We have moved to GitHub Issues
Created by Jeffrey Schoemaker 22 Jun 2016, 12:59:59 Updated by Sebastiaan Janssen 17 Sep 2017, 09:22:40Tags: PR
Is duplicated by: U4-12
Depends on: U4-9155
Parent for: U4-2474
Parent for: U4-6411
Parent for: U4-7907
Parent for: U4-8643
Parent for: U4-9831
Parent for: UAASSCRUM-913
Parent for: UAASSCRUM-914
Parent for: UAASSCRUM-915
Parent for: U4-9888
Parent for: U4-9889
Parent for: U4-9900
Parent for: U4-9913
Parent for: U4-9914
Parent for: U4-9915
Parent for: U4-9944
Parent for: U4-9946
Parent for: U4-9963
Parent for: U4-9964
Parent for: U4-9965
Parent for: U4-10023
Parent for: U4-10053
Parent for: U4-10059
Parent for: U4-10075
Parent for: U4-10083
Parent for: U4-10095
Parent for: U4-10096
Parent for: U4-10196
Parent for: U4-10104
Parent for: U4-10106
Parent for: U4-10107
Parent for: U4-10109
Parent for: U4-10111
Parent for: U4-10126
Parent for: U4-10133
Parent for: U4-10134
Parent for: U4-10138
Parent for: U4-10142
Parent for: U4-10146
Parent for: U4-10155
Parent for: U4-10173
Parent for: U4-10174
Parent for: U4-10175
Parent for: U4-10202
Parent for: U4-10210
Parent for: U4-10212
Parent for: U4-10227
Parent for: U4-10228
Parent for: U4-10230
Parent for: U4-10231
Parent for: U4-10233
Parent for: U4-10235
Parent for: U4-10236
Parent for: U4-10237
Parent for: U4-10243
Parent for: U4-10244
Parent for: U4-10256
Parent for: U4-10257
Parent for: U4-10265
Parent for: U4-10278
Parent for: U4-10279
Parent for: U4-10280
Subtask of: UAASSCRUM-1073
A feature we all wanted for a long time is Usergroups. During CG16 I've discussed the functionality with a lot of people and this is a sort of summary of the requested functionality.
Worth a good discussion:
Some more inspiration can be found here: http://umbraco.usermanagement.perplex.eu/specificusergroup.html (see different tabs)
Thanks for creating this issue Jeffrey - I was also at the CG16 session and have been giving this feature a bit of thought too since then. Had a couple of points for discussion on your specification above.
On the point ''"In the contenttree => Permissions are set on grouplevel"'' - whilst this sounds like it might be simpler were the system being designed from scratch, I think permissions being set on the user level would have to remain as well. Mainly due to site upgrades - if user permissions were removed and instead set on groups, then given a situation where a site has a number of users with permissions set, really the only way I can see to migrate this automatically would be to create one group per user - which isn't likely what is wanted.
It's also perhaps of value to allow setting of permissions on the user or the groups. Could be a simple setup doesn't need groups. Or could be some particular user exceptions were it's handy to set most permissions on groups, but some on users as well.
Given that though as you say the "net" permissions would be the most permissive set for all the groups and the specific user permissions your account has. So if a user is in a group that can do A, another group that can do B and their direct user permissions allow C - then they can do A, B and C.
User types and groups
Seems there's two approaches here - what's outlined above (and discussed at CG16), which is to effectively migrate user types to groups. So instead of having a many to one relationship between users and user types, we'd have a many to many relationship instead. Again, if starting from scratch, that would likely be the simplest set up. Alternatively though we could keep types and have groups as well. Not sure what's best here but wanted to high-level outline some considerations for each.
Move from types to groups:
-Rework database structure to remove many to one and introduce many to many relationship between users and user types. -Rework such that a user can be created without a type (currently a type is required in the constructor). -Refactor names so "types" become "groups". To bring things in line with how groups are referred to in terms of members. Might be would live with the database table and field names being "wrong", but ongoing it would likely be clearer to refer to "groups" in the code and UI. -Set up an upgrade migration process for the schema changes -Set up an upgrade migration process for user data - so each type would become a group with the same default permissions, and all users of each type would be assigned to the group -Implement UI and logic for creating groups, setting their default permissions and adding users to them. -Implement UI and logic for setting section and node specific permision on groups. -Implement permissions for a user's access sections and nodes based on the net most permissive set of permissions based on all their groups and their direct user permissions.
Keep types and introduce groups:
-Likely simpler (certainly less intrusive) from a coding perspective. Types would remain and groups would be an added feature. -Migration would be simpler. We'd just introduce, new, empty tables for groups, group/users, group/sections and group/node permissions. Users, types and existing permissions would stay as they are. No need to transform data. -Maybe in future having types as well as groups would be useful (say if properties were added like with members)? -If someone just wanted to carry on with the current setup they could, and ignore groups. -Downside though perhaps is for new users - being able to set permissions on types, groups and users may be more confusing than it needs to be. -Implement UI and logic for creating groups, setting their default permissions and adding users to them. -Implement UI and logic for setting section and node specific permission on groups. -Implement permissions for a user's access sections and nodes based on the net most permissive set of permissions based on their type, all their groups and their direct user permissions.
thanks for your comment! I've had some post-CG-stress, so hadn't time to comment back on your comment, but finally found some time.
=== User permissions === Assigning permission on a group- and a userlevel would be fantastic, but I have no idea on the impact of complexity when building it. Also we have to make sure that it's pretty easy to trackback which user has which net permission set.
=== User types and groups === I agree that is probably more complex to remove the types and introduce groups, but seen from a end user or new user-perspective it should make more logic to only have groups, I guess. I am wondering how other CMS's handle this?
I know we have to be keen on upgrading existing sites, but I think we should design the end-solution first and then see if there's a upgrade path available. If not, I don't have a problem that it's only released into Umbraco 8 and loose some backwards compatibility. I'd rather have a good end solution than a solution that has an upgrade path.
I'm wondering what the opinion of HQ is about this. I'm willing to start making some sort of wireframe/design, but some guidance would be useful. I'll be gone for a long summer holiday, but will try to come up with something after that?
I've had a bit of time to start looking at this, the results of which are in this PR: https://github.com/umbraco/Umbraco-CMS/pull/1384. I've implemented here something that follows what I described above in "Keep types but add groups". I'm a bit torn as to whether that's best but I suspect the ease of upgrading existing solutions may make it the better option (and if not, it may still be a step on the way to the larger change that migrates a single user type to multiple user groups).
Thanks for putting this all together, I replied to the PR here: https://github.com/umbraco/Umbraco-CMS/pull/1384#issuecomment-234485519 and was just explaining that having both user and group permissions might add too much complexity. I'm mostly worried about performance because currently the way user permissions is structured is less than ideal and depending on how many are assigned can cause the cache size to become enormous. If we have 2x this same cache structure bad things could start to happen.
I haven't reviewed the code just yet but will let you know when I do, perhaps it is actually ok :)
Last thing to note, because we've been talking about this for many many years and I believe that this same document has been written over and over again (and then lost), there was always an idea of having an additional permission of "Deny". Currently we don't have any "Deny" permissions but this becomes very powerful and flexible. Deny would always trump an allow and with overlapping user and user group permissions, it may become an important thing to have. That said, it also adds more complexity.
Just wanted to bump up this feature request and add my two cents.
This (missing user roles) is definitely one area where Umbraco falls short of its commercial competitors when evaluating for a large / multi-site deployment. Something I am currently evaluating CMSs for...
Shannon to your point about 'Deny' permissions, I think it adds flexibility, but at the cost of complexity. In the majority of cases(?) you can usually achieve the same permission set with a default of 'deny' all and add explicit 'allow' permissions - which are by inherited by child nodes in the content tree unless the child node has its own set of permissions (user's might need some action to clear permissions and 'use the parent permissions').
Also, role-based inherited permissions should also be able to be applied to the Umbraco Forms section in backoffice, which would need the concept of a 'folder' added within forms + worflows + datasources. That way permissions can be applied to a folder and be inherited by all children.
Given this feature could be a breaking change, it seems like the ideal candidate for a major release, say Umbraco 8? Any chance of this?
Hi, thanks for the feedback. With regards to Deny, we'd still need the notion of 'Deny' to be able to have any default deny settings, we currently don't have this notion at all which is why I'm saying we could/should add it.
This doesn't have to be a breaking change, there's no reason to wait till v8 to achieve this if we don't have to. When we find some time we'll be reviewing/tweaking Andy's PR. We'd like to try to keep this as simple as possible, permissions currently are not stored in a simple manner and consume a ton of cache memory if there are a lot applied, so having permissions set per member and per role still doesn't sit well with me and then if we add Deny as well, things will become very complex (which will result in performance penalties).
I totally agree that we should be able to make the permissions APIs utilized by other parts of the system, so Forms could plugin to it's pipeline as well instead of storing it's own permissions structure - but we'll see how complex that becomes since that might require large db changes and in which case might have to wait until v8.
We will certainly be reviewing all of this soon, there's just a few things on the HQ plate currently that we need to get completed first.
We would like to proceed with getting this into the core for a 7.x release, however as I previously mentioned, the decision has been made to simplify this implementation. We will only have user groups assigned for permissions.
The reason for this decision is to maintain simplicity, having permissions assignable for both user groups and individual users adds a lot of complexity and it will add a ton of memory and lookup implications. Currently the memory utilized for storing the permissions is huge (I'd like to fix this in the future ... but we can cross that bridge later). If people truly want single user permissions, it's easily solved by creating a group for that particular user.
So moving forward, we'll need to update this PR to just have permissions assignable at the user group level and that is it. This should hopefully simplify much of this code and probably allow us to remove quite a bit too.
The upgrade plan will be pretty simple:
Once that is done then the admin after upgrading can move users to different user groups, etc.. but this will maintain the same permissions as they had previously. As for deny permissions, this is also something we can look at in the future, the first plan will just be to get user groups working for permissions. At some stage we'll also have to update the user membership provider and the user identity implementation to return these groups as roles.
OK, noted. I'll try to take a look back at my PR and see if can be updated (or used as a resource for a new one) to match this simplified requirement. Currently quite busy and will need to get my head back into it, so not sure quite when - so if anyone else wants to pick at what I've done please feel free.
Started to have a look at reworking my PR to match this @Shandem. You've discussed node permissions above, but how do you want to handle user/app (sections like "content", "media") permissions? It would seem to follow to move them to groups as well. But then would mean if a user is created and not added to a group, they would have no app permissions - and hence in practice you'd have to create and add them to at least one group. That sound OK to you?
Hi @abutland great news :) Very interesting point about the app permissions but yes I'd concur that they should be done at the user group level too since we'll do all permissions by group. The only thing I can think of is that we have one (or more) built in groups that cannot be removed via the API and are installed probably with custom system IDs like we have for other system entities. We sort of have this already now with 'editor' 'admin' 'translator', so maybe we keep those but make them user groups that cannot be removed, then by default we can add a user to the 'editor' group. Something like that work?
It would I imagine yes. It sounds then like we need to also migrate the current user types to become user groups. I discussed pros and cons of this a little at the top of this issue. In short I think it's how you would design it if starting from scratch but it'll add complexity to the code changes and the data migrations for upgrades.
Yup we'll definitely have to do that. User Types currently don't really do anything, all they do is provide a way to have 'default' permissions for a given user. But if they are groups, then they are the permissions.
We can deal with the upgrade data later on, we'll worry about getting it functional now first :)
Have created another PR for review now here: https://github.com/umbraco/Umbraco-CMS/pull/1559
Type: Feature (planned)
Backwards Compatible: True
Fix Submitted: Pull request
Due in version: 7.7.0
Sprint: Sprint 58