Out Of Office in Jira (part 2)

[#1]

This article is the second part of the article you can find at this link. I described in it how to implement an Out Of Office assistant in Jira using built-in capabilities. However, the solution presented there have some quite significant functional limitations. First of all, it only allows for one coverer, regardless of the project. Such implementation rarely meets the actual requirements. We often work on several projects simultaneously, in different teams, and one coverer may not be enough. The second limitation is that you can only add a single absence/unavailability at a time. For example, having two vacations planned, the second one can be added only after the first is finished. In the article below, I will tackle these limitations. Additionally, I will introduce some small improvements to make it easier for users to use the overall solution.

---

Remark: This article only describes the differences from the configuration shown in the previous article. If you would like to implement this configuration, read the first part of the article beforehand!

---

The required change in the solution logic

To meet new requirements, we need to change a little bit the structure of our database. Because users should be able to configure multiple absences simultaneously, the rules can no longer be configured in a single task. We will use sub-tasks for this purpose. Each sub-task will correspond to a single absence for a single project. To configure an autoresponder for one absence, while working on 2 projects, we will just add two subtasks with the same dates, but with different projects selected. If we want to create an autoresponder that should work on all other projects, we will add a subtask with no project selected. In such a case, this rule will be applied to all situations where there is no more detailed rule configured. This configuration will allow you to configure multiple absences at the same time. We can just add multiple subtasks with different dates.

Project modifications

Issue type scheme

First, let's modify the Issue type scheme by adding a Sub-task.

Workflows / Workflow scheme

Then, we need to create a new workflow for sub-tasks. There are no requirements here. For the purpose of the article, the workflow will consist of only one status "To Do". We will not focus on its configuration - ultimately you can implement some excellent features here like automatic rule deactivation after some time or a rule approval process.

The workflow associated with the Task issue type requires only a few modifications - I suggest changing the name of the transition used to configure OOO to "Add OOO rule" and modifying the screen attached to this transition.

From the screen, we will remove the "Auto assign" field which will be replaced with a more functional alternative. We will add two new fields to this screen:

• Related project - a new custom field of the Project Picker type indicating the Jira project on which the rule should apply
• Options - new custom field of Checkbox type with a new context for OOO project with options Send an e-mail (default option), Add comment, Reassign the issue. This field will define the operating mode of the implemented solution. The field allows you to check multiple options.

Additionally, let's modify the Default Value of the Info message field to one that more precisely describes how to fill in fields on this screen:

{panel:bgColor=#deebff}

h4. On this screen, you can configure all your Out-Of-Office rule attributes.\\
----
- The *Start date* and *End date* fields indicate on which dates this Out-Of-Office configuration should be applied.
- Using the *Coverer* field you can optionally select the person who will take care of your tasks during your unavailability.
- In the *Related project* field you can select which project you wish this rule to apply. If you leave this field empty it will apply to all cases which do not have a specific rule configured.
- The *Options* field is used to choose actions performed by this OOO rule on issues assigned to you during your OOO period. Please note that if you won't choose your Coverer the Reassign the issue option won't work properly.

{panel}

The most straightforward way to add new OOO rules may be the standard "Create subtask" button. We will configure an automation rule instead which will be triggered by transitioning the Task using the "Add OOO rule" transition. This automation rule will create the required sub-task. This way we can automatically add an appropriate summary and assignee to the created rule (subtask).

Screens / Screen Schemes / Issue type screen scheme

Before we start creating this Jira automation rule, let's modify the screens used in the Issue Type Screen Scheme assigned to the project:

• All operations for Task have an associated screen with the fields: Summary and Assignee
  
  
• All operations for Subtask have an associated screen with the following fields: Summary, Assignee, Start date, End date, Coverer, Related project, Options
  
  

Field configuration / Field configuration scheme

It is also necessary to alter the "Field configuration" configured in the previous article. We don't use the "Auto-assign" field anymore, so let's set it back to optional, but set the Options field as required to eliminate the "none" option.

Project automation rule - add sub-task triggered by task transition

The new automation will look as follows: (Rule should be configured on the OOO project)

1. Trigger: Issue transitioned - from "To do" status to itself
   
2. Create a sub-task if the project was selected in the Related project field (field id - 10052: you can check any custom field id in the ways described here). Because the project picker field is not fully supported in some Jira Automation components  (for example they are not visible in choose field during issue creation or edit actions) we need to take care of them in a more advanced way shown below: 
   1. "If" block with Advanced compare condition: {{issue.customfield_10052}} does not equal Empty
      
      
   2. Create issue action with the following configuration:
      
3. Create a sub-task if the project was not selected in the Related project field 
   1. "Else" block without any additional conditions
      
      
   2. Create issue action with the following configuration:
      
4. Clean Task fields regardless of the Related project field using the Edit issue action:
   

Automation rule

The last and most important changes are necessary for the multi-project/global automation rule - the one responsible for reassigning issues, adding comments, and/or sending e-mail notifications. Let me break this rule down into smaller pieces:

1. Trigger: Issue assigned (doesn't change since the previous article)
   
2. Initial conditions: let's set up three conditions (doesn't change since the previous article)
   
   
   • Issue fields condition: Project does not equal Out Of Office (OOO) - to disable running this rule during the onboarding process when HR employee will create an initial rule for new user
     
   • Issue fields condition: Assignee is not empty - to disable running this rule when someone will set assignee as Unassigned
     
   • User condition: User who triggered the event (Initiator) is not Issue assignee - to disable running this rule when the user assigns himself during his unavailability. I suggest removing this condition during testing!
     
3. To retrieve the correct Out Of Office rule we will use the following set of components:
   
   
   • Lookup issues action with configured JQL:

     project=OOO AND type=Sub-task AND assignee={{issue.assignee}} AND "Start date" <= now() AND "End date" >= now() AND "Related project"={{issue.project.key}} ORDER BY updated DESC

     to get the newest user OOO sub-task related to the current date with the current project selected in the Related project field.
     
   • Advanced compare condition: {{lookupIssues.size}} equals 0 - to overwrite the OOO rule in case there is no specific rule for the current project (if the previous component did not return any sub-task)
     
   • Lookup issues action with configured JQL:

     project=OOO AND type=Sub-task AND assignee={{issue.assignee}} AND "Start date" <= now() AND "End date" >= now() AND "Related project" IS EMPTY ORDER BY updated DESC

     to get the newest user OOO sub-task related to the current date with an empty Related project field.
     
   • Advanced compare condition: {{lookupIssues.size}} does not equal 0 - to run the rule only if the user configured the proper OOO rule.
     
   • Log action: Used rule: {{lookupIssues.first.key}} - to save this information in the rule audit log for future troubleshooting purposes.
     
4. Main rule components are divided into 3 sections - one for each action possible to configure in the Options field:
   • The first section is used to send an e-mail notification to the user who has assigned an issue to an absent user.
     
     As you can notice there are 3 possible outcomes with different e-mail body content:
     
   • The next section is used to add a comment to an issue assigned to an absent user.
     
     As you can notice there are 3 possible outcomes with different comment content:
     
   • The last section is responsible to reassign an issue to the coverer
     
     

What's next?

This setup can be further developed. The first thing that comes to my mind is to add a reassignment registry to each rule so that the user who returns to work can verify which tasks have been reassigned during his absence. You probably also need to configure the mechanism responsible for deleting all old and unused rules to clean the OOO project a little bit.

If you have any questions about this setup, let me know in the comments.

[Alex Koxaras _Relational_]

Thanx for sharing this @Piotr Zadrożny _Eyzee_ !