Bug 1157998

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.

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)

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.

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.