Basically, the changes we're looking to have in b.m.o (but should be generically useful) is the idea of having flags with arbitrary values that can be managed and hidden in the same way as flags. The goal is to allow us to consider and accept bugs for more than just blocking/not blocking, but to fill in some of the grey areas, without using keywords or other globally-editable fields, or a large number of flags. To make this clearer, I'll provide an example of the values we'd want for a "firefox3-radar" flag: blocks-final blocks-a1 wanted would-take-patch requested (nomination state) would-not-take At some point before a1, we'd need to add blocks-a2, Then, once a1 shipped, we'd want to make that option inactive (i.e. existing bugs wouldn't change, but we wouldn't see that value otherwise, or be able to set it). The goal is to avoid a multitude of flags, and have a number of manageable states for bugs that are nominated.
Now the question is: should this be part of the Bugzilla code or only a hack for b.m.o?
I think its a generally useful feature, so it should be in Bugzilla, but I think we need this ASAP, so it needs to be backportable to whatever we're upgrading b.m.o to next.
Making the bug summary a little bit more self-explanatory.
OK, we need to have this included in b.m.o when we update on Dec 26th. It's on my plate to implement, but I'm having a hard time grasping exactly how this would work... Also something to think about is that 3.0 (the version we're taking) now has custom field support for text entry and select box types. This almost feels like something that would work good as an additional select box field on the bug.
Dave - are you unsure of what's being asked for or unsure of how to implement? How does a an optional select field on a bug differ from a flag?
This won't go into 3.0. We are frozen to prepare 3.0 RC1 and all enhancement bugs are retargetted to 3.2. If guys at MoCo want it for b.m.o, they can implement it locally, as they did for some other bugs already. schrep, the difference is that select fields do not send any notification (except the usual bugmail you get when doing changes in a bug) and has no requestee field. justdave, if you want to implement it as a select field, you would need something like: <some field name>: blocking-Fx3 | wanted-Fx3 | requested-blocking-Fx3 | requested-wanted-Fx3 | would-not-take | ... Moreover, note that any user with editbugs privs, assignees and QA contacts can freely edit this field, unless you hack Bugzilla::Bug->check_can_change_field too. Not sure that's the best approach.
ok, so I'm guessing we probably want go ahead and hack up the flag mechanism for this still then. Schrep: kinda both... I think I know what you want, just trying to make sure so I don't go running off the wrong way trying to do it. LpSolit: yes, I know it won't be in 3.0. :) It'll be a local hack on b.m.o when we upgrade, and *if* I can do it cleanly enough we'll aim for 3.2 getting it upstream, otherwise it'll just stay as a local hack. The thing that bothers me right now though is that the flag status is a 1 character field in the database. Schrep / mconnor: do you guys ever forsee having more than 10 statuses on a single flag? I could probably make them numerical (0 to 9 or something) in addition to the existing [ ?+-] on the back end and do so UI magic of some sort to make them readable in the UI.
(In reply to comment #7) > LpSolit: yes, I know it won't be in 3.0. :) My comment was for vladd who retargetted the bug from 3.2 back to 3.0 and requested blocking3.0.
I think we could easily have more than ten statuses. Based on current strawmen, we're looking at something like the following list (ideally not all would be visible at once, i.e. a3-b3) blocking-a2 blocking-a3 blocking-a4 blocking-b1 blocking-b2 blocking-b3 (maybe) blocking-final wanted would-take-patch requested would-not-take I don't think we want to have an arbitrary limit here, in any case.
ok, how about 36? Can always throw the alphabet in there, too. And this is a single-select, right? (only one of them can be set at a given time... if it's blocking-a2 and you want blocking-a3, you change it to blocking-a3, it doesn't add that to it) We're opening a whole can of UI worms if you want it multi-select. :) For admin UI I'm envisioning a link to add a value to a flag, and a table to match the backend symbols to the values you want shown in the UI. It'll need the human readable values in the activity log so it looks readable in mail, too, and search will need to have a table join to pick them up. If anyone has a bright idea how to represent it in the activity log and in the value box in the advanced query, speak up. :) Currently we do something like these: flag+ flag- flag? flag?(requestee) flagblocking-a2 is gonna look funny :) If we add something it might not be very backward-compatible though. I'm not sure if sort order will be adjustable on short notice, that adds a level of complexity to it. We can always add that later if you want it badly. Minimum functionality comes first. I'm going to try to whip this up in the next couple days... we'll need it ready by the end of this week to give time to test it on bugzilla-stage before it goes live.
Wait! What mconnor wants for these special flags is nothing more than a single-select field. This is exactly what I described in comment 6. As I understand it, mconnor doesn't want to let users request or deny anything. If a flag is set to "blocking-b2", it has the same meaning as "blocking-b2+". justdave, in this case, all you have to do is to add a single-select field, and just hack get_can_change_field() to restrict who can change it, if you really want to. And a 2nd hack to list which products should have this field. Said otherwise: if you want to be able to request (?) and deny requests (-), use flags. If you only want to "grant" (+), use a single-select field.
OK, Justin talked to mconnor, and indeed, we don't need requestees available, so the custom field select box will work nicely. So our custom patch only has to control which products is shows up in and who can set it.
This is definitely a b.m.o hack only. -> mozilla.org
OK, I mailed schrep and mconnor asking for a name for the field a couple days ago and haven't gotten a response, so I'll ask here. :) What should the field be named? I called it "Firefox 3 Radar" on bugzilla-test when we were staging it, but I don't want to set it up in production until I get signoff on the name, because once I do it, it's fairly permanent.
(In reply to comment #15) > - Replace all unset flags in bugs by a single drop-down menu, listing all > active and legal flags for this bug. I think that might hurt the usability of flags.
Wow... There is a lot here. This is where LpSolit's thing with flags came from. My 2 cents for what it is worth. I have always seen flags as a way of "signing off", which is why ?,-,+ make sense. you request, approve, reject them. I'm not sure I understand the need for having multiple statuses, and I feel like this feature is being shoe horned into flags because of a lack of a custom field type which is what you actually need? Maybe a better way of explaining it is this. We need for people to be able to request a "sign off" on blocking, but then the signer needs the ability to say Yes I approve, but with the following "approval note" or maybe I reject it for the following reason? The THIRD problem could be more simple and straight forward. Flags are too many to be manageable (VERY TRUE) and we need a way to make them more usable. We wouldn't mind having a bugillion (yeah that's a punn) flags, if they were easier to set. In which case LpSolit's suggestion of flags being drop downs would make sense, but then why would you need multiple statuses for them? I'm not ready to say this would or wouldn't make things usable, but I am happy to say that the need isn't being fully explained on this bug/feature, and the best way (IMO) to design fancy features like this is to first make sure we understand the needs and are meeting them. Lastly this feature will add complexity to Bugzilla's UI (both admin and end user), and by far the biggest complaint about Bugzilla is that it is already TOO complicated, so lets make sure we're 100% sure about this.
Finally not on the roadmap for 4.0 as some people still don't think we should do it.
Ok, let me be clear: Flags are great for signing off on patches/changes. They're not nearly as useful for release management. It is rare in our world that everything is black and white, so a yes/no flag is of little value. We have to resort to trusting world-writeable fields like target milestone, plus multiple flags, in order to track the various types of bugs we want to track. So, fine, we don't want a "flag" in the traditional sense. We want a field that's a dropdown, like a flag, with access restrictions, like a flag, that is requestable, like a flag. The key difference is that instead of having multiple flags (i.e. blocking 1.8b3, b4, b5, RC1 + wanted1.8.1.x) with single bit flags, we want to have a single controlled field per branch. The Firefox component, right now, has: blocking220.127.116.11 wanted1.8.0.x blocking18.104.22.168 blocking22.214.171.124 wanted1.8.1.x wanted1.9.0.x blocking126.96.36.199 blocking‑firefox3 wanted‑firefox3 What we would have, instead of all of these flags, is: 1.8.0 branch [blocking .15/wanted/nominated/not wanted] 1.8.1 branch [blocking .15/.16/wanted/nominated/not wanted] 1.9.0 branch [blocking 1.9/188.8.131.52/wanted/nominated/not wanted] which gives us per-branch "flags" that are more explicit, and can have values added/expired as we go along, so we don't need to migrate flags, or go through repeated renominations on the same branch, etc.
(In reply to comment #20) Yeah, that's a need I completely understand. It's definitely not limited to Mozilla, although Mozilla has even greater need of it than most other organizations. The solution, I believe, is more in bug 55970 than in custom states for flags--once Bugzilla understands the concept of a "branch", these things start to fall in line much more easily. Although custom states for flags *would* solve this problem in the short term, it would add a lot of complexity to some already *really* complex code, which might not be so maintainable in the long term, whereas the branch-based solution would become an integral yet simple part of Bugzilla with even greater flexibility than custom states for flags.
Note that a flag with custom states is just a custom field of type "single-select menu" with the ability to define it per product/component (bug 371995) and with group restrictions (bug 372017). At that point, there won't be a lot of differences between traditional flags (what we have currently) and flags with custom states. At some point in the future, I could even imagine flags to be a special kind of custom fields (very far in the future...).
(In reply to comment #22) > Note that a flag with custom states is just a custom field of type > "single-select menu" with the ability to define it per product/component (bug > 371995) and with group restrictions (bug 372017). And requestability, and multiplicability, and not just group restrictions but grantgroup and requestgroup separately (something normal fields will never have) and a CC list, and the ability to be on attachments.
Just a side comment/suggestion on how to make this a bit easier to use.. maybe.. have flag types or "state sets" that users can create and apply to flags. I'll make some mock ups of this. The idea is that if users want to use these states they can activate and apply them, but otherwise flags act just how the do now. I feel like this feature is a more advanced and might confuse some users, but defiantly needed.
(In reply to comment #24) > I feel like this feature is a more advanced and might confuse some > users, but definitely needed. "More advanced" and "might confuse some users" is something we don't need any more of in Bugzilla, really. Also, I think the branches feature will handle the needs of Mozilla (even better than this would) so I don't see a particular use case for this.
(In reply to comment #25) > Also, I think the branches feature will handle the > needs of Mozilla (even better than this would) so I don't see a particular use > case for this. We first have to see how bug 55970 is implemented before saying this one is useless.
(In reply to comment #26) > We first have to see how bug 55970 is implemented before saying this one is > useless. Sure, I'd agree to that. But let's do bug 55970 before we do this.
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.
Created attachment 8596078 [details] [diff] [review] flagstatusdescriptions.diff After being pointed to this Bug from Bug #1157208, I'd like to provide a working implementation of expressive flag status descriptions for users. After reading through the comments, one of the major issues I see with the "allow any sort of status" idea of flags is that they become far too ambiguous, which complicates user interaction and will cause flags to be less clear and expressive. As some people pointed out, I consider flags as "sign-off" method for certain actions, specifically requesting something (from someone). As such they can complement status transitions (prerequisites fulfilled), tell users to do something (feedback requests, test runs, etc.) and indicate, if certain actions have been done to help solving a bug or feature (e.g. test case implemented, documentation done; a gate mechanism). Within that context, 4 flag status values (unset, requested, approved/granted/yes/..., denied/rejected/no/...) are sufficient. The attached patch complies to that approach in so far as that it will give administrators the ability to provide context-specific details about the states. Users on the other hand will be able to identify the actual meaning in a specific flag context without having to read and interpret all the information about the flag itself beforehand. As such, the patch is a cosmetic extension of the current mechanism, not more, not less. Changes to the search were not considered for the following reasons: * Searching for flags uses a non-intuitive notation for Joe User via the default search interfaces at the moment. * Flag descriptions may change over time, if the description is found to be unclear or not exact enough - causing such a UI change to influence pre-defined searches, reports and other internals is a no-op for installations with large user base and additional third-party system integration. The search UI however could be extended to search for flags more easily, utilizing the descriptions, while still searching internally with the correct values. This would require an additional section in the search interface, which enables users to search for flag/status (description) combinations without using the abbreviated syntax. Having said this, there is an internal set of states (indifferent, whether it is extensible or not), with a UI-visible mapping of human-readable translations. You can see the patch in action on the following screenshots: attachment #8595937 [details] attachment #8595938 [details] attachment #8595939 [details] attachment #8595940 [details]