The solution provided here can, of course, be expanded and customized with different designs. The key is to understand and convey the underlying logic. First, a request form is designed on the Customer Portal as follows:
Next, if the user selected as the "Coverer" meets the necessary criteria while the issue is in the approval status, they are added to the "Approvers" field using a rule like the one below:
lookupIssues:
"Request Type" = "Out of office request (IT)" AND statusCategory != Done AND "Start date[Date]" <= startOfDay() AND duedate >= now() AND reporter ="{{issue.customfield_10003}}"
P.S: In this case, {{issue.customfield_10003}} is User field - Actually, the real name of this field is User, but I've listed it as Coverer Approver on the portal side. It needs to be the same field as the User in {{lookupIssues.User}}, which is the last step in the automation process.
For those provisioning their users from an idp, and are provisioning the Manager attribute, it is possible to use .manager in smart values referencing user fields.
It only returns the UUID of the manager and doesn't go any deeper than that, but for editing fields through automation that is good enough.
It could be something along the lines of:
Trigger:
Scheduled - Every X days
IF Status = Manager Approval
IF status changed Y days ago*
Edit work item - Approver --> {{approver.manager}}**
*The {{Request Type.currentStatus.statusDate.jira}} value used in this example is only available for JSM it seems.
**In our site Approvers = customfield_11700
In your case, manager escalation is working. But in the situation I'm describing, a user manually selects the backup approver for their desired date range.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Nice solution.
Still I would move the conditions from the trigger ot the rule, as this has proved to cause timing issues.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Marc -Devoteam- Hello,
This process varies depending on the approval design and can, of course, become more complex.
But as the name suggests, this is a "workaround solution". Hopefully, Atlassian will include this as a default in the product.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.