Example 1: Due Date should be at least 5 workdays posterior to Creation Date and Time
We want to ensure that "Due date" is at least 5 workdays later than issue date and time of creation. To do it we use validator Boolean validator with math, date-time or text-string terms with the following configuration:
Boolean expression used is: {00012} >= addDaysSkippingWeekends({00009}, 5, LOCAL)
Note that:
- {00012} is code for numeric value of "Due date"
- {00009} is code for numeric value of "Date and time of creation"
- LOCAL represents server's timezone. Timezone is needed to determine weekend time periods. Use USER_LOCAL for using current user's timezone
Once configured, the transition "Create Issue" will look like this:
Example 2: Define a time frame where transition execution is allowed
We want to allow the execution of a transition only Mondays to Thursdays: from 9:00 to 14:00 and from 17:00 to 20:30.
We can use Boolean condition and validator with math. date-time or text-string terms condition or validator depending on whether we want to hide the transition, or show a custom error message to the user when transition execution was not done in a valid time frame. In this example we are going to use the validator:
Boolean expression used is: dayOfTheWeek({00057}, LOCAL) >= {MONDAY} AND dayOfTheWeek({00057}, LOCAL) <= {THURSDAY} AND (timePart({00057}, LOCAL) >= 9:00 AND timePart({00057}, LOCAL) <= 14:00 OR timePart({00057}, LOCAL) >= 17:00 AND timePart({00057}, LOCAL) <= 20:00)
Note that:
- {00057} is code for numeric value of "Current date and time"
- LOCAL represents server's timezone. Use USER_LOCAL for using current user's timezone
Once configured, the transition will look like this:
Calculation Using Custom Schedules
Since version 2.2.39 time calculations on custom defined schedules can be carried out using Schedules Definition Grammar.
For example, you can define your work-schedule as Mondays to Fridays from 8:00 to 15:00, and from 16:00 to 20:00. Then you can calculate time differences, or add time durations to a base instant within that particular custom schedule.
Much more complex schedules than the one described in the example above are possible. You can define common and personal holidays, you can define different work-times for summer and winter seasons, change your work-times from a certain date on, keeping the older work-time definitions for previous instants. Almost any requirement you might think of is possible.
Other examples of that function
- Block a transition until all sub-tasks have certains fields populated
- Block an epic's transition depending on linked issues status and due date
- Block or hide a transition for an issue depending on its issue links
- Block or unblock a transition after an issue rested a specific time in a status
- Block transition until all sub-tasks are in a specific status category
- Close parent issue when all sub-tasks are closed
- Enforce a field (Select List) to be set when another field (Radio Button) has a certain value (works with any kind of field type)
- Ensure that all issues linked with a certain issue link type have "Due Date" field set
- If field A is populated then, field B must also be populated
- Limit issue creation per role and issue type
- Limit the number of hours a user can log per day
- Limit valid dates for work logs
- Make "Time Spent" field required when there is no time logged in the issue
- Make a custom field mandatory when priority is "Critical" or "Blocker" and issue type is "Incident"
- Make attachment mandatory depending on the value of certain custom field
- Make different fields mandatory depending on the value of a Select List custom field
- Make linked issues, sub-tasks and JQL selected issues progress through its workflows
- Make parent issue progress through its workflow
- Prevent issue creation if another issue with same field value already exists
- Reject duplicated file names in attachments
- Require at least one sub-task in status "Resolved" or "Closed" when "Testing required" is selected in Check-Box custom field
- Require issue link when resolving as duplicate
- Restrict parent issue from closing if it has sub-tasks that were created during a given parent issue status
- Restrict sub-task type creation depending on parent issue status
- Restrict sub-task type creation depending on parent issue type
- Set a condition in a global transition which only applies in a certain status
- Validate a custom field "Story Points" has been given a value in Fibonacci sequence
- Validate compatible values selection among dependent custom fields
- Validate only issue links created in transition screen
- Validate that multi-user picker custom field A does not contain any user in multi-user picker custom field B
- Validation and condition based on time expressions
- Validation based on the value of a date type project property
- Validation on issue attachments
- Validation on MIME types of issue attachments
- Validation on sibling sub-tasks depending on issue type and status
- Validation on the value of a Cascading Select field