Project

General

Profile

Actions

Feature #35245

closed

Epic #58282: Workspaces Workpackage #2

Story #60008: Visual enhancements

Rework workspace notification settings

Added by Oliver Hader about 12 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
Workspaces
Target version:
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

35245_workspace.png (70.1 KB) 35245_workspace.png Oliver Hader, 2014-07-02 09:19
35245_stage.png (53.4 KB) 35245_stage.png Oliver Hader, 2014-07-02 09:19

Related issues 5 (0 open5 closed)

Related to TYPO3 Core - Feature #35246: Make use of Extbase featuresClosed2012-03-26

Actions
Related to TYPO3 Core - Bug #66361: Workspaces: Email Notifications are always sent to members of the current workspace, NOT the selected workspace.Closed2015-04-10

Actions
Related to TYPO3 Core - Task #72395: Mark out-dated workspaces parts as deprecatedClosed2015-12-22

Actions
Related to TYPO3 Core - Task #72464: Remove deprecated code from ext:workspacesClosed2015-12-29

Actions
Has duplicate TYPO3 Core - Bug #42336: Disabled users shown in notification list for stage changesClosedMarco Bresch2012-10-24

Actions
Actions

Also available in: Atom PDF