Bug 590153

Summary: Move cf_target_release to a normal Bugzilla field and make it configurable per product
Product: [Community] Bugzilla Reporter: David Lawrence <dkl>
Component: Creating/Changing BugsAssignee: David Lawrence <dkl>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 3.6CC: mharvey
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-07-24 21:03:36 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: 583097    

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