Bug 590153 - Move cf_target_release to a normal Bugzilla field and make it configurable per product
Move cf_target_release to a normal Bugzilla field and make it configurable pe...
Status: CLOSED DUPLICATE of bug 584956
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
3.6
All Linux
low Severity medium (vote)
: ---
: ---
Assigned To: David Lawrence
: FutureFeature
Depends On:
Blocks: JIRABZ
  Show dependency treegraph
 
Reported: 2010-05-07 16:45 EDT by David Lawrence
Modified: 2013-06-23 23:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-24 17:03:36 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 David Lawrence 2010-05-07 16:45:47 EDT
Currently the Target Release field is a custom field and as such does not scale well when many different products start wanting to us it. Aside from the fact that it is currently global and visible to all products, if we start creating a new one for each product named for example "<product> Target Release" then the boolean charts list starts to get really long as well. Keeping it as a single custom field to share between many products (bug 588602) also is not good as the list of values will become very long and confusing with all of the various versions needed.

I suggest to solve this by creating a new core Bugzilla field similar to how Target Milestone works except call it Target Release. The new field will have it's values configurable per product same as Milestone. And then you can could just have one multi select on the advanced query page for all target release values (and filter it per product using javascript) instead of relying on the boolean charts drop down.

Alot of the core code would need to be touched to implement this which is partly why we did it as a custom field instead in the beginning. But the benefit would be greater than the work required.

The JIRA migration is also requiring something like this to map to their Fix For field which is configured per product as well.
Comment 1 David Lawrence 2010-07-24 17:03:36 EDT

*** This bug has been marked as a duplicate of bug 584956 ***

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