Access right for group: cannot deny "remove" permission while granting "write" permission.
From my point of view, and also as my needs:
It's easy to understand the logics of group: to manage the access rights for a lot of users in bulk, without having to repeat the action of editing (of the same) rights for each single users
It's also popular case that we want grant Write permission to a group of users so that they can create topic, add comment… while denying them from Remove right so that they cannot delete topics, content…
As mentioned in the Nuxeo Docs http://doc.nuxeo.com/display/public/USERDOC58/Document+Management+Concepts
Remove right is included in the Write right.
The Remove permission is most intended to be denied, so as to restrict the actions available to users with “Write” permission.
At first what stated in Nuxeo Docs seems to fit very well with the needs I mentioned above, but in reality it turns out to be the other way:
In my Nuxeo intsance, the workspace nam “aroma marketing” in DM: I grant Write permission to “aroma-marketing” group and deny Remove permission to this group with the logics that they can create content (topic) but cannot delete topic just exactly what is mentioned in Nuxeo Docs. But it fact, with this permission setting, users in “aroma-marketing” group still can delete content. It means that they are granted with “Write” (inlcuding Delete rights) but they are not denied from deleting as supposed to be with Remove right denial.
When I take closer look at the Nuxeo Docs with the link above and further with this link : http://doc.nuxeo.com/display/public/USERDOC58/Managing+Access+Rights
It seems to me that you can grant Write rights to group of user, and you cannot deny Romve rights to that group of user at the same time, but you can only deny Remove right to USERS (NOT GROUP) in order to have the final permission: they can create but cannot delete. If this is the case, it will be quite inconvinient because the users group are born so that we can manage permission of users in bulk without having to repeat the same permision setting to every single user. In this case, I can grant Write right in bulk (using group) but then I have to deny Remove right to every single user?
I hope that I'm wrong here because it will be exhausted if I have to deny remove right to evey single user hundreds of them), in every single workspace (hundreds of workspace) because generally I just want the normal user to be able to create and comment, not to delete.
Can anyone help me to clearify this? Or if I'm wrong here could you please tell me how to let a group of user to be able to create content, but not be able to delete content.
Thanks in advance.
 |
