Closed Bug 560523 Opened 10 years ago Closed 10 years ago
.1 and status-seamonkey2 .1 fields
We've been working on SeaMonkey 2.1 based on Mozilla 1.9.3 for some time now, and are starting concrete planning for milestones, so some new flags would be nice. We'd like to switch over to the new-style custom fields as well there, so we should get those created now. Those values should be supported (for now): blocking-seamonkey2.1: --- ? - needed a1+ a2+ b1+ final+ status-seamonkey2.1: --- ? wanted I guess there's no tooling for an automated move of the current flags to those fields, but we should disable the blocking-seamonkey2.1a1 and wanted-seamonkey2.1 flags right away, so people can't request them an more, that should all be done via the new fields, and we'll manually migrate over the states in triage.
Oh, I forgot in this initial comment that, as for current flags, seamonkey-council should be able to set all states, anyone should be able to request ? on those fields.
Assigning to Reed since this is requesting creation of new flags.
Assignee: marcia → reed
Component: Bugzilla: Keywords & Components → Bugzilla: Other b.m.o Issues
QA Contact: timeless → other-bmo-issues
Comment on attachment 440987 [details] [diff] [review] patch - v1 Phew, I hope that will become less ugly with a future version of Bugzilla, this looks overly complicated. :( >+ [% ELSIF field.name.match("^cf_blocking_seamonkey") OR field.name.match("^cf_status_seamonkey") %] >+ [% NEXT UNLESS bug.product == "Composer" OR bug.product == "MailNews Core" OR >+ bug.product == "Mozilla Localizations" OR bug.product == "Other Applications" OR >+ bug.product == "SeaMonkey" %] Not completely sure about "Composer", as that product was for the standalone composer, which never came rolling on Mozilla-hosted infrastructure. And I wonder how much pain "Mozilla Localizations" will give us in the long term for all those flags (interesting that we have SeaMonkey's there but not Thunderbird's, BTW) given the upcoming split of that into a zillion of products. Still, nothing to worry for this specific change. So, looks good to me, though I'm a bit unsure about Composer, but no harm if we don't use it there anyhow.
Attachment #440987 - Flags: feedback?(kairo) → feedback+
modified Bugzilla/Bug.pm modified Bugzilla/Search/Quicksearch.pm modified template/en/default/bug/edit.html.tmpl modified template/en/default/bug/show-multiple.html.tmpl modified template/en/default/bug/show.xml.tmpl modified template/en/default/bug/create/create.html.tmpl Committed revision 6777. and deployed to production. This only adds the back-end code for dealing with the field if it shows up on a bug. The fields still need to actually be created in the admin GUI, and I'd like to hold off on that briefly while I investigate a couple things. I'm really not fond of subjecting the general public to an SQL error on every page load during the 3 minutes it takes to add each field.
Attachment #440987 - Flags: review?(justdave) → review+
Reed: I figured out how to avoid the crash: When you create the fields, make sure the "Is obsolete" box is checkmarked. The code that's crashing while the data setup is still incomplete is explicitly looking for active fields, so as long as the field is initially created as obsolete I believe it won't crash show_bug. Once it's created you can go back and edit the field and uncheck the box.
ok, hold off while I continue to test if it's not already too late, I tried to test that theory on the staging site and it didn't work (it still crashed).
OK, you're cleared. The manual workaround works. My patch to try to make it automatic just doesn't. I'll keep working on the patch, in the meantime, manually setting it to obsolete on creation successfully avoids a crash.
And you no longer need the workaround. Got a working patch for bug 531243 and it's been deployed to production.
Dave, thanks for this work! What's the next step here? Who is doing it? What's the ETA?
Ok, all done. Let me know if you see anything incorrect or have any problems.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Looks like seamonkey-council doesn't get mail for changes of those fields, but we do for the other flags. Is that normal for those custom fields?
(In reply to comment #12) > Looks like seamonkey-council doesn't get mail for changes of those fields, but > we do for the other flags. Is that normal for those custom fields? Indeed, that is normal. If you want to file a bug requesting that feature be added, feel free, but I'm not sure when I'll have time to write it. One creative thing you could do is use whines to get a similar effect.
Thanks, good to know. I have http://dev.seamonkey.at/#radars display counts of and links to the relevant bug lists, but I appreciated getting council mail for those changes with the real flags to be fast to react. Meanwhile, I also realized the custom fields don't show who actually requested a flag, which is also handy with the real flags, but I guess even harder to implement with those fields. I'll file a bug at least on the "send mail on changes" things, even if just as a reminder of something that would be nice to have.
Oh, forgot to note in the last comment, I now did triage all old flags we retired for this and it looks like those new flags nicely work as promised. Thanks a lot!
Status: RESOLVED → VERIFIED
As a note, bug 562102 filed on the "send mail on changes" for custom fields.
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.