453279 - replace long list of available settable flags with 3 settable flags

Status: RESOLVED DUPLICATE of bug 424215

(Bugzilla :: Attachments & Requests, enhancement)

Description

[timeless]

currently bugzilla shows in flag-sort-key order all flags that could possibly affect any component in the current product for the current bug or potential (i.e. new) bug.

in bugzilla product, that means today as of this filing, i have:
approval [ |v]
approval3.2 [ |v]
blocking3.2 [ |v]
approval3.0 [ |v]
blocking3.0.6 [ |v]
approval2.22 [ |v]
blocking2.22.6 [ |v]
approval2.20 [ |v]
blocking2.20.7 [ |v]
documentation [ |v]
documentation3.2 [ |v]
documentation3.0 [ |v]
documentation2.22 [ |v]
documentation2.20 [ |v]
testcase [ |v]
needsinfo [ |v]

in firefox/core, it's actually worse.

what i'd like instead is:
1. incomplete flags (this will only happen as the result of a submission)
2. show all currently set flags (in flag-sort-key order)
3. show 3 additional potential flags (with all settable flags in flag-sort-key order):

<select id="new-flag-1-name">
<option>approval
...
<option>needsinfo
<option value="" selected>add a flag
</select>
<select id="new-flag-1-state">
<option> </option>
<option>?
<option>+
<option>-
</select>
<input id="new-flag-1-requestee">
<br>

and the same for flag-2 and flag-3

in the case where javascript is enabled, setting flag-3 should add an additional flag-4 that looks like flag-3.

optional (bonus points):
if js is disabled, a scrollable box should be available which lists each flag, the components to which it applies, whether it can be set to -/+ and whether it's specifically requestable

on submission, if the flags as set, e.g.

[blocking3.2     |v][?|v][    ]
[documentation3.2|v][?|v][    ]
[needsinfo       |v][?|-][    ]

are all valid, the flags should be set:
setter:blocking3.2?
setter:documentation3.2?
setter:needsinfo-

if there are flags which aren't valid, they should be treated as non fatal errors (this should only happen in the no js case) with a warning at the top of the page listing the flagname, the requested flag value, and the requested requestee, along with an indication as to why the tripple isn't ok.

if a requestee is specified and the flag doesn't support a requestee, the flag should be set anyway.

so
[blocking3.2|v][?|v][[e-mail]]

should become:
setter:blocking3.2?

with a warning that "the blocking3.2 flag isn't specifically requestable, so [e-mail] was not filled in."

if a flag is set to a value that isn't legal:
[blocking3.2|v][+|v][    ]

then a warning "you are not in the group which can set the blocking3.2 flag to +." if the bug is being shown again to the user (either it's a new bug, or the user is set to show the same bug after making changes), then an extra row in the flags table should be provided:

1. incomplete flags (this will only happen as the result of a submission)
2. show all currently set flags (in flag-sort-key order)
3. show 3 additional potential flags (with all settable flags in flag-sort-key order)

this flag could not be set:
       blocking3.2     <select id=blocking3.2><option selected><option>?</select>
setter:documentation3.2[?|v]
setter:needsinfo       [-|v]
      [add a flag     ][ |v][        ]
      [add a flag     ][ |v][        ]
      [add a flag     ][ |v][        ]

--
I'm pretty sure i've described this somewhere before, but i can't find it :(. it might be on viper.

Comment 1

[timeless]

i spoke with lpsolit and we clarified the only bits he was concerned about:

if javascript is enabled there only needs to be 1 blank flag instead of 3, and of course w/ js that flag should automatically change the values of the flag state to legal values and show/hide the requestee as appropriate.