Tùng Aroma
Member (155) 1 2 1 |
12/26/2013 ( History) |
Hi,
http://doc.nuxeo.com/display/public/USERDOC58/Managing+Access+Rights
The fact that the rights are given or denied to a single user or a group doesn't have any influence.
So it's not a problem of users or groups
granted rights have priority over denied rights
Here is the point. If you give a GRANT, you can change it with a DENY in a subfolder but not at the same level. (because of this rule)
Hope it helps.
PS: An other “rule” not explained in the doc. In “inherited rights” if you see somthing like : username ; granted permissions ; denied permissions jonh doe ; Read ; Read the closest permission (grant or deny) in the hierarchy is applied. It's seems obvious, but difficult to understand the first time.
I just want to share my idea on realistic, practical side of the thing here when it's in real-life operation.
- If I have Workspcae XXX, and I want to allow user to be able to WRITE (CREATE CONTENT) BUT NOT DELELE (NOT REMOVE) (it's popular scenario to do so). This way they are supposed to be able to create (but not delete) both topic and sub-workspace insides XXX.
You said "Here is the point. If you give a GRANT, you can change it with a DENY in a subfolder but not at the same level. (because of this rule)":
- this is both painful (because ussually number of sub-worspace is much bigger than parent workspcae. In Nuxeo Docs, it says the group is created to manage access right so that we do not have to repeat the same permission setting action with all-every single users (it would be crazy and unwisely with thousands of users).
For parent workspace it's similar to group, and sub-workspace is similar to user: much bigger numbers of sub-workspace with the same access right permission setting but it's different that we cannot set it with one action in parent workpace, but we have to go to all-every single workspace and repeat the same action with of to deny the Remove rights. It's quite painful and not as wise as other Nuxeo's sophisticated funtions.
- Not to mention this thing: when user are given right to CREATE CONTENT (BUT NOT TO DELETE) permision in workspace XXX, it means that they are supposed to be able to create sub-workspace themselves (but not to delete them), and then there will be sub-workspace to be created everyday and the how can the Admin of Nuxeo system go to every single workspace everyday to check for new sub-workspace and the deny the Remove permission.
"granted rights have priority over denied rights"
I think most of the problem lies here and I don't think it's goog logics of system design. I think the dened rights should have priority over granted rights because ussualy it will happens with this order: No. 1. you grant access to group of user (the other users not supposed to access of course we will do nothing about them - no access right granted). And then No.2: within the group granted access (larger, containing group), there will be particular users or groups (smaller group inside) you want to FINE TUNE with the DENY permission.
It means that the "fine-tune" DENY permision must have effect over group of users with GRANT permission in step one. This way, the DENY permission must have priority over GRANT. If GRANT have priority over DENY, then the DENY is totally out of use, it's there you can technically set DENY in a workspace but actually it have no effect, it cannot work (because it works according to the GRANT).
This is the reason why we cannot set DENY Remove permission in the same workspace but we have to go to all-evry single workspace to repeat the same action of DENY Remove. Not to mention the impposibilities of this action when sub-workspaces are created by user with WRITE permision and the Admin cannot go to every workspace everyday to check for new sub workspcae to repeat the DENY Remove action.
In summary, I think that it's not logical to set GRANT to have priority over DENY and by doing so it cause the problem that the DENY cannot work with the GRANT in one workspace and you have to go to all-every single sub workspace to DENY.
I think DENY should have priority over GRANT and then the problems will disappear and all other things will run smoothly as well.
Actually when I design user and gruop structure, I know that there's bot GRANT and DENY, without reading Nuxeo Docs, I naturally thing and feel that DENY should be higher that GRANT and I set permision with group for all workspace this way. Then i'm so supprised to find out from Nuxeo Docs that it's totally opposite.
Do you think that this point should be suggested to be modify at the next version?
Going into a museum, a house is supposed to be WRITE permission, and when going into, physically visitor can see displayed items (Read), take photo (create content) and physically they can touch, move the displayed items (considered to be Remove rights). Then visitors are "fine-tuned" to restrict (DENY) them from touching and moving items (Remove rights).
Naturally and logically, this restriction (DENY) must have effect on the vistors going in museum (Write granted). If GRANT permission have priority over DENY then there's no point, no effect, no thing for the DENY here.
First you have to allow user in to museum (Grant Wrtite), and then you restrict (DENY) them from moving displayed items and that restriction must work or else there's should not be restriction.
DENY is kinda "fine-tune", "restriction" and the fine tune and restriction must have effect, must be able to work on the existing permision granted, it means DENY should have priority over GRANT in order to work.
- workspace "aroma marketing" -> group "aroma marketing" grant write
- workspace "aroma marketing (protected)" -> group "aroma marketing" deny delete
- workspace "aroma marketing" -> in the local config disallow all types of documents (or only folderish ones if you manage rights only in folderish documents, as you want)
Then your users can't create a document in the "aroma marketing" workspace, but only in the "aroma marketing (protected)". If they create folders, these folders inherits the good permissions. => all is OK
If it's your requirements, you can also create a new permission "WriteWithoutDelete". Then you don't need to use a subfolder to deny delete. NB: As a user, if I want to delete the "my personal phone number" document, and I can't => I remove all the content and I save. An empty document remains, but as a user it's like a delete. Just to say : write and delete are not so different. And you maybe have to deal with that too.
> "granted rights have priority over > denied rights" > > I think most of the problem lies here > and I don't think it's goog logics of > system design. I think the dened > rights should have priority over > granted
I don't know. Maybe. The first time I used Nuxeo I thought the same. But now it's no more a problem. And I usually have users asking me : I want to deny access to this group, but not to X because he is the manager. In that case, grant before deny is a good point.
> Do you think that this point should be > suggested to be modify at the next > version?
I'm a Nuxeo user, not a Nuxeo employee. if you want you can open a ticket. But I doubt that it can be possible. It will be very difficult for each client to manage this change (in my case: we have several thousands of documents, with several permissions on many many many folders) But for a fresh instance, maybe you can create an extension to change the way permissions are managed.