Administration
- 1 Global settings
- 1.1 Create additional customfield(s)
- 1.2 Simple Example of a definition
- 1.3 Simple Example with additional user infos
- 1.4 Dynamic Rule(s) for more complex but flexible approaches
- 1.5 Complex Example with different syntax: use a customfield (multi-user or user picker) to dynamically specify voters
- 1.6 Complex Example with different syntax: a set of conditional definitions depending on issue's data
- 1.7 Different configurations depending on the value of a referenced custom field
- 1.8 Complex Example accessing issue's functions to dynamically retrieve approver name(s), here: issue's reporter
- 1.9 Complex Example display a Group Sign-Off field depending on its issue's status
- 1.10 Concat of multiple custom fields' contents
- 1.11 Different configurations depending on the value of a referenced custom field
- 1.12 Concat of multiple custom fields' contents (also: some maybe empty)
- 1.13 Approver of stories are determined by their epic's customfield 'Approvers'
- 1.14 Approver of stories are determined by their epic's customfield 'Approvers'
- 1.15 Additional Options
- 1.15.1 Vote/decide multiple times revoking prior one
- 1.15.2 Vote/decide multiple times revoking prior one - but limited to revert declines, only
- 1.15.3 Disable delegation of decisions
- 1.15.4 Confirm decision by entering password again (re-authenticate)
- 1.15.5 Disable forcing a comment if having declined
- 1.15.6 Mandatory comment if having declined (since version 2.10.4 for Jira 10 or 2.8.24 for Jira 9)
- 1.15.7 Overwrite standard behavior to reload an issue after deciding
- 1.15.8 Disable displaying individual users
- 1.15.9 Display decision buttons for deciders only if their decision has got an immediate and direct effect on the total result
- 1.15.10 Option for "maybe/uncertain" (available since version 2.8.6)
- 1.15.11 Force sequentially voting, one after the other, instead of parallel (available since version 2.8.19)
- 1.16 Simple Example of a definition with additional option in bold
- 1.17 Special Function(s)
- 2 Create additional listener(s) for automatic workflow transition(s)
- 3 Modify your workflow(s) with new Condition(s)
- 4 Modify your workflow(s) with new Validator(s)
- 5 Modify your workflow(s) with new Post Function(s)
- 6 Email-Notifications (available since v2.4.1)
- 7 Custom Events "Issue Signed-Off Event" and "Issue Declined Event" for automatic Notifications/Emails
- 8 Issue Property “jira.issue.editable“ depending on status
- 9 Using Jira Automation
- 10 JQL functions
- 11 Reporting
Jira system admins have to do a lot within larger companies and cannot take care about individual projects out of hundreds. Therefore, you can setup and configure all necessary sign-off/approval-rules for my app "Group Sign-Off/Multi-Approvals for Jira" as project administrator, now: such rule for sign-off/approval will be stored as a default value within a new context of the related custom field for the maintained project only. Additionally, all screens will be adjusted to also contain this Group Sign-Off field except for the screen of the issue-create-operation.
Global settings
Within the app's global configuration, you can specify some overall behaviors/features as shown below:
As a system admin, you can reach that panel by clicking on the button "Configure" of the expanded section "Group Sign-Off for JIRA" on your Jira page "Manage apps".
Create additional customfield(s)Please create any many new customfields of type "Group Sign-Off" as you need, like "Steering Committee", "Product Board" etc. Within this documentation, I am focussing on one new customfield named "Sign-Off". If you are not familiar with creation of new customfields, please have a look at the Atlassian documentation for this standard feature of JIRA. | |
In order to get the related unique ID of your new customfield, please click on the "configure" menu item as visible on the screenshot. | |
Within the URL, you will find the unique ID of your customfield as parameter, here: 10100. Please write it down to remember. You will need it while configuring listeners later. | |
You have to determine, who is allowed to make a decision. Using the feature of setting a default value of a customfield, you can define it once and it will be taken over while creating a new issue automatically.
Simple Example of a definitionfpolscheit If you want to put additional information in front of the user name, you can add this as comment straight after the user name without any spacing and enclosed by /* and */. Attention: you have to use the combination of name and comment as a unique identifier within the sign-off rule. Background: you may have different roles and act in different contexts. Simple Example with additional user infosfpolscheit/*Manager*/ | |
Dynamic Rule(s) for more complex but flexible approachesInstead of explicitly declaring a list of users and a sign-off rule using boolean algebra, you can specify a dynamic rule coded in JavaScript and using provided helper functions, which extract the users out of referred other custom fields like single- or multi-user pickers, etc. A dynamic rule MUST start with a first line just containing "// conditional rule". Then, users and a rule have to be defined as described below. The reserved words in blue within the following complex example are mandatory within a dynamic rule!
If you are using getUsersByCustomfield(), getUsersByProjectRole(), getUsersByGroup() the name of the referred element (custom field, project role or group) will be displayed in front of the retrieved user name since Group Sign-Off version 1.4.0. Complex Example with different syntax: use a customfield (multi-user or user picker) to dynamically specify voters// conditional rule users =""+helper.getUsersByCustomfield(issue,"Board Members",","); Please use the exact syntax above for dynamically specifying the list of user(s) based on the referred custom field. Users must be a comma separated list, that why the operand is a comma. The rule must be a sequence of users, concatenated by a boolean operand (AND or OR). By the first voting, the content of the customfield, referenced by name as parameter, will be taken over and the members will become a fix list. Instead of using the custom field's name, you can also use it's ID: please put that number into the quotes like "10023" instead of "Board Members". Or you can get the value of a cascading-select-customfield and determine the deciders and their logic per field value: Within this sample, the custom field named „myCascadingSelection“ has got the options A-1, A-2, B-I, B-II … You can also access the following functions of an issue (similar to the functions officially provided by the Atlassian Java API):
Within the following sample, the issue's reporter is automatically retrieved and used as a decider this for approval: Often, you do not want to see a group sign-off field and its approvals through the complete life-cycle of an issue: you can limit displaying a group sign-off field only if its issue is within a certain status. Suppose you use multiple custom fields to retrieve all users, who have to decide all together: in this case, you have to concatenate the custom fields' content and use a logical operator within the dynamic rule. The sample below illustrates a proper definition. All members of the custom field "Managers" will be appended but if there is at least one user, only. Since Group Sign-Off version 2.8, you can access an issue's fields a bit easier, just using Javascript-llike JSON-notation like issue.status.name. Or you can get the value of a single-select-customfield and determine the deciders and their logic per field value: Or you can get the value of a cascading-select-customfield and determine the deciders and their logic per field value: Within this sample, the custom field named „myCascadingSelection“ has options A-1, A-2, B-I, B-II …
The following code sample is a generic template to concat all members of referenced custom fields (single- or mutli-user pickers) as well as referenced Jira group(s):
Advanced feature for experienced power-user: DEPRECATED due to security aspects and removed in Group Sign-Off version 2.8:
Using these advanced features, you can configure suitable solutions for even more complex business scenarios. INSTEAD, please use: | Pay attention: using a dynamic rule, it's resulting set of deciders will be automatically turned into a static equivalent by the first decision for integrity reasons! Background information: if someone has voted (declined or signed-off) and the members of a decision would be changed later, you can manipulate the total result by removing deciders with unwanted votes or add additional deciders. To avoid this, an automatic transition into a fix set of deciders will be done together with the first vote. |
Additional OptionsAdditional options can be added at the end of the definition like shown below. Vote/decide multiple times revoking prior one
Vote/decide multiple times revoking prior one - but limited to revert declines, only
Disable delegation of decisions
Confirm decision by entering password again (re-authenticate)
Disable forcing a comment if having declined
Mandatory comment if having declined (since version 2.10.4 for Jira 10 or 2.8.24 for Jira 9)
Overwrite standard behavior to reload an issue after deciding
Disable displaying individual users
Display decision buttons for deciders only if their decision has got an immediate and direct effect on the total result
Option for "maybe/uncertain" (available since version 2.8.6)
|