449143 - Need to expose valid status transitions through config.cgi

Status: RESOLVED WONTFIX

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Max Kanat-Alexander]

Right now there's no way for WebService or other clients to have any idea what a valid status transition is without trying it out and failing, or screen-scraping.

Comment 4

[Gervase Markham [:gerv]]

Attachment: Patch v.1

This patch exposes the appropriate variables to templates. It doesn't expose the info in any of the default templates, but a) RDF is not my strong point, and b) people can drop in templates which do expose it in a form they would like. 

Gerv

Comment 5

[Frédéric Buclin]

Comment on attachment 412161 [details] [diff] [review]
Patch v.1

>+$vars->{'initial_status'} = Bugzilla::Status->can_change_to;
>+$vars->{'status_objects'} = [Bugzilla::Status->get_all];

It doesn't make sense to expose variables which are unused in our default templates, despite what you say in bug 528215 comment 3. We don't add unused stuff in our code, because it's totally unmaintainable (how should we know that such or such stuff is used somewhere else?) and it requires extra cycle for something which is not used by default Bugzilla installations. The information has to go into the RDF template.

Comment 6

[Frank Becker]

You can get the same information when you use my patch from bug #506559 (https://bug506559.bugzilla.mozilla.org/attachment.cgi?id=413945).

You need to pass the name (bug_status) or the id (9) of the status fielddef.

Comment 7

[Max Kanat-Alexander]

  Bug.fields exposes this information in a nice and structured fashion, in the WebService, now.

Comment 8

[Gervase Markham [:gerv]]

Max: although presumably that only works on 3.6? And it will require the BzAPI to make two calls in order to fulfil one request. Although I guess that's not your problem :-)

Gerv

Comment 9

[Max Kanat-Alexander]

(In reply to comment #8)
> Max: although presumably that only works on 3.6? And it will require the BzAPI
> to make two calls in order to fulfil one request. Although I guess that's not
> your problem :-)

  At some point, the WebService interfaces will support multiCall, so you can get two results in one trip.

  Also, may provided a combined bunch of stuff about Bugzilla's configuration in a Bugzilla.config call at some point in the future.

  For now, though, you could just cache the workflow--it doesn't change that often.

Comment 10

[Gervase Markham [:gerv]]

Well, the other call is to config.cgi, so it would be two calls whatever. But yes, I could cache the workflow :-)

Gerv

Comment 11

[charley]

Sorry to intrude -- I've been following this bug as a blocker to some stuff with Mylyn on Eclipse. Looks like this is exactly what I've been looking for! :)

Is there any available documentation/examples/anything on working with Bug.fields in the WebService? Is the Bug.fields you're discussing related to the patch https://bug506559.bugzilla.mozilla.org/attachment.cgi?id=413945 ?

-Charley

Comment 12

[Max Kanat-Alexander]

(In reply to comment #11)
> Is there any available documentation/examples/anything on working with
> Bug.fields in the WebService?

  Yeah, the WebService is described here:

  http://www.bugzilla.org/docs/3.6/en/html/api/Bugzilla/WebService.html

  At the bottom you'll see a link to the Bug functions.