Last Comment Bug 553591 - Custom field value visibility by Status or Resolution does not work
: Custom field value visibility by Status or Resolution does not work
[3.6 only; 4.0 and tip not affected]
Product: Bugzilla
Classification: Server Software
Component: User Interface (show other bugs)
: 3.4.6
: All All
-- major with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: default-qa
Depends on:
  Show dependency treegraph
Reported: 2010-03-19 07:59 PDT by Liya
Modified: 2011-03-01 11:16 PST (History)
1 user (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Liya 2010-03-19 07:59:07 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 GTB6
Build Identifier: 

Custom field value visibility by Status or Resolution does not work

Reproducible: Always

Steps to Reproduce:
1. Create a custom field (Drop Down or Multi-Selection Box), define values visibility by Status.
2. Add legal values for your new field while add a visibility at least for some of them to a specific Status value, for example - RESOLVED
3. Open existing bug, change its status to RESOLVED
Actual Results:  
the list of the values in your custom field does not change

Expected Results:  
Values that are defined to be visible for RESOLVED status should appear in the list

- same flow can be reproduced for Resolution
- no JS errors..
Comment 1 User image Frédéric Buclin 2010-03-19 08:07:38 PDT
Looks like a dupe of bug 520993. Which version of Bugzilla do you have?
Comment 2 User image Liya 2010-03-20 05:23:10 PDT
I have the latest - Bugzilla 3.4.6
bug 520993 was about field visibility (and I opened it :)), 
this one about values visibility.
Comment 3 User image Frédéric Buclin 2010-05-22 18:28:53 PDT
I can reproduce the issue in Bugzilla 3.4.6 and 3.6, but not in 3.7. mkanat, do you remember which bug fixed this problem?
Comment 4 User image Frédéric Buclin 2010-05-22 18:32:09 PDT
Maybe fixed by bug 512606?
Comment 5 User image Frédéric Buclin 2010-05-22 18:33:01 PDT
(In reply to comment #4)
> Maybe fixed by bug 512606?

Hum no, there has been no change in knob.html.tmpl since 3.6.
Comment 6 User image Max Kanat-Alexander 2010-05-22 22:04:40 PDT
Is it possible we did a different fix on HEAD than on the branches for that bug...? Otherwise I don't know what bug would have fixed this.
Comment 7 User image Frédéric Buclin 2010-05-23 12:48:13 PDT
Confirming for now as I can reproduce with 3.6.
Comment 8 User image Frédéric Buclin 2010-10-25 05:35:01 PDT
I definitely don't know for sure which bug fixed this problem in 4.0 and 4.1. Maybe it could be bug 487508, but I'm really not sure. mkanat, unless you have an idea what's wrong with 3.6, I suggest we close this bug as WFM as it's fixed in newer releases.
Comment 9 User image Max Kanat-Alexander 2010-10-26 13:51:24 PDT
Well, at the moment it's not fixed in any stable release, and 3.6 is our current stable series, so until 4.0 becomes the stable series, I think we should keep this open.
Comment 10 User image Max Kanat-Alexander 2011-03-01 11:16:18 PST
Status Whiteboard says this was 3.6 only, and 3.6 is locked to security fixes only now, so this should be handled now unless the Whiteboard is wrong.

Note You need to log in before you can comment on or make changes to this bug.