Bug 802141
| Summary: | RPC should allow updating of bug flags | ||
|---|---|---|---|
| Product: | [Community] Bugzilla | Reporter: | Tomas Hoger <thoger> |
| Component: | WebService | Assignee: | Simon Green <sgreen> |
| Status: | CLOSED UPSTREAM | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.2 | CC: | ebaak, sgreen |
| Target Milestone: | 4.2-5 | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-09-07 02:52:26 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 840034 | ||
(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 (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? (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 Reopening this, as we can work on this, but I need the PM to assign time to it. 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 |
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'.