Bug 802141 - RPC should allow updating of bug flags
RPC should allow updating of bug flags
Status: CLOSED UPSTREAM
Product: Bugzilla
Classification: Community
Component: WebService (Show other bugs)
4.2
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Simon Green
: Reopened
Depends On:
Blocks: 840034
  Show dependency treegraph
 
Reported: 2012-03-11 13:00 EDT by Tomas Hoger
Modified: 2014-10-12 18:47 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-06 22:52:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2012-03-11 13:00:37 EDT
Description of problem:
Bug.get API allows getting a lot of details about bug(s).  That info, however, does not include bug flags.  To get that info, it seems separate Flag.get call needs to be used.

At least some basic flag info should be provided by Bug.get too.  It does not need to be the same amount of detail as provided by Flag.get, but it would be useful to have a list of set flags without an overhead of additional xmlrpc call.

I think returned value can be something like:
- arrays of strings representing currently set flags, e.g. 'pm_ack?', 'blocker+', 'rhel-6.1.0-'
- alternatively, it can be an array of 'flags' hashes as returned by Flag.get (name, status, flag_id, setter_email, ...) only including set flags, and excluding unset

Similarly, Bug.update should allow doing flag updates with other related changes in a single operation.  E.g. via add_flag / delete_flag as used for other fields that allow multiple values, or using a more Flag.update like info.

Note that there's currently an inconsistency in between Bug.* APIs, as Bug.search allows getting flag values ('flags' can be used in column_list) as a string (flags separated using ', '), but include_fields for Bug.get does not seem to allow 'flags'.
Comment 6 Simon Green 2012-05-16 23:43:12 EDT
(In reply to comment #0)
> At least some basic flag info should be provided by Bug.get too.  It does not
> need to be the same amount of detail as provided by Flag.get, but it would be
> useful to have a list of set flags without an overhead of additional xmlrpc
> call.

As noted, this is part of the Bug.get (and Bug.search) result set when 'flags' is specified as a value in the include_fields or extra_fields key.
 
> Similarly, Bug.update should allow doing flag updates with other related
> changes in a single operation.  E.g. via add_flag / delete_flag as used for
> other fields that allow multiple values, or using a more Flag.update like info.

I've been thinking about this. Is there any reason that Flag.update does not meet your needs? The main reason I am thinking this is that I'd hate to put in some code for this, only for upstream to do it differently. At least with Flag.update we can depreciate it when upstream allow updating Flags via Bug.update.

  -- simon
Comment 7 Tomas Hoger 2012-05-17 04:56:25 EDT
(In reply to comment #6)
> > Similarly, Bug.update should allow doing flag updates with other related
> > changes in a single operation.  E.g. via add_flag / delete_flag as used for
> > other fields that allow multiple values, or using a more Flag.update like
> > info.
> 
> I've been thinking about this. Is there any reason that Flag.update does not
> meet your needs? The main reason I am thinking this is that I'd hate to put in
> some code for this, only for upstream to do it differently. At least with
> Flag.update we can depreciate it when upstream allow updating Flags via
> Bug.update.

There is nothing wrong with Flag.update API, I successfully used it to set / unset flags.  As noted above, the motivation is to be able to do all required changes to the bug in a single operation.  I.e. if I want to change summary, version, add comment and change some flags, it's bit odd to be able to change all but flags in one call and a separate one is needed to change flags.  Not having to do two calls has other benefits:

- for updates like these, establishing connection may take more time than the rpc request itself; halving the number of requests may have significant impact on the total execution time if more than a few bugs are to be changed
- less bug spam

Is upstream likely to do anything about flags and their updating in Bug.update in some foreseeable future?
Comment 8 Simon Green 2012-05-17 06:29:10 EDT
(In reply to comment #7)
> There is nothing wrong with Flag.update API, I successfully used it to set /
> unset flags.

There are some changes to this in Bugzilla 4.2.1-2 that will make this work better :)

> As noted above, the motivation is to be able to do all required
> changes to the bug in a single operation. 

While I agree with this, I'm going to leave it as it is. Hopefully someone upstream will pick this up, and work on it. After looking at the Flag.update code today (for a different bug) putting it in Bug.update is not going to be a small job.

> Is upstream likely to do anything about flags and their updating in Bug.update
> in some foreseeable future?

I've filed a bug upstream. Hopefully someone will pick it up.

https://bugzilla.mozilla.org/show_bug.cgi?id=756048

Marking as WONTFIX. Sorry.

  -- simon
Comment 9 Simon Green 2012-08-09 00:55:09 EDT
Reopening this, as we can work on this, but I need the PM to assign time to it.
Comment 10 Simon Green 2012-09-04 02:54:02 EDT
Patch filed upstream. If accepted upstream, we WON'T be backporting it to Bugzilla 4.2. Instead we will wait for Bugzilla 4.4 to be released.

  -- simon

Note You need to log in before you can comment on or make changes to this bug.