There should be an inclusion/exclusion table for custom fields, so that they only show up in certain classifications, products, or components.

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

At the moment I implement the enhancement #396974. In this feature a have also implement a function to define the visibility of a custom field, so you can bind a field to a product, a compomnet or any other condition.

Patch created is depended on bug 291433. it provides the future to turn on/off visibility of a custom field against a classification/product

Comment on attachment 355116 [details] [diff] [review] Classification/Product Custom fields No, I want it to reuse the existing inclusion/exclusion code we have for flags, which is why this bug is blocked by bug 261181.

This is essentially already fixed by bug 291433. We just need to add Product and Component as valid fields. So instead of using the *clusions stuff, we just need to allow the Product and Component fields to control the visibility of fields. (Then eventually we might even allow multiple selections.) The only thing this doesn't get us is components that have the same name across different products being considered as different items, but I think that's actually OK in a lot of use cases.

OK, I will let you play with that, then.

I have created another patch per Comment #5 by Frédéric

Comment on attachment 356160 [details] [diff] [review] Clusioned custom fields No, I think you have misunderstood where I was going with this bug. We just need to extend the "Field only visible when" mechanism that is new to 3.4.

I believe this is a crucial modification to allow Bugzilla to leave the "Software development corner" to used as tracking tool for general projects or corporate environments...

So, as it turns out, it's very easy to make Product control other fields, and it will be harder for the Component field, I do believe. So we're going to just do the Product field first, and then possibly the Component field later.

Okay, here we go. This was actually fairly straightforward. I didn't create a warning page when deleting the product if the product controls other fields, it just throws a (rather clear) error when you attempt to actually perform the deletion.

I realized I attached a slightly out-of-date patch.

Comment on attachment 358584 [details] [diff] [review] v1.1 >Index: template/en/default/bug/edit.html.tmpl >+ [% INCLUDE bug/field.html.tmpl >+ bug = bug, field = select_fields.product, >+ desc_url = 'describecomponents.cgi', value = bug.product Why setting desc_url for it? When you click the label, it displays all products. Does it make sense? >Index: template/en/default/bug/field.html.tmpl > # no_tds: boolean; if true, don't display the label <th> or the > # wrapping <td> for the field. >+ # desc_url Haha, nice description of desc_url. :-p >Index: template/en/default/global/user-error.html.tmpl >+ You cannot delete the [% value.field.description FILTER html %] Nit: would be better lowercase. Looks good and works fine. r=LpSolit

Comment on attachment 358584 [details] [diff] [review] v1.1 >Index: template/en/default/bug/field.html.tmpl >+ <a href="[% desc_url %]"> Oh, I almost forgot: t/008filter..........NOK 19/263 # Failed test '(en/default) template/en/default/bug/field.html.tmpl has unfiltered directives: # 54: desc_url # --ERROR' Please add FILTER html.

(In reply to comment #14) > Why setting desc_url for it? The other option was to add a no_desc argument, and I thought it was more useful to allow specifying a desc, particularly where a useful one could be provided. > When you click the label, it displays all > products. Does it make sense? Yeah, it describes all the products, I think that's useful. I'll fix all that other stuff. :-)

Checking in enter_bug.cgi; /cvsroot/mozilla/webtools/bugzilla/enter_bug.cgi,v <-- enter_bug.cgi new revision: 1.169; previous revision: 1.168 done Checking in Bugzilla/Field.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Field.pm,v <-- Field.pm new revision: 1.43; previous revision: 1.42 done Checking in Bugzilla/Product.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Product.pm,v <-- Product.pm new revision: 1.34; previous revision: 1.33 done Checking in Bugzilla/Field/Choice.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Field/Choice.pm,v <-- Choice.pm new revision: 1.8; previous revision: 1.7 done Checking in template/en/default/admin/custom_fields/cf-js.js.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/custom_fields/cf-js.js.tmpl,v <-- cf-js.js.tmpl new revision: 1.5; previous revision: 1.4 done Checking in template/en/default/bug/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.152; previous revision: 1.151 done Checking in template/en/default/bug/field.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/field.html.tmpl,v <-- field.html.tmpl new revision: 1.23; previous revision: 1.22 done Checking in template/en/default/global/user-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v <-- user-error.html.tmpl new revision: 1.275; previous revision: 1.274 done

Here's what was actually checked in.

This provides only to have a custom field on either one or all products and it is not possible to exclude a field from one product and include in the rest of products.

(In reply to comment #19) > This provides only to have a custom field on either one or all products and it > is not possible to exclude a field from one product and include in the rest of > products. You are correct, but this does at least get you the basic functionality of per-Product fields.

The attachment 355116 [details] [diff] [review] (Classification/Product Custom fields) I created first provides having custom fields in/excluded on Product and Classification base. Which can easily be converted to Product/Components. I thought that was the main goal for this bug

(In reply to comment #21) > The attachment 355116 [details] [diff] [review] (Classification/Product Custom fields) I created first > provides having custom fields in/excluded on Product and Classification base. > Which can easily be converted to Product/Components. > > I thought that was the main goal for this bug It was originally, but we changed it to re-use some architecture that we already have, instead. Over time what we've done can be extended to do what you need, most likely.

(In reply to comment #19) > it > is not possible to exclude a field from one product and include in the rest of > products. Created bug 479400 for this enhancement.

This feature worths to be relnoted.