Actually, we can configure that a notification will be send to a target entity. In my definition, a entity could be either the current assignee or reporter or group or project role or whatever else.
Today, we are not able to send a notification to the intersection (cardinality) of an entity "A" and an entity "B".
Let's say that 50 developers are split into 3 teams, so we create 3 groups: "Team A", Team B", "Team C".
The developers of a team are split into 3 levels, so we create 3 groups: "Senior", "Confirmed", "Junior".
We will not be able to notify the developers who are in the "Team A" and who are also "Junior".
But we can notify either all members of the "Team A" or all members with the level "Junior".
The only way to do that will be to create 3 * 3 = 9 groups to match with this requirement ("Team A Junior", "Team A Confirmed", ...).
We don't want to do that (not easy to maintain / changes / administrate).
For an issue of type "Development", we are able to choose which development team will handle an issue through a custom field "Dev. Team".
Let's say that it has been defined in the related workflow that the next transitions must be visible only for the selected team.
=> a condition C1 of type "User Is In Group Customfield" for the custom field "Dev. Team" is added for each transitions, easy!
Some of those transitions are also visible only for some developer levels.
=> a condition C2 to combine with C1 can be added to the transitions, easy!
BUT we cannot combine the entity which will receive notifications through the notification scheme.
If we create the "9 groups solution" to match with this requirement, we cannot use the condition C1 anymore because we will have to create a custom field for each levels in this case ("Dev. Team Level Junior", "Dev. Team Level Confirmed", "Dev. Team Level Senior") and an validator plugin to ensure that the selected groups in those custom fields are linked to the same team. Then we have to create 3 conditions as C1 for each transitions to check in those 3 custom fields to be able to know if an user is member of a paricular team.
To summarize, we would like to be able to combine entities which will receive notificationsusing cardinality ?
Mhh, I would think about a solution with 9 groups. I read this just a few seconds, so maybe I won't get the whole situation, but:
When the team and level is specified in a transition, maybe you could run a post-function, that splits this double information into 2 separate custom fields which only hold one information each.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG