It's important to understand that this first story is not at all meant to be really usable by a end user. It's main purpose is to "touch" the whole stack of what should be modified by the epic but on a very limited subset of feature already under control because it's pretty much what we are doing for "regular" Contributor semantic.
The whole feature is hidden by a feature flag in local.inc for tracker administrators. Once activated for a tracker, all users "see" the feature. As it's behind a feature flag, the tracker cannot be inherited (either from tracker picker at tracker creation or as part of a template project).
Functional overview
Contributor semantic
In order to introduce this first step as light as possible, at this step, the "Contributor" semantic is re-used "as is" (tracker admin has to selection a field for that) but there is a toggle (hidden by a feature flag) that turn this Semantic in "automatic" mode. The automatic mode is meant to gather all user/groups fields on the longer term but at this step, it's a way to implement it as a baby step while having a field that "means" something (the alternative would have be to pick one field randomly, that was not really usable).
Once set to "automated", it's no longer possible to switch back to "regular" semantic (one field). It's mostly an arbitrary, technical, constraint to avoid having to manage the switch on/off consequences on the whole stack. As we don't see it as a nominal use case, we prefer to prevent it and to implement that later on when the need actually arise.
It's not possible to switch to "automated" if there is already a permission set to "have access to all artifacts assigned to group" or "have access to all artifacts submitted by or assigned to group". Tracker admin must remove them first.
There is a link from "Contributor" screen to "Tracker Permissions" screen to ease the switch.
Permissions
Once the "automatic" semantic is set:
- It's no longer possible to select "have access to all artifacts assigned to group" or "have access to all artifacts submitted by or assigned to group"
- There is a new "Role based permission" section (as in epic mockup) section
In the "Role based permission" section, the new perm can be activated. When activated, the permission of the artifact is enforced in
- Artifact view
- Modales
- v1 in tracker
- v2 "Agile Dasbhoard home"
- Angular
- CSV export
- REST
- reports
- Kanban
- Scrum
- Planning
- Overview
- Cardwall
- Cross tracker search
- TTM
- Baseline
- Timetracking
Tracker TQL
Tracker TQL is enhanced to support `@assigned_to` (or maybe @contributor ?) syntax with all related features
- @assigned_to
- operators: =, !=, IN, NOT IN
- expr
- `username`
- (`username1`, `username2`)
- MYSELF()
Cross Tracker Search TQL
Ensure existing `@assigned_to` works with the new behaviour (there should be no change here).
However, the pre-query checks are made more strict to ensure all tracker selected in the query have the "automated contributor". Another way of stating is that it won't be possible to mix trackers with "automated" and "regular" contributor semantic.
It's also an arbitrary, technical, constraint that can be relaxed later if needed but better not spend to much time on supporting that at this point of the development.
My Artifacts Widget v2
As the "my artifact" feature is going to be completly re-think, we make a completly new widget for "automated" semantic to avoid having to deal with both development at the same time. At the end of the development "My artifacts v2" will include artifacts from the "regular" semantic as well.
At this point, the widget is very limited and doesn't do any performance optimization. It will list all Open artifacts "assigned to" with
- id
- title of the artifact
- tracker name
- project name
Ordered by artifact id descending (the latest at top) and only the first 30 results.
Technically speaking, it's plain php/mustache with ajax call (no vuejs at this point).