Closed
Bug 487508
Opened 15 years ago
Closed 14 years ago
Allow restricting the visibility of custom fields and values by component
Categories
(Bugzilla :: Administration, task, P1)
Tracking
()
RESOLVED
FIXED
Bugzilla 4.0
People
(Reporter: trevor.bugs, Assigned: mkanat)
References
Details
(Whiteboard: [es-ita])
Attachments
(1 file, 2 obsolete files)
39.64 KB,
patch
|
dkl
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB5; .NET CLR 2.0.50727; DFO-MPO; DFO-MPO) Build Identifier: 3.3.4 The "Field only appears when" dropdown in editfields.cgi doesn't include a value for the Component field. Reproducible: Always Steps to Reproduce: 1.Open a custom field. 2.Open the dropdown beside "Field only appears when" and try to limit visibility by component Actual Results: Component value not available. Expected Results: Component should be included. This is an important field I want to use with this functionality when 3.4 is released.
Comment 1•15 years ago
|
||
Compared to other fields already listed, components are per-product, not global. Not sure what mkanat plans to do with them.
Severity: normal → enhancement
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → 3.3.4
(In reply to comment #1) > Compared to other fields already listed, components are per-product, not > global. Not sure what mkanat plans to do with them. I see what you mean. One possibility would be to concatinate 'Product: Component' for the visible values in the dropdown. I haven't looked at the code so this may be ugly. Originally I had thought that the functionality from the custom flags was going to be re-used here. This would have been ideal for this case since it allows limiting/allowing visibility by product and component, and allows multiple values.
Assignee | ||
Comment 3•15 years ago
|
||
I plan to use <optgroups> if I can make that work. The tricky part is making Bugzilla::Component subclass Bugzilla::Field::Choice properly, and doing all the other necessary things.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Summary: Component not available for custom field visibility functionality → Allow restricting the visibility of custom fields by component
Target Milestone: --- → Bugzilla 4.0
Comment 4•15 years ago
|
||
I would also like to see "Classification" added to the list of fields that I can use to restrict the visibility of custom fields. I can't think of a reason that it shouldn't be there.
Assignee | ||
Comment 5•15 years ago
|
||
(In reply to comment #4) > I would also like to see "Classification" added to the list of fields > that I can use to restrict the visibility of custom fields. I can't > think of a reason that it shouldn't be there. That's bug 514618.
Assignee | ||
Comment 6•15 years ago
|
||
This actually turned out to be much easier than I thought it would be. The largest part of this patch is just factoring a bunch of stuff out of Bugzilla::Field::Choice and into an Interface, (Bugzilla::Field::ChoiceInterface). I also replaced select_fields with bug_fields in the templates. I can split that out into a separate patch if you really want. Instead of using the <optgroup> tag, I just prefixed the names of the components with the names of the products. In some situations it's easy enough to do the <optgroup>, but in the dynamic javascript case (during editfields.cgi) it's pretty tough, so I just did a prefixing of the product name instead.
Assignee | ||
Updated•15 years ago
|
Target Milestone: Bugzilla 4.0 → Bugzilla 3.6
Assignee | ||
Updated•15 years ago
|
Whiteboard: [es-ita]
Assignee | ||
Comment 7•15 years ago
|
||
Oooookay. This is getting a teeny bit more complex now. I discovered that values were showing up for Component-controlled fields on page load if the *name* matched. This led to further refactoring: * Most of the code in ChoiceInterface is moved directly from Choice without modification, and so doesn't need to be looked over. However, is_set_on_bug and is_visible_on_bug are two new methods that I just added. * I discovered that showValuesWhen was being put into HTML pages even when there were no values for the value to control, wasting space and execution time. * I had to modify edit-multiple to display all values all the time--I don't know if it's buggy in 3.4, I just know that with my changes, it had to be modified.
Attachment #412320 -
Attachment is obsolete: true
Attachment #412353 -
Flags: review?(dkl)
Attachment #412320 -
Flags: review?(dkl)
Assignee | ||
Updated•15 years ago
|
Summary: Allow restricting the visibility of custom fields by component → Allow restricting the visibility of custom fields and values by component
Assignee | ||
Comment 8•15 years ago
|
||
There was a circular dependency between Field::Choice and ChoiceInterface.
Attachment #412353 -
Attachment is obsolete: true
Attachment #412362 -
Flags: review?(dkl)
Attachment #412353 -
Flags: review?(dkl)
Comment 9•14 years ago
|
||
Comment on attachment 412362 [details] [diff] [review] v3 I apologize for letting this one slide so long. It fell off my radar accidently. The patch is fairly large but I have made a best effort to review the code and it looks good from my point of view. One error I encountered is the code (due to me taking so long to get to it) is very slightly bitrotted. patching file template/en/default/bug/create/create.html.tmpl Hunk #2 FAILED at 212. Hunk #3 succeeded at 226 (offset 5 lines). Hunk #4 succeeded at 243 (offset 5 lines). Hunk #5 succeeded at 281 (offset 5 lines). Hunk #6 succeeded at 309 (offset 5 lines). Hunk #7 succeeded at 684 (offset 3 lines). 1 out of 7 hunks FAILED -- saving rejects to file template/en/default/bug/create/create.html.tmpl.rej I fixed the code to be able to continue my testing as it just requires adding id="component" in create.html.tmpl. I have also tested functionality and for the most part all works as expected in each of the different use cases. One oddity that I wanted to question is this. I have a custom field is a multiselect type, and is set to only display a particular value when the component is set to a specific value for a specific product. When I select the right, component, the value is then displayed in the custom field. I then select the value and commit the change. When I go back to the bug and change the component to something else, the custom field value is removed as expected. Then I commit the component change. But if you look in the bug history the value that I selected in the custom field is also automatically removed as well. The difference is that is I do not select a different component but instead change the product to a different product, then the value in the custom field is not automatically removed and is still selected if I change the bug back to the correct product/component combination. Is this expected behavior or a bug? The bit rot can be fixed on checkin. And if the above scenario is expected behavior (although inconsistent) then this is r=dkl.
Assignee | ||
Comment 10•14 years ago
|
||
Hmm. The above scenario is a larger issue surrounding the way that the value-controlled fields are implemented. I think it's worth filing a bug for the general case to decide what we want to do about it. Though for this bug I don't think it's related to specifically this patch.
Comment 11•14 years ago
|
||
Comment on attachment 412362 [details] [diff] [review] v3 Ok thanks. Will file a bug for the issue with the values. Please fix the patch error on checkin. r=dkl
Attachment #412362 -
Flags: review?(dkl) → review+
Updated•14 years ago
|
Flags: approval?
Assignee | ||
Updated•14 years ago
|
Target Milestone: Bugzilla 3.6 → Bugzilla 3.8
Assignee | ||
Updated•14 years ago
|
Flags: approval? → approval+
Assignee | ||
Comment 12•14 years ago
|
||
There was some tiny bitrot, which I fixed on checkin. Committing to: bzr+ssh://mkanat%40bugzilla.org@bzr.mozilla.org/bugzilla/trunk/ modified editvalues.cgi modified report.cgi modified Bugzilla/Component.pm modified Bugzilla/Constants.pm modified Bugzilla/Field.pm modified Bugzilla/Migrate.pm modified Bugzilla/Product.pm modified Bugzilla/Search.pm modified Bugzilla/Status.pm modified Bugzilla/Field/Choice.pm modified Bugzilla/WebService/Bug.pm modified template/en/default/admin/custom_fields/cf-js.js.tmpl modified template/en/default/admin/custom_fields/edit.html.tmpl modified template/en/default/admin/fieldvalues/create.html.tmpl modified template/en/default/admin/fieldvalues/edit.html.tmpl modified template/en/default/bug/edit.html.tmpl modified template/en/default/bug/field-events.js.tmpl modified template/en/default/bug/field.html.tmpl modified template/en/default/bug/create/create.html.tmpl modified template/en/default/global/user-error.html.tmpl modified template/en/default/list/edit-multiple.html.tmpl Committed revision 6955.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 13•14 years ago
|
||
Fixed now: Committing to: bzr+ssh://mkanat%40bugzilla.org@bzr.mozilla.org/bugzilla/trunk/ added Bugzilla/Field/ChoiceInterface.pm Committed revision 6958.
You need to log in
before you can comment on or make changes to this bug.
Description
•