Bug #100117
openContent modification takes place in wrong workspace if user switches to different workspace concurrently
0%
Description
Using workspaces v11.5.24
Content creation/modification intented to happen within a workspace A actually gets created/modified within workspace B if the user has (or has been) switched to workspace B concurrently.
This scenario arises when the user works with multiple browser tabs or windows during their backend session, and switches to workspace B in any of these browser tabs/windows.
In practical terms, this means that content not yet intended for live publication may actually be published live; also the reverse can happen: content which is supposed to be created/modified in the live "workspace" will actually only be part of an "work-in-progress" workspace.
Here is a screen recording as GIF (MP4 version also attached):
The underlying issue seems to be that the workspace within which content creation/modification eventually takes place is being controlled server-side in the backend user property/field/attribute workspace_id
.
This workspace_id
property is updated whenever the backend user switches (or alternatively gets switched to?) to another workspace, e.g. by the user selecting that workspace from the workspace dropdown menu (backend route ajax_workspace_switch
, path /ajax/workspace/switch
, TYPO3\CMS\Workspaces\Controller\AjaxController:switchWorkspaceAction(..)
, https://github.com/TYPO3-CMS/workspaces/blob/v11.5.24/Classes/Controller/AjaxController.php#L49 ).
Concurrently happening workspace switches are not automatically reflected in (other) browser tabs/windows; those browser windows still present their no-longer-valid workspace context (e.g. the green menubar coloring and "work-in-progress" workspace title still shown despite the user actually already working in the "live" workspace).
Also further content editing and backend navigation will keep the outdated workspace context. Only with a full page reload will the backend user interface show the correct workspace context again.
In my opinion, the root cause is that currently the workspace within which content is being created/modified is decided server-side. The better approach would rather be to include the workspace ID with each content modification client request on the client side.
Files
No data to display