Closed Bug 450593 Opened 16 years ago Closed 16 years ago

Ability to define values of custom fields on products (and component?) level

Categories

(Bugzilla :: Administration, task)

task
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 308253

People

(Reporter: bigstijn, Unassigned)

Details

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 1.0.3705; InfoPath.1) Build Identifier: Bugzilla 3.2 Ability to define values of custom fields on products (and component?) level Bug 371995 deals with setting a general custom field (with general values) available or not for products/components. But certainly one custom field (description) will be used for different products, while for each product different values are needed. One example can be "Fixed in version". Others are also possible. With bug 371995, this could be done by defining every time for every (new) product a custom field, adding the correct values. But it would be much better if people with editcomponents rights could enter values starting from the editproducts page. Previously bugs with specific implementations were entered (like create "fixed in" field) but I would dupe them against this more generic bug (which is, I hope, more in line with the roadmap too). Reproducible: Always Steps to Reproduce: 1. 2. 3.
IMO, this requires too much complexity and is better covered by bug 371995. I would tend to mark this bug as WONTFIX or as a dupe of bug 371995.
About the complexity, and not being a bugzilla expert: I think complexity can be reduced if the entered values are saved just as "general" custom fields (in cf_table), but that only editproducts, the values in dropdownlist and the validation is using a different table: possible values per product per custom field. But maybe that's the compexity that Frédéric had in mind :-).
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.