Skip to end of banner
Go to start of banner

Comment issue

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

A workflow post-function that creates a comment on the current issue or issues related to the current issue. The text of the comment to be created can be any simple text or generated text using Groovy templates or expressions.

To add a post-function:

  1. Log into your Jira Server instance as an Administrator.

  2. Click on the Administration icon ⚙️ in the upper right corner.

  3. Select Issues.

  4. In the left-hand panel, click Workflows.

  5. Click Edit for the workflow to be edited.

  6. Edit the Transition:

    1. When viewing the Workflow in Diagram view, select the Transition and click the Post Functions link. Click Add post function at the top of the list of existing post functions.

    2. When viewing the Workflow in Text view, click the name of the Transition then select the Post Functions tab. Click Add post function at the top of the list of existing post functions.

Configure the post-function

  1. Follow the steps above to add a post-function to a Transition.

  2. From the list of post-functions, select Comment issue.

  3. Click Add.

  4. The Comment issue page will open (Figure 1, right). Configure the post-function as needed, setting the options for target issues, comment body, comment visibility, and additional options as necessary. See below for details on each of the configurations.

  5. Click Add.

Note that you need to publish the workflow for the new post-function to take effect.

Target issues

The Target Issues configuration set which issue will be updated by the post-function.

  • Which issue(s) - Select the issue type.

    • Current Issue - The issue that is being transitioned and triggering the post-function.

    • Issue/Subtask

      • Sub-tasks of the current issue - Updates will be made to all sub-tasks of the current issue.

      • Parent issue of the current sub-task - Updates will be made only to the parent of the current issue (if any).

    • Epic/Story

      • Issues that belong to the current Epic - Updates will be made to all issues that belong to the current Epic.

      • Epic of the current issue - Updates will be made only to the Epic of the current issue (if any).

    • Portfolio Parent/Child

      • Child issues of the current issue in the Portfolio hierarchy - All child issues will be updated.

      • Parent issue of the current issue in the Portfolio hierarchy - Only the parent issue will be updated.

    • Issue links

      • Issues linked to the current issue through any link type

      • Issues linked to the current issue through the following link type

    • JQL / Groovy

      • Issues returned by the following Groovy script

      • Issues returned by the following JQL search

  • Issue Link - Only available when Which issue(s), above, is set to Issues linked to the current issue through the following link type. Select the required link type between the current issue and the issue to be updated.

  • Groovy script - Only available when Which issue(s), above, is set to Issues returned by the following Groovy script. Enter a Groovy script that returns the ID values for the issue or issues to be updated. See Customizing further with Groovy scripts for more information on Groovy scripting.

  • JQL expression - Only available when Which issue(s), above, is set to Issues returned by the following JQL search. Enter a JQL expression that returns the ID values for the issue or issues to be updated. See Using JQL in JMWE for more information on JQL.

Comment body

Enter the text value to be used as the comment content; the value can be either a static text value or a String value generated by a Groovy template or Groovy expression.

  • Comment type - Select one of the following:

    • Text or Groovy template - A fixed text that can include a Groovy template markup that can be used as the comment body.
      For example, The issue will be resolved on or before <%= issue.duedate%> by <%issue.assignee%>.

    • Groovy Expression - A Groovy expression whose return value (of type String) will be used as the comment body.
      For example, issue.get("description") will add the description of the issue to the issue as a comment.
      See the Expected Value tab of the Groovy help editor or refer to the documentation to know more about the expected value in the above cases.

  • Comment text - Enter text including optional Groovy expression that is used as the body of the comment.

Comment visibility

This configuration enables you to select a group or a project role to which the comment will be visible.

For no restriction, leave the field blank.

  • Restrict to Group - Select a group to restrict the visibility of the comment to a specified group. For no restriction, leave the field blank.

  • Restrict to Project Role - Select a project role to restrict the visibility of the comment to a selected project role. For no restriction, leave the field blank.

  • Restrict to Internal (Jira Service Desk only) - REQUIRES the option Send 'Issue Commented' notification is selected. Select this option to restrict the visibility of the comment to the Service Desk Agents and Collaborators only. 

Options

  • Send "Issue Commented" notification - Select this option to notify users by email when a comment is added to the issue.

Run as

Select which user account will be used when running the post-function.

  • Run as user

    • Current user - The user who triggered the transition.

    • Specific user - Select a specific user account to execute the post-function.

    • User in field - Select a User Picker field or other custom field containing user values.

    • User from script - Enter a Groovy script that returns a user ID.
      Examples:

      • "jdoe" - To use a static value username.

      • issue.get("assignee") - To return the current issue's Assignee.

Note: Prior to JMWE 8.4.0, this configuration stores a username value. If an Administrator changes a user’s username, the post-function will fail.

Existing post-functions created before version 8.4.0 should be updated; open the post-function for editing and save it (no changes are necessary). This will update the configuration to use the immutable user ID value.

New post-functions do not need to be updated.

Conditional execution

It is possible to configure the post-function to execute (or not execute) only in specific circumstances. The Condition executional option sets this behavior.

  • Only if condition is true - Check this option to execute the post-function based on the result of a Groovy expression. See Conditional execution/validation using a Groovy expression for more information.

    • Condition - Enter a Groovy expression that evaluates to true or false (or truthiness/falseness).

Error Handling

  • Make transition fail when an error occurs in this post-function - Select this option to make the transition fail when an error occurs while running the post-function. An error message is displayed to the user showing the transition failure.

By default Error handling is turned off. When it is turned off, all errors (Java Exceptions) raised by this post-function, including those raised by custom Groovy scripts, will be logged in the JIRA log file. However, they will not be reported to the user and will not prevent the transition from completing. 

When designing new workflows or troubleshooting them, it may more convenient to be notified immediately of any such error during the execution of the transition. For example, on production Jira instances you might want to show errors only for the post-function(s) being created or updated, in order to avoid disrupting other workflows. To make errors raised by the current post-function prevent the transition from completing and show the error in the browser, select Make transition fail when an error occurs in this post-function.

When the Error handling option is selected on a specific extension, it overrides the configuration on the JMWE configuration page.

If you want to show all errors - to either All Administrators or All Users - configure the option globally on the JMWE configuration page. For example, on development and staging instances, you can activate error reporting for all JMWE post-functions so as to display all the errors (it is recommended to do so); on production instances you may want to activate error reporting only for administrators so that they can be made aware of configuration errors.

You are viewing the documentation for Jira Server / Data Center.

On This Page

  • No labels