Bug 206203 - Implement is_deletable flag attribute for "flag can't be undefined once it has a defined value"
Summary: Implement is_deletable flag attribute for "flag can't be undefined once it ha...
Status: Open
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Many People
Assignee: Mahdi Mokhtari
URL: https://bugzilla.mozilla.org/show_bug...
Keywords: dogfood, easy, feature, needs-qa, patch
Depends on:
Blocks:
 
Reported: 2016-01-13 14:51 UTC by Kubilay Kocak
Modified: 2018-05-23 10:27 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kubilay Kocak freebsd_committer freebsd_triage 2016-01-13 14:51:29 UTC
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
Comment 1 Mahdi Mokhtari freebsd_committer freebsd_triage 2016-01-21 10:27:58 UTC
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
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-23 10:27:05 UTC
batch change of PRs untouched in 2018 marked "in progress" back to open.