Bugzilla flags are a custom 4-state attribute of bugs and/or attachments. These states are: granted (+), denied (-), requested (?) and undefined (not set) Further, when creating a new Flag via Administration -> Flags, there are additional attributes that affect the capability and/or behaviour of the flag in use: [ ] active (flags of this type appear in the UI and can be set) [ ] requestable (users can ask for flags of this type to be set) [ ] specifically requestable (can be set to request a *specific* user) [ ] multiplicable (multiple flags of this type can be set on the same bug) These four attributes, at new flag creation time, default to [X] (enabled). Currently, anyone with editbugs permissions or the reporter or assignee of an issue, can set a flags value to its *undefined* or *empty* state, even when it is not optimal to do so. A couple of examples include: A maintainer unsetting the maintainer-approval flag value (empty/undefined) instead of to + or - (meaning approved, denied) A committer unsetting the merge-quarterly or mfc-stableX flag value (empty/undefined) instead of to + or -, meaning respectively, committed/dont (+) or denied/not-needed (-) This results in lost tracking value, where it is more useful and valuable for the state of an issue to be additive (or cumulative), rather than subtractive. This issue is for the implementation of a new "Flag Attribute" that allows an Administration to specify whether a Flags value, once defined, can not be undefined. More precisely (in horrible pseudocode), it would be defined in behaviour as: IF (flag->setting[name-of-flag] == X) AND current_flag_value != NULL AND new_flag_value == NULL DO stuff To summarise the behaviour of this new attribute simply, it would mean: adj. not able to be erased, indestructible Some words that were identified that come close being able to describe the functionality of this new attribute. They include: permanent, indelible, perpetual, interminable, indeliable, durable, fixed, constant However, since all flag attribute values default to ENABLED when creating a new flag, the new "flag attribute" should be named so as to describe the CURRENT default behaviour of flags, if the behaviour was enabled. Thus, this new attribute (likely) needs to be named the opposite of the above terms, and also be enabled by default. Some ideas for attribute names include: removable, ephemeral, transient, temporary, destructible In terms of what actions/behaviour could or should take place when this condition is checked/matched, we want to make it consistent with other error conditions that Bugzilla produces when an action is taken that is not allowed, including the manner in which, and method that is used to display the result/error. Actions may include: * Displaying a relevant error using an existing (error?) template
The first draft of our patch (that adds this feature to Bugzilla-core) is created. And has been attached to Mozilla's Bugzilla (BMO) issue (its link is in URL:). Now waiting for their reviewers to review (and if any edits needed we'll edit), and finally they approve it ;D
batch change of PRs untouched in 2018 marked "in progress" back to open.
^Triage: assignee's commit bit was taken in for safekeeping some time ago.