Create Rules extension to replace hard coded edit rules currently in BMO bug_check_can_change_field hook
Categories
(bugzilla.mozilla.org :: General, enhancement)
Tracking
()
People
(Reporter: dkl, Assigned: dkl)
References
()
Details
(Keywords: bmo-goal)
Expressing rules as code is not ideal. Code has to be changed, reviewed, committed and then wait for the next deployment. This can take quite a bit of time. The current code resides in extensions/BMO/Extension.pm in the bug_check_can_change_field() function[1]. A better way would be for an empowered user be able to write rules in a structured format language and be able to submit them using an admin UI causing the changes to take affect immediately.
Dylan started this using a proof of concept PR[2] which gets us some of the way there [1]. I am going to finish this up and extend it to allow using YAML for the rules definition. The YAML must be validated before saving and also should not cause any performance slow down of the system.
Proposed YAML stucture:
rules:
- desc: Deny if new bug page, product is Firefox, field is priority and not in editbugs group
condition:
new_bug: true
product: Firefox
field: priority
not_user_group: editbugs
action: deny
- desc: Deny if show bug, product is Firefox, field is assignee, and not in editbugs group
condition:
product: Firefox
field: assigned_to
not_user_group: editbugs
action: deny
- desc: You need at least canconfirm to mark a bug as FIXED
condition:
field: resolution
new_value: FIXED
not_user_group: canconfirm
action: deny
We will need to extend this as more selective criteria is needed. Current hard coded rulesinitially would be moved over to the new format and removed from the BMO extension. Some of the hard coded rules may be too complicated and would not fit in and would be left in place.
[1] https://github.com/mozilla-bteam/bmo/blob/master/extensions/BMO/Extension.pm#L572-L674
[2] https://github.com/mozilla-bteam/bmo/pull/985
Assignee | ||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
I have two nits with the yaml structure:
- conditions should be grouped under the same key, so each rule only has three keys: desc, condition, and action. It'll read better.
- I would avoid using
!
as it can be used for tagging in YAML.
Assignee | ||
Comment 2•6 years ago
|
||
(In reply to Dylan Hardison [:dylan] (he/him) from comment #1)
I have two nits with the yaml structure:
- conditions should be grouped under the same key, so each rule only has three keys: desc, condition, and action. It'll read better.
- I would avoid using
!
as it can be used for tagging in YAML.
Thanks. Should we hash out the format in google docs or better to make a working prototype and work on it in the github PR?
Comment 4•6 years ago
|
||
Can we try making a prototype with the structure you proposed?
How can we make this consistent with the structure for tracking flags? It'd be good to not have two permissions systems for fields.
Comment 5•6 years ago
|
||
(In reply to Emma Humphries, Bugmaster βοΈπΈπ§ββοΈβ¨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #4)
Can we try making a prototype with the structure you proposed?
How can we make this consistent with the structure for tracking flags? It'd be good to not have two permissions systems for fields.
Tracking flags are only group based, and this is based on arbitrary boolean predicates so I'm not sure how that would look
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
Closing bug. Rules extension no longer being worked on. Workflow changes will be handled in the code as needed.
Description
•