Actions
Feature #35245
closedEpic #58282: Workspaces Workpackage #2
Story #60008: Visual enhancements
Rework workspace notification settings
Start date:
2012-03-26
Due date:
% Done:
100%
Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:
Description
Different notifications on stages¶
Currently there are several notification settings for these stages:- edit stage: takes recipients from "adminusers" (workspace owners)
- "ready to publish" stage: takes recipients from "members" (workspace members)
However, the "execute publish" stage is not considered here.
Different behaviors for each stage¶
Each stage has to possibility to define "default users" with the following behavior:- all (non-strict)
- if users from workspace setting (field "adminusers" or "members") which are also in the specific "default_users" setting for the stage, the checkbox is enabled by default and cannot be changed - otherwise it's not checked
- all (strict)
- all users from workspace setting (field "adminusers" or "members") are checked and cannot be changed
- some (whatever "some" should mean in general)
- all users from workspace setting (field "adminusers" or "members") are checked, but still can be changed
So, the specific "default_users" is just used in one case. Besides that, default_users and the workspaces settings are not merged - if there's no intersection for the mode "all (non-strict)" no recipient is checked per default.
More flexible approach¶
A more flexible approach would be to define (for each stage, plus the "execute publish" state and the individual stages):- that nobody is selected per default
- the everybody is selected per default (standard case)
- the initial author of a change is included
- the workspace owners are included (currently this is only the case if "ready to publish" or "publish execute"
- whether the selected elements can be unchecked again (protected mode)
Draft¶
See https://github.com/ohader/irre_workspaces/blob/master/Classes/Service/BehaviourService.php for a first draft implementation to e.g. resolve editors for each element. Using domain models or at least virtual containers for live/version records seems to be a first requirement.
Files
Actions