Dynamic Rule(s) for more complex but flexible approaches
Instead of explicitly declare a list of users and a sign-off rule using boolean algebra, you can specify a dynamic rule, which extracts the users out of referred other fields like multi-user pickers. A dynamic rule MUST start with a first line just containing "// conditional rule". Then, users and a rule has to be defined as described below:
Within a dynamic rule, the reserved words in blue within the following complex example are mandatory!
Within a condition, you can use all methods provided by JIRA's issue API. The helper object provides the following methods:
- contains(collection, string)
- contains(collection, id as number)
- getCF(issue, customfieldName)
- getCFms(issue, customfieldName) to retrieve a customfield's value in milliseconds
- getUsersByCustomfield(issue, customfieldName, operand) to retrieve a (list of) user(s)
customfieldName can be any custom field of type single-user picker or multi-user picker
- *) getUsersByProjectRole(issue, projectRoleName, operand) to retrieve a list of users
- *) getUsersByGroup(issue, groupName, operand) to retrieve a list of users
- concat(list, operand) to append a list of users using logical operand like "AND" or "OR" within rule definition and "," within user definition
- log(data) to write data into the user's browser console output.
If you are using getUsersByCustomfield() etc. then the name of the referred element (e.g. field) will be displayed in gray in addition to the user name. So, a user knows her/his context if displayed multiple times, for example by belonging to various internal roles.
*) According to Atlassian's restrictions, access to users per project role or group can only be done by users with admin permissions! Therefore, each time you modify the members of a group or project role, you have to click on the "sync" button as admin in order to provide this infos to the Group Sign-Off app in the context of all logged-in users.
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, concatinated 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".
GDPR makes it necessary to use account ids
If an automatic conversion from a user name or email into an account id is not possible, which depends on various scenarios and cannot be simply answered, you have to use the account id of deciders instead. Generally, that should not be necessary but in case you need it for uniqueness, you can find the accountId of a user as described below.
How to get the account id of a user?
The easiest way to find your account id is to click on your icon on the sidebar (left/most down icon with your avatar image) and then on the "Profile" link. Then, have a look at the URL within your browser: your accountId is the string after the last "/" marked bold in the sample below:
Such accountId has to be adjusted by replacing the colon (":") by double underscores ("__") and all minus ("-") by a single underscore ("_") if being used as a hardcoded reference within your dynamic rule.
Access issue's data for conditions
You can also access all fields of an issue, like within the following sample of extracting the issue's reporter, and use fields' information for approval:
You can use "helper.log(issue)" to display all available fields and the elements' structure within your browser's console.
If you are using multiple custom fields to retrieve all users, who have to decide all together, you have to concatenate the custom fields content and use a logical operator within the dynamic rule. The sample below illustrates proper usage.
Another sample of displaying the Group Sign-Off field in a certain status, only:
Behave differently if the issue's reporter is a member of a specified project role: