We have developed our intranet for a reasonably large organisation using umbraco, however, from what I can tell the current permissions model isn't suitable for our needs.
Firstly each department will need to have a lead editor with several content writers potentially beneath them. Additionally there are several sensitive 'developer nodes' dotted around, these contain user controls and various pages set up to house custom applications, they are most certainly not for general consumption.
From what I can tell I need to set up each user separately, go through each node, assign access to sections they need and strip off permissions for all developer nodes. This isn't practical for 30+ content editors. Especially when adding new developer only nodes, we would have to go through each user and make sure they can't delete, move or otherwise tinker with them.
Another problem we're facing is that our news section has a top level news node containing a user control which auto-populates the most recently published news stories. News articles sit underneath this node for logical reasons. If we restrict access to the top news node to prevent editors from deleting it then any subsequent child nodes can't be deleted either.
If anyone can give me some advice on how to tackle these problems and can anyone let me know the road map for the permissions model in future Umbraco releases.
It might be possible to look up a user's role membership (using whatever role management solution your organization has) when they sign in to the back office, and update that user's per page permissions based on their role in the ValidateUser method of the MembershipProvider you're using for the back office.
If I get such a solution working, I'll be sure to post it here.
User permissions - groups of users and inheritance
We have developed our intranet for a reasonably large organisation using umbraco, however, from what I can tell the current permissions model isn't suitable for our needs.
Firstly each department will need to have a lead editor with several content writers potentially beneath them. Additionally there are several sensitive 'developer nodes' dotted around, these contain user controls and various pages set up to house custom applications, they are most certainly not for general consumption.
From what I can tell I need to set up each user separately, go through each node, assign access to sections they need and strip off permissions for all developer nodes. This isn't practical for 30+ content editors. Especially when adding new developer only nodes, we would have to go through each user and make sure they can't delete, move or otherwise tinker with them.
Another problem we're facing is that our news section has a top level news node containing a user control which auto-populates the most recently published news stories. News articles sit underneath this node for logical reasons. If we restrict access to the top news node to prevent editors from deleting it then any subsequent child nodes can't be deleted either.
If anyone can give me some advice on how to tackle these problems and can anyone let me know the road map for the permissions model in future Umbraco releases.
Thanks.
I'm in the same boat. Did you come up with a solution? IMHO, the entire permission model needs rebuilt.
There is a Usergroup Umbraco package out there, which allows you to assign per page permissions based on user type rather than individual users.
I get the impression that it doesn't work for v7 yet (based on the feature requests), but it is something.
Package: http://our.umbraco.org/projects/backoffice-extensions/usergroup-permissions Source: https://github.com/rsoeteman/usergrouppermissions
It might be possible to look up a user's role membership (using whatever role management solution your organization has) when they sign in to the back office, and update that user's per page permissions based on their role in the ValidateUser method of the MembershipProvider you're using for the back office.
If I get such a solution working, I'll be sure to post it here.
is working on a reply...