We just ran into an issue with the new way that permissions work in version 4.7.1
This is from the changelog:
"We’ve changed the way inherited content permissions works, so Umbraco defaults to the Usertype permis-sions of a User if no specific permissions has been sat on a node. Complementing this, Umbraco will now au-tomatically copy the specific permissions of a parent when creating a new page."
I was quite surprised when I saw saw this new behaviour. It seems that this change actually breaks the permissions that are set up in an existing site, if that site relies on inheritance. In our case it does not help that we have ~ 100 editors in a site with 10.000 nodes. It means that we need to actively do some migration just to keep status quo, and it also means that the umbracoUser2nodePermission table will grow a lot.
Could the core team elaborate a bit on why this (in my opinion "breaking") change was made in a minor update? I suspect that many site owners will be as surprised as we were that permissions suddenly work differently.
Which usecases is this specifically designed to solve, that the inheritance model could not?
I can see at least one scenario that this new behaviour would cause problems.
Consider a nodetree like this, where the current user has the permissions liek (abc)
So the user has permissions abcd on the english site, except for the Products pages. Now i want to change the general permissions for the englsih site to abcde. In order to do that, I need to select all nodes _except_ the Products one to update the permissions. If inheritance was used i only needed to change the "Englsih" permissions, since all subnodes with no other explicit permissions would then automatically inherit those new permissions.
Am I missing an advantage of the redundant permission data?
In any case, as you do mention, these changes do break existing sites that relied on the previous permissions esp. regarding inheritance. Which is why we're running 4.7.1.1 with a custom patch to revert to the previous permissions system. And a configuration option to select whether you want the old / new system. Would that make sense to have it in Core?
The pre-4.7.1 inheritance model had issues (how do you indicate eg that user "can update all nodes below that node") but, as you said, I fail to see the benefits of the new system and the use cases it solves...
Thanks Stephen. So it's not just me that is going crazy :-)
I don't think we will make our own patches since that will probably come back to haunt us later, but I do worry that it will get harder to keep permissions in synch when working with them programatically.
Well that's the point, we have various pieces of code maintaining permissions programatically depending on what users do, and with the new system they all fail or would need to be re-engineered, which would require time + budget. In addition, I'm not fully confident that the new system is going to solve everything. So we're in "wait and see" mode, still using the old system...
The new system probably requires some fixes + some documentation and "how to". Sadly I have to resist the urge to dig into it. Too many things to do right now.
I'm doing a bit of playing around with it, and I think there is another side effect of the new model. The problem is that it is not possible to determine for at node if it's permissions were set explicitly, or if the were "inherited" from the parent node a creation time.
Scenario of moving a node:
- English (abcd) - - News (abcd) - - Products that should have been in danish site (abcd) - Danish (a) - - News (a)
Now, I want to move the Products node to the danish site where it was suppose to be. That will result in the following permission set:
- English (abcd) - - News (abcd) - Danish (a) - - News (a) - - Products that should have been in danish site (abcd)
So the user that is only supposed to have extra permissions in the english site, now suddenly has those permissions on a node in the danish site. And since there is no way to tell if the abcd permissions were "inherited" or explicitly set, there is no way to handle that scenario except for an admin user to go and reset permissions for all nodes in the danish site.
We tried creating a script for resetting the permissions for the users, so that the would be inherited. the script ended up running for 8 hours, and creating 1.3 million rows in the permissions table.
Obviously that is not going to work in the long run, so we ended up skipping the permissions model all together, and just restricting access to the tree using the events on the BaseTree class.
So if anyone are facing the same issue, then that would be one way of solving it.
At least I'm saying that it does not work for our kind of scenario with a whole lot of user needing permissions on a whole lot of nodes.
It might work if you want to use it backwards with granting default permissions to the user type, and then restricting access to certain nodes instead, such as
So I'm having a hard time figuring out what the user story is for using permissions, and therefore we decided to skip it all together so we have full control.
Trying to find out a good way to work with permissions as well, processes described above match problems that I'm facing. How did you all end up working with permissions?
Recent breaking changes to the user permissions
We just ran into an issue with the new way that permissions work in version 4.7.1
This is from the changelog:
"We’ve changed the way inherited content permissions works, so Umbraco defaults to the Usertype permis-sions of a User if no specific permissions has been sat on a node. Complementing this, Umbraco will now au-tomatically copy the specific permissions of a parent when creating a new page."
I was quite surprised when I saw saw this new behaviour. It seems that this change actually breaks the permissions that are set up in an existing site, if that site relies on inheritance. In our case it does not help that we have ~ 100 editors in a site with 10.000 nodes. It means that we need to actively do some migration just to keep status quo, and it also means that the umbracoUser2nodePermission table will grow a lot.
Could the core team elaborate a bit on why this (in my opinion "breaking") change was made in a minor update? I suspect that many site owners will be as surprised as we were that permissions suddenly work differently.
Which usecases is this specifically designed to solve, that the inheritance model could not?
I can see at least one scenario that this new behaviour would cause problems.
Consider a nodetree like this, where the current user has the permissions liek (abc)
- English (abcd)
- - News (abcd)
- - - Multiple items (abcd)
- - Products (ab)
- Danish (a)
- - News (a)
- - Products (a)
So the user has permissions abcd on the english site, except for the Products pages. Now i want to change the general permissions for the englsih site to abcde. In order to do that, I need to select all nodes _except_ the Products one to update the permissions. If inheritance was used i only needed to change the "Englsih" permissions, since all subnodes with no other explicit permissions would then automatically inherit those new permissions.
Am I missing an advantage of the redundant permission data?
Looking forward to some insight
/Morten
In any case, as you do mention, these changes do break existing sites that relied on the previous permissions esp. regarding inheritance. Which is why we're running 4.7.1.1 with a custom patch to revert to the previous permissions system. And a configuration option to select whether you want the old / new system. Would that make sense to have it in Core?
The pre-4.7.1 inheritance model had issues (how do you indicate eg that user "can update all nodes below that node") but, as you said, I fail to see the benefits of the new system and the use cases it solves...
Thanks Stephen. So it's not just me that is going crazy :-)
I don't think we will make our own patches since that will probably come back to haunt us later, but I do worry that it will get harder to keep permissions in synch when working with them programatically.
Well that's the point, we have various pieces of code maintaining permissions programatically depending on what users do, and with the new system they all fail or would need to be re-engineered, which would require time + budget. In addition, I'm not fully confident that the new system is going to solve everything. So we're in "wait and see" mode, still using the old system...
The new system probably requires some fixes + some documentation and "how to". Sadly I have to resist the urge to dig into it. Too many things to do right now.
I'm doing a bit of playing around with it, and I think there is another side effect of the new model. The problem is that it is not possible to determine for at node if it's permissions were set explicitly, or if the were "inherited" from the parent node a creation time.
Scenario of moving a node:
- English (abcd)
- - News (abcd)
- - Products that should have been in danish site (abcd)
- Danish (a)
- - News (a)
- English (abcd)
So the user that is only supposed to have extra permissions in the english site, now suddenly has those permissions on a node in the danish site. And since there is no way to tell if the abcd permissions were "inherited" or explicitly set, there is no way to handle that scenario except for an admin user to go and reset permissions for all nodes in the danish site.- - News (abcd)
- Danish (a)
- - News (a)
- - Products that should have been in danish site (abcd)
A quick update on this.
We tried creating a script for resetting the permissions for the users, so that the would be inherited. the script ended up running for 8 hours, and creating 1.3 million rows in the permissions table.
Obviously that is not going to work in the long run, so we ended up skipping the permissions model all together, and just restricting access to the tree using the events on the BaseTree class.
So if anyone are facing the same issue, then that would be one way of solving it.
But... If I understand correctly, you're saying that the new permissions system just can't be used and you had to skip it entirely?
Maybe it deserves a CodePlex issue, because as more users start working with 4.7+ we're going to run into troubles...
At least I'm saying that it does not work for our kind of scenario with a whole lot of user needing permissions on a whole lot of nodes.
It might work if you want to use it backwards with granting default permissions to the user type, and then restricting access to certain nodes instead, such as
- English (default perms)
- - News (restrict)
- - - Item 1 (default perms)
But the problem is that when you create Item 2, it will inherit from the parent:
- English (default perms)
- - News (restrict)
- - - Item 1 (default perms)
- - - Item 2 (restricted as "News")
So I'm having a hard time figuring out what the user story is for using permissions, and therefore we decided to skip it all together so we have full control.
And yes, a codeplex issue probably would be nice in order to at least raise the flag.
Created codeplex issue: http://umbraco.codeplex.com/workitem/30686
Hello
I know this has been a while, but did anything come of this? Facing a similar problem now with permission inheritance.
Trying to find out a good way to work with permissions as well, processes described above match problems that I'm facing. How did you all end up working with permissions?
is working on a reply...