The entries are there, but empty; I'm logged in as someone who can set them to +, no less! http://grab.by/grabs/7fc19eb164552e35823cdbfa177f3a07.png

This is a regression from bug 580056, I'm pretty sure.

If I could set "in-testsuite?" on this bug, I would.

Dave: can you give an ETA on fixing this regression, or some other comment?

I believe, as another symptom, this bug is what makes cloning inherit the field values of the parent bug with no way to change them.

Anything we can do here? Looks like it will never get attention.

Taking.

Patch that creates a proper Bugzilla::FakeBug package in enter_bug.cgi allowing the values for custom fields to be properly filtered and displayed. At first I thought of just sub classing Bugzilla::Bug completely but that cause other issues when the template causes default.foo where foo equals some subroutine name in Bugzilla::Bug instead of a simple value. This should be fixed properly for 4.0 but this patch fixes this for now. Please review Dave

Patch to update the BMO extension to allow filtering of custom fields for enter_bug.cgi and other places. Creates a new module extensions/BMO/lib/FakeBug.pm that mimics a simplified Bugzilla::Bug object for use of check_can_change_field(). Please review. Dave

I thought I'd tested this on 4.0 without the FakeBug and it worked... Was I hallucinating? Gerv

(In reply to comment #12) > I thought I'd tested this on 4.0 without the FakeBug and it worked... Was I > hallucinating? > I was going by your original email you sent a while back giving the current 4.0 porting status which stated this functionality was not working. So I admit that I did not try it first before working on a solution for 4.0 similar to what I did for 3.6. I will play around with it some more without the changes and see if it can be done. As it is now with my patch applied, each of the scenarios is working properly for me. Dave

Comment on attachment 506886 [details] [diff] [review] Patch to fix broken custom field values for enter_bug.cgi 3.6 (v1) This looks fine by inspection, as long as you've tested it, as I don't have the time to test it myself right now.

(thanks, david and reed, for helping get this fixed)

I am going to have justdave put this on staging to do final checks and then see when it can be pushed live. Committing to: bzr+ssh://dlawrence%40mozilla.com@bzr.mozilla.org/bmo/3.6/ modified enter_bug.cgi Committed revision 7241.

This is live now. Please reopen this if you see any problems. Dave

This does indeed fix comment 6 :)

So what about the status fields? Do we really want to allow everyone to set all states, or only '?' as for the blocking flag?

(In reply to comment #19) > So what about the status fields? Do we really want to allow everyone to set all > states, or only '?' as for the blocking flag? The code for enter_bug.cgi is using the same group filtering that is used for show_bug.cgi so the same options are available in both places. Are you saying it would be better to only show "?" as an option on enter_bug.cgi even if the reporter has permissions to see all of the other values as well? Dave

Ok, I see. So I have checked and yes, it's really the same on both pages. Not sure if there was already a discussion for which items are wanted in the status flag field and who has permissions. Should at least be another bug, if it's an issue. Marking as verified fixed. Thanks David!

Comment on attachment 507147 [details] [diff] [review] Patch to fix broken custom field values for enter_bug.cgi 4.0 (v1) This is fixed now on BMO and no longer needs review.

Did this land recently? I noticed that email for new bugs includes all the current custom fields and their default statuses, which turns out to cause a much larger email.

(In reply to comment #23) > Did this land recently? I noticed that email for new bugs includes all the > current custom fields and their default statuses, which turns out to cause a > much larger email. The fix for displaying the fields properly from the enter_bug.cgi page landed recently, yes. The fields showing up in new bug mails was a quick mistake that should be fixed now. dkl