Setting up a Modify Checklists post function

You need administrator rights in Jira to perform the tasks on this page.

You can use the Modify Checklists post function to automatically perform operations on checklists when a workflow transition occurs. This can be helpful to adapt checklists to a particular workflow; for example, you could configure the post function so that once the developers finish developing a feature and move the issue to the “To Review” state, the checklist items that the QA teams need are automatically added.

To learn more about configuring workflows and post functions, see the Atlassian Jira documentation.

To set up a post function that will modify checklists during a workflow transition:

  1. Go to Administration > Issues.

     

  2. In the sidebar, go to Workflows > Workflows.

     

  3. In the Actions column for an existing workflow, click Edit.

     

  4. Select the transition that you want to modify:

    • In Diagram mode, click on the arrow that points to the transition, and then click Post Functions in the panel that appears on the right.

       

    • In Text mode, click on the transition name in the Transitions (id) column.

       

  5. In the Post Functions tab, click Add post function.

     

  6. Select Modify Checklists and click Add

     

  7. Configure the parameters, which are described in the table below, and click Add.

     

  8. On the Workflows > Workflows page that you are returned to, publish your edited workflow so that your changes take effect.

Setting

Description

Setting

Description

Add Parameters to Function

Function Name

The name of the function, which is only displayed for reference in the list of post functions.

Applicable Checklists

The checklist(s) to which the condition will be applied; use Shift + Click or Ctrl + Click to select multiple. If none are selected, the condition will be applied to all checklists associated with the issue.

Generate history log

Check this field if you want the modifications to generate a log in the issue history.

If you do not want to generate a history log, keep this field unchecked and make sure the post function is positioned after the Update change history for an issue and store the issue in the database step.

Operations

Existing Items - Completion

The impact on the checkboxes of existing checklist items when the workflow transition occurs:

  • Do not change items: Does not change the checkboxes of any checklist items.

  • Uncheck all items: Unchecks all checklist items.

  • Uncheck items matching the following regular expression: Unchecks all checklist items whose text matches the specified regular expression (plus any Markdown or description, which includes line breaks).

  • Check all items: Checks all checklist items.

  • Check items matching the following regular expression: Checks all checklist items whose text matches the specified regular expression (plus any Markdown or description, which includes line breaks).

For help with regular expressions, see Java Regular Expressions from w3schools.

Existing Items - Statuses

The impact on the statuses of existing checklist items when the workflow transition occurs:

For help with regular expressions, see Java Regular Expressions from w3schools.

New Items

The items and/or headers that will be added to the checklist when the workflow transition occurs:

Operation

  • Append: Appends the specified checklist items and/or headers to the checklist when the workflow transition occurs.

  • Replace: Replaces the current checklist items and/or headers with the specified items and headers when the workflow transition occurs. If you choose Checklist items for Type and do not enter any items or headers, the checklist is reset to its default state (which will be empty if you have no global items).

If you select Replace, global checklist items will not be removed. These items are immutable. To replace the entire checklist, ensure that no global items have been created (see Editing global items).

Type

  • Checklist items: An empty checklist will be presented, in which you can manually enter items to append or use as replacements.

  • Template: You can select a template from which to pull items to append or use as replacements.

Only append items that do not exist

You can check this field to prevent items from being added multiple times if the same transition occurs more than once.

Items will only be considered duplicates if their names, Markdown, and descriptions are exactly the same. The comparison is case sensitive, and any additional characters or spaces will result in the items being seen as different.

Conditions

Conditional rules

The issue rules that must all be satisfied before the condition will be applied. If no issue rules are created, the condition will always be applied.

  • JQL Query: The issue must be returned by the specified JQL query. If you enter a specific JQL query instead of using a filter, click Validate to ensure that your syntax is valid and that no errors are returned.

You can use an %issuekey% variable in your JQL query to inject the key of the current issue, which is useful for special JQL functions like the ones used by ScriptRunner. If you do so, you can enter an issue key in the Issue Key placeholder field to inject into the variable for the purpose of validating your query.

To make a filter appear as an option, mark it as a favorite.

If you change a field in a transition screen that is queried by your JQL, the system will validate the old value instead of the new one.

Make sure that the Modify Checklist post function is positioned after the re-index step. It also helps if the function occurs immediately before the issue event is raised. If not, the JQL query will likely not work.

  • Issue Label: The issue must have at least one of the specified labels.

  • Issue Type: The issue must be of the specified type(s).


SERVER documentation (On Cloud? Go here.)
Have questions? Contact our Service Desk for help anytime.