Now that we have a create() for Bugzilla::Field::Choice, it's time to make an update() for editvalues.cgi to use.

Here's what I have so far. This is actually starting to get kind of complex. :-(

Okay, here we go. Tested and ready. Note that I updated the way Object::update() works ever so slightly (gave it a list-context return that's different from its scalar-context return), so I had to make a few modifications in files otherwise unrelated to this patch.

Comment on attachment 340280 [details] [diff] [review] v1 This looks fine, but one thing I've just noticed is that in the db the cf_foo column is a *string* not an id linking to the cf_foo table??? Is that really the intention?

Comment on attachment 340280 [details] [diff] [review] v1 (Oh, and the SetParams stuff is really ugly, but thats a later fix...)

(In reply to comment #3) > Is that really the intention? Yes, that's really the intention, currently all our fields work like that. Bug 287311 covers making them foreign keys instead. (In reply to comment #4) > (Oh, and the SetParams stuff is really ugly, but thats a later fix...) Depending on how you mean that, the fix is either bug 351899 or bug 303662.

(bbaetz--I responded to your comment but realized that you weren't CC'ed.)

Comment on attachment 340280 [details] [diff] [review] v1 OK then, r=bbaetz Not too happy that the new fields were implemented the 'old way', but its a bit late now.

(In reply to comment #7) > Not too happy that the new fields were implemented the 'old way', but its a bit > late now. It was the right choice at the time. Either we moved all the old fields over before adding custom fields (a huge task that we didn't have time, resources, or enough interest in from contributors), or we added custom fields using strings directly in the bugs table. The only other choice would be to split our logic everywhere for those fields, and that was obviously not going to happen, particularly in Search.pm.

Putting in the approval queue until the blocker gets r+.

Checking in editusers.cgi; /cvsroot/mozilla/webtools/bugzilla/editusers.cgi,v <-- editusers.cgi new revision: 1.149; previous revision: 1.148 done Checking in editvalues.cgi; /cvsroot/mozilla/webtools/bugzilla/editvalues.cgi,v <-- editvalues.cgi new revision: 1.33; previous revision: 1.32 done Checking in Bugzilla/Bug.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v <-- Bug.pm new revision: 1.263; previous revision: 1.262 done Checking in Bugzilla/Object.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Object.pm,v <-- Object.pm new revision: 1.25; previous revision: 1.24 done Checking in Bugzilla/Product.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Product.pm,v <-- Product.pm new revision: 1.31; previous revision: 1.30 done Checking in Bugzilla/Status.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Status.pm,v <-- Status.pm new revision: 1.9; previous revision: 1.8 done Checking in Bugzilla/Field/Choice.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Field/Choice.pm,v <-- Choice.pm new revision: 1.3; previous revision: 1.2 done Checking in template/en/default/global/messages.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/messages.html.tmpl,v <-- messages.html.tmpl new revision: 1.77; previous revision: 1.76 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.260; previous revision: 1.259 done

Added to the release notes for Bugzilla 3.4 in bug 494037.