Closed Bug 1124255 Opened 5 years ago Closed 5 years ago

Need a way to find only active versions and target milestones using the API

Categories

(bugzilla.mozilla.org :: API, defect)

Production
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: emorley, Assigned: dkl)

References

Details

Attachments

(1 file)

Use case:
mcMerge wants to display only the active target milestones in its UI.
A number of target milestones have been disabled on BMO, but when mcMerge calls https://bugzilla.mozilla.org/bzapi/configuration it returns all milestones, even the inactive ones. 

Filing this in upstream (rather than bmo::bzapi compat) , since (a) I'm presuming bzapi is feature frozen, and (b) bug 1120782 comment 12 implies that the native API doesn't support this either, which would presumably be a pre-requisite for bzapi supporting it, if if not feature-frozen.
For this version of the API we cannot change what is already there but we can add if we need to. The /bzapi/configuration is bascally the same output as config.cgi?ctype=json. They use the same template. so the latter can be used for a native REST only client which is not using the /bzapi endpoint.

What we can do is add to the template, next to the product milestones, another key called 'active_target_milestone' which only lists the ones that are enabled.

Then for the 2.0 version of native REST we can do the 'target_milestone' field properly and make it a list of objects with is_active set to true or false.

Sound good?

dkl
Assignee: nobody → dkl
Status: NEW → ASSIGNED
Flags: needinfo?(glob)
Flags: needinfo?(emorley)
Sounds great! Thank you :-)
Flags: needinfo?(emorley)
(In reply to David Lawrence [:dkl] from comment #1)
> What we can do is add to the template, next to the product milestones,
> another key called 'active_target_milestone' which only lists the ones that
> are enabled.

i think it would be better to add an "is_active" to each object.

that said, ed, mcMerge could hit:
  https://bugzilla.mozilla.org/rest/product/Core?include_fields=milestones

which already includes the milestone's is_active bit (and if that's all mcMerge needs, it's a much quicker query).
Flags: needinfo?(glob)
(In reply to Byron Jones ‹:glob› from comment #3)
> that said, ed, mcMerge could hit:
>   https://bugzilla.mozilla.org/rest/product/Core?include_fields=milestones

We need the milestones from multiple products (and don't know in advance, at least with the current flow) sadly.
understood.

fwiw (even though you can't use it) you can do multiple products with the very ugly and clumsy:
https://bugzilla.mozilla.org/rest/product/Core?include_fields=name,milestones&names=Firefox&names=Toolkit
(In reply to Byron Jones ‹:glob› from comment #3)
> (In reply to David Lawrence [:dkl] from comment #1)
> > What we can do is add to the template, next to the product milestones,
> > another key called 'active_target_milestone' which only lists the ones that
> > are enabled.
> 
> i think it would be better to add an "is_active" to each object.
> 
> that said, ed, mcMerge could hit:
>   https://bugzilla.mozilla.org/rest/product/Core?include_fields=milestones
> 
> which already includes the milestone's is_active bit (and if that's all
> mcMerge needs, it's a much quicker query).

So we would then need to add a new list called 'target_milestone_detail' which is a list of proper objects then. Similar to how we do assigned_to_detail, etc. in Bug.get.

dkl
Attached patch 1124255_1.patchSplinter Review
Went ahead and fixed up components and versions as well.

dkl
Attachment #8556536 - Flags: review?(glob)
Comment on attachment 8556536 [details] [diff] [review]
1124255_1.patch

Review of attachment 8556536 [details] [diff] [review]:
-----------------------------------------------------------------

r=glob
Attachment #8556536 - Flags: review?(glob) → review+
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   0624216..fe77847  master -> master
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Blocks: 1131862
You need to log in before you can comment on or make changes to this bug.