1524700 - Create Rules extension to replace hard coded edit rules currently in BMO bug_check_can_change_field hook

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: General, enhancement)

Description

[David Lawrence [:dkl]]

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

Comment 1

[Dylan Hardison [:dylan] (he/him)]

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.

Comment 2

[David Lawrence [:dkl]]

(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 3

[David Lawrence [:dkl]]

Need feedback from Emma as well.

Comment 4

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

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

[Dylan Hardison [:dylan] (he/him)]

(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

Comment 6

[David Lawrence [:dkl]]

Closing bug. Rules extension no longer being worked on. Workflow changes will be handled in the code as needed.