Bug #42109
open
Shortcuts do not observe in which workspace they were set
Added by Michael Schramm over 11 years ago.
Updated 10 months ago.
Description
Shortcuts do not observe in which workspace they were set.
I try to set a Shotcut wich must only lead to a target in LIVE Workspace.
If i use it in a custom Workspace i get to the Shortcut Target but in the wrong Custum workspace
Maybe its a Solution to give the user within the shortcut edit form an option to set the target to one or all workspace. (such as absolut or ralative path for shortcut)
- % Done changed from 0 to 10
Looks like you mean "Bookmarks" and not "Shortcuts". I can confirm this issue.
Steps to reproduce:
- Create a page in a workspace
- add a bookmark to this page
- go to the live workspace
- open the bookmark
You will get the edit form for the record of the workspace...
- Category changed from New Features to Workspaces
- Project changed from 624 to TYPO3 Core
- Category changed from Workspaces to Workspaces
- Target version changed from 4.5.21 to 7.5
- Target version changed from 7.5 to 7 LTS
- Target version deleted (
7 LTS)
- TYPO3 Version changed from 4.5 to 12
This issue is still present on 13.0.0-dev, and reproducible with the steps at comment 1:
Steps to reproduce:
- Create a page in a workspace
- add a bookmark to this page
- go to the live workspace
- open the bookmark
You will get the edit form for the record of the workspace...
Addendum
- on the LIVE workspace, you can even add content element to the "phantom" page, but of course they don't show up
- if you go on the DRAFT workspace, the content element is visibile, but as it was created on the LIVE workspace, it is not listed on the workspace module
I upgrade the TYPO3 version, because I suspect it is affected, too
Possible solutions that come in mind:
- Make the shortcuts workspace-aware, so that the shortcut created on one workspace will be confined on that workspace
- When you open the bookmark created on a workspace outside of it, a warning message on the top of the page warns you that the record has been created on a different workspace and offers a button to go straight to the correct workspace.
A bit of background:
- the current workspace is saved to the session
- the backend URL handling is currently not context-aware, so URLs do not contain any information about the context of the user (workspaces, languages, switch-user come to mind as cases that should be considered)
- backend URL handling is currently not (easily) extensible by an extension (in this case: workspaces)
The correct fix for this issue would probably be to introduce context as a concept for backend routing.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by