347835 - flags should be groupable

Status: UNCONFIRMED

(Bugzilla :: Attachments & Requests, enhancement)

Description

[timeless]

This is getting annoying. I'm tired of having to disable both blocking and approval.

I should be able to:
1. define a flaggroup "1.8.0.6" <- this bug
2. define a bug flag in the group named "blocking{groupname}" <- this bug
3. set the description to "set {flagname} for gecko {groupname}" <- already filed by me
4. define an attachment flag in the group named "approval{groupname}" <- this bug
5. set the description to "set {flagname} for gecko {groupname} ..." <- already filed by me
6. mark the active option on the flag group <- this bug
7. wait a while (say 2 weeks)
8. copy the flag group to "1.8.0.7" <- this group
9. clear the active option on the flag group <- this bug

6/9 will cascade to the members of the flag group.
8 will result in 2 new flags in addition to the new group.

I'm not sure if I want to restrict flags to a single group. there could be uses for not, so as an implementation guide, please don't constrain the impl to require a 1->many mapping from flaggroups to flagtypes.

When I edit a flag group, instead of getting checkboxes, i need list boxes.

[ Doesn't override ancestor group (default) |v]
| Doesn't affect grouped items                |
| Require unset                               |
| Require enabled                             |
| Set inherited to unset                      |
| Set inherited to enabled                    |

as an implementation simplification, it might be sufficient to only allow single inheritance for flags (flagtype appr1806 inherits from 1.8.0.6 inherits from defaultgroup). The shipping default group would have "Set inherited to unset"

"Doesn't override ancestor group" would basically mean "inherit ancestor setting". The wording here is subject to negotiation.
"Doesn't affect grouped items" means that any ancestor setting is not inheritted and the flagtype itself isn't affected by this ancestor. This option might not make sense and is probably equivalent to "Set inherited to unset"
"Require unset" would force a flagtype to not have the checkbox set.
"Require enabled" (Require set?) would force a flagtype to have the checkbox checked. I'm not sure what should happen for a flaggroup (i.e. should it not be 
able to override an ancestor), I don't think I care.

Obviously there should be copy, and rename options for flaggroups.

I'm not sure about delete. I'll leave handling or specifying that as an implementation decission :).

Note that for lists of users (cc list) and such, the list of options is more interesting. In fact, you should get two sets.
[ ] Inherit [                     ]
[ ] Remove  [                     ]
[ ] Append  [                     ]

To replace a list one simply doesn't check inherit and does check append. to substitute one user for another, one should check remove and enter a name (copied from the inherit list) and checks Append and enters a replacement.

The fields will of course allow multiple accounts (comma/space delim?).