Bug #77024
closed
Workspaces don't care about Usergroup-permissions
0%
Description
When setting an usergroup-permission for workspaces (users only should only can edit in draft-workspace), the workspace-plugin don't care about this setting. The BE-user still can edit records in live-workspace.
Only setting the permission in be-user-record produces the required effect.
Typo3-Version 7.6.9
Updated by Riccardo De Contardi over 5 years ago
Seems still valid for 10.0.0-dev; but I think that the problem starts here
1) The "Usergroup" records have an "Edit Live (Online)" settings that can be on (1) or off (0)
2) The "User" records have the same "Edit Live (Online)" settings that can be on (1) or off (0)
So, if you set
Usergroup > Edit Live (Online) = 0
User > Edit Live (Online) = 1
The User settings "wins" and User can edit the Live workspace.
There is no "Edit Live (Online) = not set" setting, (or "Edit Live (Online) = inherit from group") so that the Usergroup setting alone is considered.
This means that the current matrix is (correct me if I am wrong)
Edit Live (Online)
| Usergroup | User | Result |
|---|---|---|
| 0 | 0 | Edit Live: denied |
| 1 | 0 | Edit Live: granted |
| 0 | 1 | Edit Live: granted |
| 1 | 1 | Edit Live: granted |
By the way, even if a setting like "not set" or "inherit from usergroup" would be added, I guess what will happen when your user have more than one group, and at least one has access to live ... in this case the user should have access to the live workspace or not? [1]
I admit that the current status seems to make the Usergroup setting pretty much useless...
[1] My personal opinion: yes, it should have. I think that in this case the least restrictive group should win.
addendum
Another possibility:
- consider the 0 status as "not set"
- not set means "yes"
- revert the logic and call the setting something like "Prevent Live Editing"
The matrix would be:
Prevent Live Editing
| Usergroup | User | Result |
|---|---|---|
| 0 | 0 | Edit Live: granted |
| 1 | 0 | Edit Live: denied - and it is now truly independent from the setting on user |
| 0 | 1 | Edit Live: denied (but only to the user) |
| 1 | 1 | Edit Live: denied |
Updated by Christian Kuhn over 4 years ago
- Status changed from New to Needs Feedback
Hey. I don't think this is a bug.
Access rights are additive. This is especially true with explicitADmode = explicitAllow, which is the default since years. The opposite explicitDeny can easily lead to an access rights administration nightmare. Actually, explicitDeny should vanish altogether, but that is a different story.
So, as soon as one element in the chain (a subgroup, a group or the user record) allows live editing, the user will be able to edit live. Just as Riccardo analyzed correctly. This is identical with all other permission settings: As soon as a group or sub-group allows something, the user will inherit that setting to allowed. This strategy is basically the only one to follow to keep access rights administration maintainable and transparent. This is important if you stack multiple groups with sub groups, which is required with more complex role demands. Other access rights systems usually handle this in a similar way.
I'd suggest to close this issue with "This is how it should be" if nobody objects?
Updated by Riccardo De Contardi over 4 years ago
@Christian Kuhn thank you for your work in this area, so long neglected.
I understand what you mean, and I can agree with you; my only concern is this scenario:
Usergroup: should edit online
User (belongs to usergroup): should not edit online
So, a Usergroup can edit online, but a specific user in that group should not
How should this be accomplished? By adding a second group with no edit online access?
So, in case of multiple groups, the one with more restriction wins?
Furthermore, I don't remember, but I think that this inheritance should be documented if it is not (possibly with examples).
Updated by Christian Kuhn over 4 years ago
If you want someone to not edit live, no group or sub group must have this flag.
A useful setup would be:- A 'all users' group that is for instance used to set page group ownerships, 'edit-live' not active.
- A 'general editing' group that probably has 'all users' as sub group already. It gives access to pages, tt_content, plugins, mountpoints and so forth. Again 'edit-live' not active.
- A 'edit live' group that basically only sets the 'edit live' flag to true. Has no sub groups.
- A 'workspace 1' group that has basically nothing set.
Have a 'workspace 1' set up that has group 'workpace 1' as member or owner.
Then add two users:
User1 is member of 'general editing' and 'edit live' -> The user will be able to edit live. If you additionally give user1 group 'workspace 1', it will be able to work in workspace 1, too.
User2 is member of 'general editing' and 'workspace 1' -> no live access, but workspace access.
You basically stack additional roles to the user by selecting prepared groups. This can be extended as complex as needed and everything is based on an 'additive' approach.
Updated by Riccardo De Contardi over 4 years ago
The answer from @Christian Kuhn is sufficient for me
Updated by Christian Kuhn over 4 years ago
- Status changed from Needs Feedback to Closed