Overview
The goal is to provide an automated way to identify people that are "involved" on an artifact and to attach behaviours to this role.
Who is "involved" on an artifact ?
- The one who created it
- Any individual who is selected in a list field (select box, multi select box, radio, check box, open list) bound to "Users"
- Any individual member of a group that is selected in a list field (idem) bound to "User groups"
The "involved" people are gathered in an automated fashion. That is to say, there is no configuration needed to identify a field to be part of that. As soon as a field meets the requirements, the selected individuals/groups are "involved".
This aims to ease interaction of people with artifacts with limited configuration for tracker admin:
- Granting people access to artifacts they are "involved" on
- For individuals, identifying easily all the artifacts they are "involved" on
The proposal is to extends the Contributor semantic to work in an "automated way".
Impact
Contributor Semantic
Contributor semantic can be switched to "automated". On switch, all list fields bound to either users or user groups are automatically associated to the contributor semantic.
This configuration is not enabled by default but the option is inherited so project templates can be made to activate it. All the options/config are imported/exported with XML.
It's no longer possible to switch back once activated (no strong requirement here, it's just to limit the scope of the epic, it can be made available latter on if needed). If needed later on, it will probably possible to allow cherry-pick of which fields are associated to the semantic but this should be dedicated stories if the need arise.
Tracker permissions
The goal is to grant access to artifacts to people that are Contributor to the artifact. The nominal use case is the following:
- A team acknowlegde and tirage all incoming tickets. The have the permission "have access to all artifacts" permission (already exists)
- Then they will identify people or groups in a list field, those people will get access to the artifact (artifact was to visible to them before)
- Those people could add someone else in CC or select another group, for instance a L3 support team. Both CC and L3 team should now have access to the artifact.
The screen will be enhanced to add links between permissions & contributor semantic screen (back & forth).
Loose of permissions
People can "loose" access to an artifact if they are no longer identified in the artifact either individually or if none of the groups they are member of are selected in one of the fields.
Removal of "Assigned to" permission
As the "Assigned to semantic" is no longer available, the permissions "have access to artifact assigned to group" and "have access to artifact submitted or assigned to group" can no longer be set. If they were set, they are removed.
TQL
Single Tracker TQL is enhanced with a new keyword @assigned_to taken from XTS syntax. This @assigned_to means that one can search on the Contributor Semantic (open question: maybe we should use the @contributor key word for consistency ?).
This means that the following query
status = 'Open' and @assigned_to = 'marius'
Will look for all Open artifacts where 'marius' is involved. In other words it will look for 'marius' in all list fields bound to users and it look for marius's groups in all list fields bound to user groups.
However it will not be possible to search for @assigned_to with groups. In other words, the following query won't be supported:
status = 'Open' and @assigned_to = 'Developers'
⚠️ As of today TQL doesn't look for values in Open Lists, this needs to be spiked. We also need to spike how to search on several fields of different types.
Cross tracker search
The implementation proposal is eaxctly the same than regular TQL on single tracker in term of behaviour of search and limitations. But it comes with another limitation: it won't be possible to search for @assigned_to on trackers where there are different settings of Contributor semantic (all trackers must be "single field" Contributor or "automated" but not a mix).
"My Artifacts" widget, new generation
There is a new widget "My artifacts" for both Personal and Project Dashboard that present all the artifacts a user is Contributor to. As this artifact can display a lot of informations (+ the fact that "My Artifacts" queries can already harm the database on very large datasets) we will probably need to denormalize this part. A mockup will be needed to have a better display of the information and a more actionnable widget.
=> mockup & UX to be defined.