The intend of this feature is to progressively settle fields during artifact life in case of usage of worklow to mark maturity stages (like ISO/CMM processes often do). With this in mind, when moving from one stage to another, a bunch of fields that were "under elaboration" became frozen.
It's still possible to un-freeze those fields if the workflow allows some back-tracker (ie. a tracker admin could temporarly allows a transition to make edit possible).
With this feature it would be possible to configure a worklow so an artifact would be entirely "read-only" when "Closed" (except for follow-up comments).
This story depends on story #12187 for new workflow configuration panel.
See live mockup: https://s.codepen.io/enalean/debug/dace752a350bcecdad1003e505bc9992
Tracker administrator point of view, configuration
The configuration of frozen fields is made in workflow transition settings. A new post-action is proposed "Freeze fields" with a multi-select box like in tracker field administration (with fields grouped by containers). All the fields selected won't be modifiable (even by a tracker, project or site administrator).
In order to keep a clear UI and not make it confusing, this post-action can only be added once per state. After adding it once, when you try to add this type of post-action again, then the selectbox for post-action type will show a disabled option.
- Field dependencies: if 2 fields have dependencies they must be configured to be either editable or frozen at same time.
- Triggers: Triggers are defined by tracker admin and can modify a "frozen" field on the behalf of the user.
- Other post-actions. If the transaction set a value to a field (for instance set "0" as remaining_effort when status is Done) and the field is set to frozen, the post action valuation is done (that is to say: remaining_effort is set to 0 and no longer modifiable).
- Rules: Rules applies regardless of the frozen field. A tracker admin can make a dead-end transaction by having a global rule that cannot be satisfied due to frozen field.
End user point of view, usage
At a given state, all the frozen fields the user can see are read only (as if they were not updatable as per permissions).
There are some limits with the interaction of workflow post action with some Tuleap features:
- On scrum cardwall. If the workflow defines that at some states either "Remaining effort" or "Assigned to" are no longer modifiable, it will not be taken into account on the cardwall. To say it differently, in this situation, the data won't be updated on the backend (data are safe) but the error will not be shown to the end user. It would require a major rewrite of the current scrum cardwall (out of the scope of this dev) and it's very unlikely that a team would actually set this up.
- On cardwall renderer of a tracker. If the workflow forbids modification of state at some points of the workflow, the following drag'n drop will be possible but will trigger an error with a opening modal of the artifact to modify the values so the constraints are met.
- Configuration must be exported/imported with tracker XML format
- Configuration must be duplicated at tracker / project creation.
- On the configuration screen fields that are already readonly (burndown, last_update_date, etc) or containers (columns, etc) are not listed to limit the amount of elements to pick-up.
For REST and the angular Artifact modal
The REST routes need to be updated. We initially thought to use the permissions, but those live on the tracker and not on the artifact. The tracker has no knowledge of the particular states of artifacts. We must add the information on the artifact or more precisely, on the artifact's fields.
Here is the proposal:
The artifact modal will need to be updated to take into account that fields with "can_user_update" === false should not be editable.
"workflow_state" can be reused in story #12188 to also support the "hide" information that will tell the REST consumer that this field is supposed to be hidden.