Last Comment Bug 520993 - Custom field that should appear only when Resolution is FIXED is not displayed when you change the status to RESOLVED
: Custom field that should appear only when Resolution is FIXED is not displaye...
Status: RESOLVED FIXED
:
Product: Bugzilla
Classification: Server Software
Component: Creating/Changing Bugs (show other bugs)
: 3.4.2
: All All
: -- normal (vote)
: Bugzilla 3.4
Assigned To: Max Kanat-Alexander
: default-qa
Mentors:
: 575501 (view as bug list)
Depends on:
Blocks: 545277 548933
  Show dependency treegraph
 
Reported: 2009-10-07 07:46 PDT by Liya
Modified: 2010-06-29 16:45 PDT (History)
4 users (show)
mkanat: approval+
mkanat: approval3.6+
LpSolit: blocking3.6+
mkanat: approval3.4+
LpSolit: blocking3.4.6+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
v1 (2.29 KB, patch)
2010-02-07 14:44 PST, Max Kanat-Alexander
LpSolit: review+
Details | Diff | Splinter Review

Description Liya 2009-10-07 07:46:36 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5
Build Identifier: 3.4.2

I have a custom field that should appear only when Resolution is FIXED.
If I edit a bug in any "open" status, and change the status to RESOLVED, the resolution field appears while FIXED is the first value, so it's selected. This does not make my custom field be displayed on the page as expected. 
If I change Resolution to any other value and then back to FIXED, my custom field is displayed.

Reproducible: Always

Steps to Reproduce:
1.Define a custom field, set 'Field only appears when'=Resolution, 'is set to'=FIXED
2. Open existing bug in any open status (NEW/ASSIGNED/REOPENED)
3. Change status to RESOLVED
Actual Results:  
resolution field appears, FIXED is selected (the first value), but you custom field does not appear

Expected Results:  
Your custom field should appear in this case, the same like on change of the resolution field to FIXED
Comment 1 Frédéric Buclin 2009-10-07 07:51:07 PDT
I can reproduce the problem. Probably should JS trigger this event.
Comment 2 Frédéric Buclin 2009-12-04 08:08:42 PST
OK, I couldn't understand why a custom field was not displayed despite the bug was marked as FIXED till I remembered this bug.
Comment 3 Max Kanat-Alexander 2009-12-04 08:12:55 PST
If I finish this before the sec release, then it can be a blocker, otherwise it will have to wait for 3.4.6.
Comment 4 Guy Pyrzak 2010-02-01 11:44:46 PST
there are a bunch of fields that don't use the custom field template so I can check this out. Did we test this across the board with all the built in fields?
Comment 5 Max Kanat-Alexander 2010-02-07 13:26:24 PST

*** This bug has been marked as a duplicate of bug 538211 ***
Comment 6 Max Kanat-Alexander 2010-02-07 14:07:53 PST
Okay, so it turns out that the bug that I duped this to was specifically a problem in enter_bug, so it couldn't possibly be related to this bug. Reopening.
Comment 7 Max Kanat-Alexander 2010-02-07 14:44:49 PST
Created attachment 425722 [details] [diff] [review]
v1

Okay, this fixes it. We fire onchange when we display or hide the resolution field, now, and when we hide it, we set it to an empty value so that the onchange works properly.
Comment 8 Frédéric Buclin 2010-02-07 16:34:15 PST
Comment on attachment 425722 [details] [diff] [review]
v1

OK, this fixes the problem for me. r=LpSolit
Comment 9 Max Kanat-Alexander 2010-02-08 15:45:14 PST
Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/                       
modified js/field.js
Committed revision 6973.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/3.6/                         
modified js/field.js
Committed revision 6967.

Committing to: bzr+ssh://mkanat%40bugzilla.org@bzr.mozilla.org/bugzilla/3.4/   
modified js/field.js
Committed revision 6722.
Comment 10 Frédéric Buclin 2010-06-29 16:45:32 PDT
*** Bug 575501 has been marked as a duplicate of this bug. ***

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