371995 - Allow the Product field to restrict visibility of custom fields

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, enhancement, P1)

Description

[Max Kanat-Alexander]

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

Comment 2

[Max Kanat-Alexander]

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.

Comment 3

[Pascal Held]

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.

Comment 4

[rojanu]

Attachment: Classification/Product Custom fields

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 5

[Frédéric Buclin]

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.

Comment 6

[Max Kanat-Alexander]

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.

Comment 7

[Frédéric Buclin]

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

Comment 8

[rojanu]

Attachment: Clusioned custom fields

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

Comment 9

[Max Kanat-Alexander]

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.

Comment 10

[MHL]

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

Comment 11

[Max Kanat-Alexander]

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.

Comment 12

[Max Kanat-Alexander]

Attachment: v1

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.

Comment 13

[Max Kanat-Alexander]

Attachment: v1.1

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

Comment 14

[Frédéric Buclin]

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 15

[Frédéric Buclin]

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.

Comment 16

[Max Kanat-Alexander]

(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. :-)

Comment 17

[Max Kanat-Alexander]

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

Comment 18

[Max Kanat-Alexander]

Attachment: Checked-In Version

Here's what was actually checked in.

Comment 19

[rojanu]

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.

Comment 20

[Max Kanat-Alexander]

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

Comment 21

[rojanu]

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

Comment 22

[Max Kanat-Alexander]

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

Comment 23

[bigstijn]

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

Comment 24

[Frédéric Buclin]

This feature worths to be relnoted.