Purpose
This post-function creates a comment in current issue using the content of a field, setting the visibility by project role, by user group or Jira Service Desk's internal / public visibility modes. Comment author can be selected among user fields, or leave as anonymous comment using an empty field.
Text of the comment can be introduced directly in the post-function, or be composed previously using Copy parsed text to a field post-function, and stored into an ephemeral string field.
Comments can also be created in related issues using Write field on linked issues or sub-tasks or Update issue fields for writing into virtual fields "New comment" and "New comment (sends email notifications)".
Example: Create an automatic issue closing comment
Using Jira Workflow Toolbox 2.2.1 or higher versions
We use Add a comment post-function for composing the text of the message and creating the comment with the desired visibility restrictions:
Note that:
- %{00021} is field code for "Current user's full name"
- %{00057} is field code for "Current day and time"
- %{00028} is field code for "Resolution"
Using Jira Workflow Toolbox 2.2 or lower versions
We will use 2 post-function to implement this usage example:
1) We use Copy parsed text to a field post-function for composing the text of the comment, and storing it into "Ephemeral string 1":
Note that:
- %{00021} is field code for "Current user's full name"
- %{00057} is field code for "Current day and time"
- %{00028} if field code for "Resolution"
2) We us Add a comment post-function for creating a comment using the text stored in field "Ephemeral string 1":
Once configured, the transition looks like this:
Other resources related to comments
Jira Workflow Toolbox provides a series of virtual fields related with comments that can be used with all the features of the plugin:
Writable virtual fields
Field Name | Effect of Writing | Allowed String Values | Allowed Numeric Values | Examples |
---|---|---|---|---|
Last comment | Updates the last comment added to the issue if it exists | unlimited text string Optionally parameter visibility can be added for setting comment visibility. To do it add ": {visibility:visibility_value}" at the end of the text. This parameter admits the same values as "Last comment's visibility restriction". (See example Creating a Jira Service Desk internal comment) Since version 2.2 | numbers are cast to string | WARNING: When writing into this field, please add your writer post-function AFTER "Add a comment to an issue if one is entered during a transition." post-function, since otherwise updated comment will be the one before last, instead of the last one. Example: Add current user to comment |
Last comment's visibility restriction Formerly called "Last comment's visibility" | Updates the visibility of the last comment in the issue if it exists. Can be used to set the visibility of a comment introduced with virtual field "New comment" | name of a Project Role or name of a Group. In Jira Service Desk it also admits values public and internal, or alternatively jsd_public and jsd_internal to avoid name collision with existing project roles and user groups. Since version 2.2 | n/a | Developers: for setting visibility to project role or group with name Developers. jsd_internal: for setting JSD internal visibility. jira-developers: for setting visibility to "jira-developers" user group. |
New comment | Inserts a new comment into the issue | unlimited text string Optionally parameter visibility can be added for setting comment visibility. To do it add ": {visibility:visibility_value}" at the end of the text. This parameter admits the same values as "Last comment's visibility restriction". (See example Creating a Jira Service Desk internal comment) Since version 2.2 | numbers are cast to string |
|
Virtual field "New comment" and "New comment (sends email notifications)" can be used in combination with Write field on linked issues or sub-tasks or Update issue fields for adding comments to other issues (linked issues, sub-task, JQL selected issues, or issues returned by an issue list expression.
Optional Parameter {visibility=visibility_value}
Since version 2.2 parameter visibility can be added at the end of comment's text in order to set visibility restrictions. To do it simply add ": {visibility=visibility_value}" at the end of the comment's text. Let's see some examples:
- This is a comment only visible to developers group.
:
{visibility=jira-developers} - This is a comment only visible to Admin project role.
:
{visibility=Administrators} - This is a comment only visible to Jira Service Desk agents and collaborators.
:
{visibility=jsd_internal} - This is a comment also visible to Jira Service Desk customers.
:
{visibility=jsd_public}
Values returned when reading virtual fields
Field name | Type | Value returned when cast to string | Examples |
---|---|---|---|
Last comment | Text string | Last comment entered in the issue. | - |
Last comment's visibility restriction | Text string | Name of a group or project role the visibility of the last comment entered in the issue is restricted to. If no restriction is applied to the comment, this field is returns an empty string. For Service Desk's special Internal visibility restriction, string Internal is returned. This field can be used to check visibility restriction of field entered in transition when it exists. | - |
Last commenter | User | Name of the user who entered the last comment in the issue. | galileo.galilei |
Transition's comment | Text string | Comment entered in transition screen. This field can be used to make comment mandatory in transition screen, or to validate the content of comment entered in a transition. | - |