Bug #93153
open
No such workspace defined after assigning usergroups to users
0%
Description
I got a bug which I had in TYPO3 7, 8 and now in 9 again. Not sure if it is already fixed in 10.
A BE user has some be usergroups assigned. I added one group to that user and as an admin I wanted to test that user. I then changed into that user role in the backend and I got the following error:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1476045469: No such workspace defined | InvalidArgumentException thrown in file /var/www/typo3/public/typo3/sysext/workspaces/Classes/Service/WorkspaceService.php in line 124. Requested URL: https://my.domain.de/typo3/index.php?route=%2Fmain&token=--AnonymizedToken--&referrer-refresh=1608632069
The group I added had the following access rights:
Erlaubte Ausschlussfelder
sys_file_metadata:caption
sys_file_metadata:latitude
sys_file_metadata:duration
sys_file_metadata:download_name
sys_file_metadata:unit
sys_file_metadata:creator
sys_file_metadata:creator_tool
sys_file_metadata:content_creation_date
sys_file_metadata:color_space
sys_file_metadata:publisher
sys_file_metadata:categories
sys_file_metadata:location_country
sys_file_metadata:content_modification_date
sys_file_metadata:longitude
sys_file_metadata:note
sys_file_metadata:source
sys_file_metadata:ranking
sys_file_metadata:location_region
sys_file_metadata:keywords
sys_file_metadata:pages
sys_file_metadata:visible
sys_file_metadata:language
sys_file_metadata:location_city
sys_file_metadata:status
sys_file_metadata:title
sys_file_metadata:copyright
sys_file_metadata:fe_groups
Module
file_FilelistList
The result: the BE didn't work anymore
I fixed it with going to the be_user table and changed the value in 'workspace_id" from -99 to 0. After that I needed to restart the browser in order to be able to login again. As said, that I had this bug in earlier TYPO3 versions and it happend when assigning usergroups to users. Something must be wrong with the usergroups but I don't know why such an error can appear and break the BE...
Updated by Christian Kuhn almost 4 years ago
- Status changed from New to Needs Feedback
Interesting.
This -99 workspace is some 'magic fallback' workspace handled mostly internally. As far as I can see, the related code is still very similar in v9, v10 and master. And yes, -99 is ugly and should go away somehow.
But I'm unable to reproduce the issue: Dave, would you like to dig a bit deeper and see how exactly this can be reproduced in v9, v10 or master? be_users usually have 0 set as workspace_id, I mostly wonder how / what sets the db value to -99, so a step-by-step guide on how to reproduce the issue would be great.
Updated by David Menzel almost 4 years ago
Thank you for the response. Sorry for the late reply but I didn't get any notification that someone has answered. ..I can try to find out more but when we first had the error in TYPO3 7 it was not really clear what triggered the issue.
Updated by Christian Kuhn over 3 years ago
- Status changed from Needs Feedback to Closed
Hey.
I couldn't find a way to trigger this in v9, v10 & master.
I hope it's ok to close the issue for now.
Please report back (maybe in a new issue) if you come along this problem again and find a way to reproduce it.
Updated by David Menzel about 3 years ago
- TYPO3 Version changed from 9 to 10
- PHP Version changed from 7.2 to 7.4
I observed the following:
The error occurs when users have neither been assigned a workspace nor have the right to edit the live page.
I have created a new user in TYPO3 10.4.21 and assigned a user group that was not assigned to a workspace (as owner). When I wanted to test the role as admin the BE was broken again. With the user right to edit the live page, it works for the user. Even if the user does not have the right to edit the live page, but the usergroup is specified as owner of the workspace (then the user can only work in the workspace, which would be ok), it works.
Theoretically it should be checked if a user has at least one of both:
1) Either the right to edit the livepage or
2) a usergroup that is assigned to a workspace as owner.
If the user has neither, the error should be caught...
Updated by Andreas KL almost 3 years ago
I also encountered the problem::
Preconditions:
Typo3-Version: 10.4.17
Workspaces Management: aktiv
1 Workspace defined
Log in as Admin
Actions:
Create new Backend User
set "Enabled=Yes"
Admin = no
Assigned Group = no
Edit Live (online) = no
switch to user (as if you want to test his account)
Result:
typo3-error: "no such workspace found"
no login possible anymore!!
Workarround as described:
set workspace_id=0 in table be_user and restart the browser
Updated by Riccardo De Contardi 9 months ago
ยท Edited
I'm not sure if it is fixed on TYPO3 13... I tried to follow the steps on comment 6
- the " workspace_id: -99 " is still present on the database
- but I don't see any ugly error, just an empty backend (no module menu, no pagetree: is it normal? or is it the effect of having no be group defined?
Updated by David Menzel 9 months ago
- TYPO3 Version changed from 10 to 11
We noticed the same behaviour in TYPO3 11.
So, something between TYPO3 10 and 11 must have fixed this issue, so that at least the configuration does not break the instance anymore.
However, when I first saw this blank page, I didn't know why this happened because I never got a blank page in the backend before. Therefore, it would be good to show a notification like:
"This user as neither the Live or Custom workspace assigned.
Please assign the Live Workspace or another Custom Workspace to this user."
Updated by Georg Ringer 5 months ago
- Related to Bug #97129: No such workspace defined after create a new user and assigning usergroups to users added