bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Allow the Product field to restrict visibility of custom fields

RESOLVED FIXED in Bugzilla 3.4

Status

()

Bugzilla
Bugzilla-General
P1
enhancement
RESOLVED FIXED
12 years ago
6 years ago

People

(Reporter: Max Kanat-Alexander, Assigned: Max Kanat-Alexander)

Tracking

(Blocks: 2 bugs)

Bugzilla 3.4
Dependency tree / graph
Bug Flags:
approval +
testcase ?

Details

(Whiteboard: [roadmap: 4.0])

Attachments

(1 attachment, 4 obsolete attachments)

(Assignee)

Description

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

Updated

11 years ago
Duplicate of this bug: 386151
(Assignee)

Updated

11 years ago
Blocks: 287336
(Assignee)

Updated

11 years ago
Depends on: 261181
(Assignee)

Comment 2

11 years ago
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.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0

Updated

10 years ago
Assignee: general → LpSolit
Whiteboard: [roadmap: 4.0]

Updated

10 years ago
Blocks: 353690

Comment 3

10 years ago
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

10 years ago
Created attachment 355116 [details] [diff] [review]
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
Attachment #355116 - Flags: review?

Comment 5

10 years ago
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.
Attachment #355116 - Flags: review? → review-
(Assignee)

Comment 6

10 years ago
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.
Depends on: 458436
No longer depends on: 261181
Summary: Ability to restrict custom fields to products/components (like flags) → Allow Product and Component fields to restrict visibility of custom fields

Comment 7

10 years ago
OK, I will let you play with that, then.
Assignee: LpSolit → general

Comment 8

10 years ago
Created attachment 356160 [details] [diff] [review]
Clusioned custom fields

I have created another patch per Comment #5 by Frédéric
Attachment #355116 - Attachment is obsolete: true
Attachment #356160 - Flags: review?
(Assignee)

Updated

10 years ago
Attachment #356160 - Flags: review? → review-
(Assignee)

Comment 9

10 years ago
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

10 years ago
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...
(Assignee)

Comment 11

10 years ago
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.
Assignee: general → mkanat
Status: NEW → ASSIGNED
Priority: -- → P1
Summary: Allow Product and Component fields to restrict visibility of custom fields → Allow the Product field to restrict visibility of custom fields
Target Milestone: Bugzilla 4.0 → Bugzilla 3.4
(Assignee)

Comment 12

10 years ago
Created attachment 358580 [details] [diff] [review]
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.
Attachment #356160 - Attachment is obsolete: true
Attachment #358580 - Flags: review?(LpSolit)
(Assignee)

Comment 13

10 years ago
Created attachment 358584 [details] [diff] [review]
v1.1

I realized I attached a slightly out-of-date patch.
Attachment #358580 - Attachment is obsolete: true
Attachment #358584 - Flags: review?(LpSolit)
Attachment #358580 - Flags: review?(LpSolit)

Comment 14

10 years ago
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
Attachment #358584 - Flags: review?(LpSolit) → review+

Comment 15

10 years ago
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.
(Assignee)

Comment 16

10 years ago
(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. :-)
Flags: approval+
(Assignee)

Comment 17

10 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Comment 18

10 years ago
Created attachment 361169 [details] [diff] [review]
Checked-In Version

Here's what was actually checked in.
Attachment #358584 - Attachment is obsolete: true
Attachment #361169 - Flags: review+

Updated

10 years ago
Flags: testcase?

Comment 19

10 years ago
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.
(Assignee)

Comment 20

10 years ago
(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

10 years ago
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
(Assignee)

Comment 22

10 years ago
(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.

Updated

10 years ago
Blocks: 479345

Updated

10 years ago
Blocks: 479400

Comment 23

10 years ago
(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

9 years ago
This feature worths to be relnoted.
Keywords: relnote

Updated

9 years ago
Duplicate of this bug: 492740

Updated

9 years ago
Blocks: 494072
(Assignee)

Updated

9 years ago
Keywords: relnote

Updated

9 years ago
Blocks: 507389
(Assignee)

Updated

9 years ago
Duplicate of this bug: 528313

Updated

6 years ago
Blocks: 731178
You need to log in before you can comment on or make changes to this bug.