Idea ID: 2877709

Impact of AccuRev Merge/Patch on Closed AccuWork Issues - Violates Quality System - Audits

Status: New Idea

  When a developer merges or patches file(s) within AccuRev there can be a consequence of that action that can impact the our quality system.  If during the merge/patch operation, the file(s) have an associated AccuWork/Jira Issue, the  Issue within AccuWork is updated with the new resulting version of the file(s). This happens regardless of the Issue’s state,  possibly being  “Closed” / ”Done”.  If the Issue is “Closed” / ”Done” this violates our quality system.

     This is not new functionality of AccuRev. We have been working around this problem by manually removing the offending file versions from the AccuWork Issue. However this is a band-aid, not a solution.


 When a file is merged or patched in AccuRev, three items are updated:

  1. The file’s contents are merged/patched, based on the developer’s choices. The AccuRev Principal/User is in control.
  2. The file’s history and ancestry lines are updated, as seen in the Browse Versions, with the two contributing versions / nodes (and potentially their ancestral nodes) coming together to the newly created merged/kept version. The AccuRev software is in control.
  3. For the contributing versions/nodes, if they have Jira / AccuWork Issues associated, these Issues are found on the merged or patched/kept version/node. The AccuRev software is in control.


   What is of concern with AccuRev’s merge and patch functionality, is point 3 above.  For those Issues that are in a terminal state (“Closed” or “Done”), they will have their Change Packages updated as part of the merge or patch. From our perspective,  Issues in a terminal state must not be changed. These Issues have gone under extensive peer review and testing.  Modifying these Issues subjects us to audit failures, both internally and via external governmental agencies.


   We need a solution that puts step 3 in our control. If the Issue is in a terminal state, then the below four choices could be suitable solutions:


  1. Have AccuRev check the Issue’s state, and not update Issues that are in a terminal state.  This would require changes to the AccuRev Schema, so that it would be possible to tag fields that are required to be checked and the fields’ values. 
  2. Honor the Change Package Trigger on Merge and Patch.  If the Issue(s) are valid in the CPK Trigger, then update the Issues as merge and patch does now. Otherwise, the action taken by the AccuRev software in step 3, is bypassed and the Issue is not updated.
  3. Create a sister trigger to the CPK Trigger, called the Merge/Patch Trigger, and provide Queries and Actions.
  4. Warn the user, before the merge/patch allows the AccuRev Principal/User to make any changes,  that the resulting merge/patch would impact a list of Issues. Provide  mitigating steps, possibly putting new versions/nodes into the workspace and ‘merged from’ stream that have no Issues associated, then have the user retry the merge/patch after they complete those steps.