Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 590153 - Move cf_target_release to a normal Bugzilla field and make it configurable per product
Summary: Move cf_target_release to a normal Bugzilla field and make it configurable pe...
Status: CLOSED DUPLICATE of bug 584956
Alias: None
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs
Version: 3.6
Hardware: All
OS: Linux
medium vote
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
Depends On:
Blocks: JIRABZ
TreeView+ depends on / blocked
Reported: 2010-05-07 20:45 UTC by David Lawrence
Modified: 2013-06-24 03:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2010-07-24 21:03:36 UTC

Attachments (Terms of Use)

Description David Lawrence 2010-05-07 20:45:47 UTC
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 21:03:36 UTC

*** 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.