Bug 1157998 - Update Rules Engine docs to explain how rollback interacts with multi-value fields
Summary: Update Rules Engine docs to explain how rollback interacts with multi-value f...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Bugzilla
Classification: Community
Component: Internal Tools
Version: 4.4
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: PnT DevOps Devs
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks: 1201607 1266813
TreeView+ depends on / blocked
 
Reported: 2014-10-28 08:54 UTC by Rony Gong 🔥
Modified: 2017-01-17 03:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-17 03:52:10 UTC
Embargoed:


Attachments (Terms of Use)

Description Rony Gong 🔥 2014-10-28 08:54:26 UTC
Description of problem:
Roll back will just add back origin keywords but the rule action is set keywords

Version-Release number of selected component (if applicable):
4.4.6026

How reproducible:
Always

Steps to Reproduce:
1.Create a rule rule_1 with some criterion:
Classification is 'Red Hat'
Product is 'OpenShift Online'
Status is 'POST'
Component is 'Cartridge'

and actions include:
Change the Status field to 'ASSIGNED'
Change the Keywords field to 'CommonBugs'.  

Then submit this rule and add those matched bugs to the queue, let rule could hit bugs.(this rule could hit a bug bug_1 whose keyword value is "CodeChange")
2.Wait some minutes, update a bug bug_1 that already hit by rule_1 , set keywords to AutomationBlocker
3.Then I want roll back this change of rule rule_1 in the during the time of step 1, go to the roll back page
4.select rule rule_1 and check checkbox "Rollback even if the bug has since changed", input the duration time of step 1
5. Click button "Rollback rule changes"
6. Check the bug bug_1's keywords after the roll back hit bug_1
Actual results:
bug_1's keywords value is: AutomationBlocker, CodeChange

Expected results:
bug_1's keywords value is: CodeChange,  since the keyword value of bug_1 is "CodeChange" before the time of step 1.
Additional info:

Comment 1 Jason McDonald 2014-10-30 11:36:14 UTC
This behaviour is as designed.  Simon and I discussed this aspect of the design at length on several occasions, and I am satisfied that Simon's design is a reasonable way to approach a problem that has no perfect solution.

The rollback feature is a "best effort" and is not expected to be perfect in the case that a user has edited bugs between a rule making changes and the rollback attempting to reverse those changes, nor if the rule changed certain fields that we guarantee will never be deleted.

The rollback reverses as much of the activity log as it can and skips the bits that don't make sense anymore due to changes made by other users after the rule was applied, and also skips the bits that would violate data retention policies.

In the case above, the rollback reverses the change that removed the CodeChange keyword, as doing that still makes sense, but skips attempting to reverse the addition of the CommonBugs keyword because that keyword is no longer on the bug.  The rollback also ignores the AutomationBlocker keyword, because that keyword was not touched by the rule that is being rolled back -- the history says "rule_1 added CommonBugs and removed CodeChange", so that's all the roillback will attampt to reverse.

To put this another way, the "Rollback even if the bug has since changed" feature is only supposed to reverse changes made by the Rules Engine, and intermediate changes made by other users should be unaffected whenever possible.

A better example of why this "best effort" approach is the correct design is comments.  If rule_1 is applied to a bug and then I later add a comment to that bug, a subsequent rollback of rule_1 should not delete my comment.  In fact, if the comment was deleted, we would be violating the Bugzilla data retention policy, which guarantees our customers that (among other things) comments are never deleted.  That guarantee is critical for ensuring that syncing between Bugzilla and many external tools can be done in an optimal fashion without repeatedly downloading data that is guaranteed never to change.  If the rollback feature was allowed to delete comments, many external tools that sync data from Red Hat Bugzilla would break.

Comment 2 Rony Gong 🔥 2014-10-31 02:17:40 UTC
Then below sentence need be update, I filed this bug obey this sentence:
If the fields modified by the rule were edited by a user after the rule ran, then performing a rollback with the "even if the bug has changed since" checkbox enabled will result in the user changes being overwritten with the values from before the rule ran. All the changes will remain in the history of the bug. 
It list in the rule engine help document(/docs/en/html/rule-engine.html)

Comment 5 Jason McDonald 2015-11-11 01:57:08 UTC
Returning this task to the backlog as I've been given some new priorities that will prevent me making progress on this for the foreseeable future.

Comment 6 Matt Tyson 🤬 2017-01-17 03:52:10 UTC
The rollback function has never been used in production and we don't have the time or resources to maintain and QE it.  Therefore the rollback feature will be removed.  See bug 1413820.


Note You need to log in before you can comment on or make changes to this bug.