Open Bug 353690 Opened 18 years ago Updated 9 years ago

Allow flags to have customized states

Categories

(Bugzilla :: Attachments & Requests, enhancement, P3)

3.1.3
enhancement

Tracking

()

People

(Reporter: mconnor, Unassigned)

References

(Depends on 2 open bugs)

Details

(Whiteboard: [wanted-bmo])

Attachments

(1 file)

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?
Assignee: general → attach-and-request
Severity: normal → enhancement
Component: Bugzilla-General → Attachments & Requests
OS: Windows XP → All
Hardware: PC → All
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.
Whiteboard: [wanted-bmo]
Target Milestone: --- → Bugzilla 3.2
Making the bug summary a little bit more self-explanatory.
Summary: Needed changes to support Fx3/1.9 → Allow flags to have customized states (needed changes to support Fx3/1.9)
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.
Flags: blocking3.0?
Target Milestone: Bugzilla 3.2 → Bugzilla 3.0
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.
Flags: blocking3.0?
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
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.
Blocks: 335151
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
Assignee: attach-and-request → justdave
Component: Attachments & Requests → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
QA Contact: default-qa → myk
Target Milestone: Bugzilla 3.2 → ---
Version: unspecified → other
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.
QA Contact: myk → reed
OK, I changed my mind after my discussion on IRC with mconnor today and I'm going to implement this upstream, in Bugzilla 4.0.

What I'm going to do is:

- Move the inclusion/exclusion list feature from FlagType.pm into Field.pm. This can be done in the backend without altering current behavior. So it have its own patch.

- Move the group-controled  feature from FlagType.pm to Field.pm. This can also be done in the backend without altering the current behavior. And would also have its own patch.

When this is implemented, all fields should be able to use them, i.e. have an inclusion/exclusion list and be group controled. This would also mean having field values per product/component.

- Replace all unset flags in bugs by a single drop-down menu, listing all active and legal flags for this bug. When one is selected, its legal values are displayed, which you can select. At the same time, JavaScript would add a new drop-down menu with the same list of flags so that you can immediately set another flag, and so forth. If JS is disabled, only one (or maybe two) drop-down menus would be displayed, which means you could only set one (or two) new flag at once. Of course, all already set flags would be in their own place in the UI, as flags are currently.

- Keywords would all be killed and be morphed into a flag type with only one legal value: "+", as a keyword can currently only be present or not (you cannot even negate a keyword, i.e. change "regression" into "not a regression", so the "-" value would be useless here). Maybe I would still use "+"/"-" as we have now, I will see.

So at this point, keywords would no longer exist *at all* in Bugzilla. This also means keywords (now: flags) would now be group-controlled, can be per-product/component and can be marked as obsolete, which means that bugs which currently have obsolete keywords would keep them, but you cannot add this keyword to bugs which don't have it yet (as for flags currently).

- The search form UI would need to be updated to remove keywords and add a section for flags, whose importance is big enough to not be limited to boolean charts. The idea is that you can query for flags as easily as you can for keywords currently.

- A final step would be to be able to mark a single value for a given flag type as obsolete, instead of the whole flag type. This can be done much later, eventually.

At this point, flags would share so much code with custom fields that they could be seen as a new custom field type. You could still be able to request someone (specifically) as you can now, and you would still be able to set flags on attachments, making it a very special "custom field".


I think I detailed everything. :) I will set dependencies when I have a little bit more time. Several of the RFEs describes here already have a bug filed some time ago.
Assignee: justdave → LpSolit
No longer blocks: 335151
Component: Bugzilla: Other b.m.o Issues → Attachments & Requests
Priority: -- → P1
Product: mozilla.org → Bugzilla
Whiteboard: [wanted-bmo] → [wanted-bmo] [roadmap: 4.0]
Target Milestone: --- → Bugzilla 4.0
Version: other → 3.1.3
QA Contact: reed → default-qa
Depends on: 261181
(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.
Whiteboard: [wanted-bmo] [roadmap: 4.0] → [wanted-bmo]
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:

blocking1.8.0.15
wanted1.8.0.x
blocking1.8.1.15
blocking1.8.1.16
wanted1.8.1.x
wanted1.9.0.x
blocking1.9.0.1
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/1.9.0.1/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.
Priority: P1 → P3
Assignee: LpSolit → attach-and-request
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.
Target Milestone: Bugzilla 4.4 → ---
Summary: Allow flags to have customized states (needed changes to support Fx3/1.9) → Allow flags to have customized states
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]
You need to log in before you can comment on or make changes to this bug.