Change request approval bug
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-07-2022 04:02 AM
I found a bug in the change request approval logic when requiring concurrent group and manager approvals for the Assess stage. If the manager approves after the group, the group approvals are set to "No longer required" and the ticket doesn't progress to the Authorise state. It makes no difference whether there is one or multiple groups and whether the manager is in the group or not. If the manager approves first, the process works correctly. Has anyone else experienced this issue and managed to resolve it?
Steps to reproduce:
1. Change the "Normal Change Policy" -> "Low risk manager approval" to only have "change request.state is Assess" as the condition
2. Raise a Normal change request
3. Approve for a member of the approval group
4. Approve for the manager
5. The state remains at Assess; the group approval is set to No longer required
I raised a case and the support person claimed it was down to our customisations even though I've reproduced this in a PDI (screenshot attached). I've tried to trace through the out-of-the-box approval logic, hoping to identify the bug, but it's a maze.
- Labels:
-
Instance Configuration
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-07-2022 04:10 AM
Hi Pauline,
Can you share the screenshot of the workflow? I reckon using approval coordinator activity will resolve your issue. Rather than having 2 different approval activities
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-08-2022 02:13 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-08-2022 04:56 AM
For info in case anyone else encounters this, I finally implemented a hack. I created a dummy group containing a dummy user and changed the decision to pull in that group. A business rule then changes the assignee on the sysapproval_approver record when it is created. I've used this approach as I couldn't debug the OOB code and this is a light-touch solution which can easily be removed if/when the bug is fixed.