Coming from a SharePoint background one thing I think Umbraco seriously lacks is finer control over members and users.
Many of us are using Umbraco to house multiple sites for different companies on one installation. The current backoffice users security model only really allows the admin of all the sites to create new users. There isn't anything built in that allows me to setup an admin for a subsite that gives him permissions to add backoffice users (writers, editors, etc.) to his specific site only. The same goes for members. Each subsite needs the ability to have access to its members and not the whole Umbraco installation members.
Now, member groups could be used to lump each subsite's members together. This could be used to create a custom Umbraco "section" for subsite users to only access their member group. It would be transparent to them. They would just choose Members section and see only their members. Each subsite could have its own membership creation control that references the Umbraco Member API using their member group ID etc... Rather easy work around. However, there is no "User Group" functionality in Umbraco to make use of my members work around idea.
I honestly don't have time to administrate user permissions on all the sites. The companies should be able to do that themselves. What is the point of giving them access to create content and then have to rely on me to create users for them.
We need to be able to setup admin users for each site and allow them to create users with equal or lesser permissions for access to their subsite backoffice. We need to be able to assign member groups to either a domain (like manage domain name or set root node).
This is one of the issues that I believe is keeping Umbraco from being really enterprise ready.
First of all, it is always nice to hear about what other umbraco users are missing in umbraco. I have not had the need for this myself, so I would like to get the scenario right.
It seems that your sites are rather separated since there needs to be this sort of separation between the users/members?
What is the reasoning behind not splitting those sites into separate umbraco installs with completely separate database and so on? Is it to be able to reuse code, or are there some other common things between the sites that would rule out a clean separation of the sites?
Being able to reuse code, document types, etc. without the need to create packages is one reason.
It makes managing a number of websites much easier when you can log in as the admin and see them all there, access their content, update their controls, make upgrades. Say I have 10 websites each with an separate Umbraco install and I want to push out a new feature to all of them. I have to go into each instance and repeat the same procedure 10 times. However, if they were split into 2 installs with 5 websites on each it would reduce the amount of work I have to do.
Another example would be like setting up a company's site as an Umbraco install that has several subsidiaries (business units) with their own brand and websites. The mother company would want access to all the members collected from the sub-sites in one place. Umbraco can do that. They could use that information to cross sell, push out targeted ads (member groups), email campaigns, etc. However, they want each business unit to handle their own members (member group) and content. They want to limit each business unit to their portion of the mother website but still have the freedom to add/disable writers/editors/translators. This cuts down on the content be duplicated in several places.
Umbraco would just need some finer grain security rules to make this work.
Some more thoughts:
Reduces the number of databases needing to be backed up
Reduces the number of instances to upgrade with Umbraco puts out a new version
Reduces server costs - hard drive space
Reduces application pools on server
Easier to monitor uptime for multiple sites at once
Shared assets but not shared permissions
Reduces the need for external "Keep Alive" service as multiple small sites generate enough traffic to keep the app pool open organically
Okay. Makes sense to keep it together in a single install.
Coming up with the right security model for this scenario is however not an easy task. Especially if it needs to be generalized.
I don't think that defining one member group per domain is the way to go, since each site may have multiple member groups such as basic/plus/admin and so on. Also a user might not have permissions on any type of content, but should be allowed to manage certain member accounts.
So in order to define a users permission to edit a member, there will need to be more than one parameter. For example, is the user allowed to add/remove the member to/from other groups?
Also there would probably need to be a better form of inheritance between users, so that you could easily create a new editor for a certain website, so that he automatically inherits permissions for the correct content/membergroups/media and so on.
Taking all this into account, I don't see this happening in version 4.x, since this is in no way supported by the infrastructure of umbraco at the moment.
As for version 5, I have not seen any roadmaps, and I am not sure what the ambitions are on this sort of feature. But if I know Niels, I think he would probably argue that it is best to keep it simple, since that covers the needs of a large amount of the users.
Alternatively, I do think that you might be able to at least implement some of this sort of functionality as an extension of umbraco, to fit your specific needs. By hooking into rendering events on the content/media/member tree, you could make your own assertions on whether this user is allowed to click on this member or not, and then choose not to render ti if the user has no permissions.
This is of course not the same as having it out of the box, but might solve you immediate needs. Let me know if this is a road you might consider taking, and we can try and work out a way of doing this.
I understand about keeping it simple but let's be honest Umbraco is way beyond that point now. :)
User inheritance seems like something that would have made sense to implement from the beginning.
The membership thing I could probably create by extending Umbraco and adding another section much like the "Members" that would use the users credentials to show the correct member group. The backoffice users is another thing. I could create my own UsersMembershipProvider coupled with extension...but I don't know the user api well enough yet to know if I could pull it off. Let me look into the api a bit more and I will let you know if I move forward with writing an extension.
You have absolutely 100% hit the core of an earlier problem I had. In v4.0 I made a shadow Member set in a custom section with matched the original exactly, simply because I used everything I could find on the Koders site (classes and what more). I then added the missing functionality in several places using a 'simple table' which stored which member belonged to which root. In this way the members were separated in the 'Back End' of Umbraco and depending on the rootnode website 'owners' could only see and deal with their own members. I did this only for the members, not for member groups, because there was no need for that.
I was very pleased with my own approach, because it did exactly what I and you (and others perhaps) were/are also missing.
To me it is a big question why this is not part of the original plan since my solution was relatively simple. Why should anyone have to wait for v5 is a mistery tot me.
In v4.6.1 I had to re-invent the trick, because there I bumped into an XmlDocument problem which I did not have the time (or the knowledge) for to tackle. So I made things a little easier. In short, the 'simple table' holds a few parameters for each member. Among them are the domainId and the nodeId of the member. It allows members to join more than one website with their login name (which equals their e-mail code) and the manager of the website only 'sees' his own members, whereas in the original Member menu you still see all members, independent of their domeinId. Allthough you can edit any data in the 'Back End' I allow members to join the system only in the ' 'Front End' because that is the place and time where the system knows who is who and where.
Maybe you have created your own solution months ago, but I hope that others may also benifit from this little shortstory.
Gotta say i'm running into the same problem now - not found anything yet to only allow a user to see/create/modify the users they are supposed to and the only way I can see forwards is to create a new dashboard control that provides this functionality
Member Groups and User Groups - Finer Control
Coming from a SharePoint background one thing I think Umbraco seriously lacks is finer control over members and users.
Many of us are using Umbraco to house multiple sites for different companies on one installation. The current backoffice users security model only really allows the admin of all the sites to create new users. There isn't anything built in that allows me to setup an admin for a subsite that gives him permissions to add backoffice users (writers, editors, etc.) to his specific site only. The same goes for members. Each subsite needs the ability to have access to its members and not the whole Umbraco installation members.
Now, member groups could be used to lump each subsite's members together. This could be used to create a custom Umbraco "section" for subsite users to only access their member group. It would be transparent to them. They would just choose Members section and see only their members. Each subsite could have its own membership creation control that references the Umbraco Member API using their member group ID etc... Rather easy work around. However, there is no "User Group" functionality in Umbraco to make use of my members work around idea.
I honestly don't have time to administrate user permissions on all the sites. The companies should be able to do that themselves. What is the point of giving them access to create content and then have to rely on me to create users for them.
We need to be able to setup admin users for each site and allow them to create users with equal or lesser permissions for access to their subsite backoffice. We need to be able to assign member groups to either a domain (like manage domain name or set root node).
This is one of the issues that I believe is keeping Umbraco from being really enterprise ready.
Hi Rick.
First of all, it is always nice to hear about what other umbraco users are missing in umbraco. I have not had the need for this myself, so I would like to get the scenario right.
It seems that your sites are rather separated since there needs to be this sort of separation between the users/members?
What is the reasoning behind not splitting those sites into separate umbraco installs with completely separate database and so on? Is it to be able to reuse code, or are there some other common things between the sites that would rule out a clean separation of the sites?
Being able to reuse code, document types, etc. without the need to create packages is one reason.
It makes managing a number of websites much easier when you can log in as the admin and see them all there, access their content, update their controls, make upgrades. Say I have 10 websites each with an separate Umbraco install and I want to push out a new feature to all of them. I have to go into each instance and repeat the same procedure 10 times. However, if they were split into 2 installs with 5 websites on each it would reduce the amount of work I have to do.
Another example would be like setting up a company's site as an Umbraco install that has several subsidiaries (business units) with their own brand and websites. The mother company would want access to all the members collected from the sub-sites in one place. Umbraco can do that. They could use that information to cross sell, push out targeted ads (member groups), email campaigns, etc. However, they want each business unit to handle their own members (member group) and content. They want to limit each business unit to their portion of the mother website but still have the freedom to add/disable writers/editors/translators. This cuts down on the content be duplicated in several places.
Umbraco would just need some finer grain security rules to make this work.
Some more thoughts:
Okay. Makes sense to keep it together in a single install.
Coming up with the right security model for this scenario is however not an easy task. Especially if it needs to be generalized.
I don't think that defining one member group per domain is the way to go, since each site may have multiple member groups such as basic/plus/admin and so on. Also a user might not have permissions on any type of content, but should be allowed to manage certain member accounts.
So in order to define a users permission to edit a member, there will need to be more than one parameter. For example, is the user allowed to add/remove the member to/from other groups?
Also there would probably need to be a better form of inheritance between users, so that you could easily create a new editor for a certain website, so that he automatically inherits permissions for the correct content/membergroups/media and so on.
Taking all this into account, I don't see this happening in version 4.x, since this is in no way supported by the infrastructure of umbraco at the moment.
As for version 5, I have not seen any roadmaps, and I am not sure what the ambitions are on this sort of feature. But if I know Niels, I think he would probably argue that it is best to keep it simple, since that covers the needs of a large amount of the users.
Alternatively, I do think that you might be able to at least implement some of this sort of functionality as an extension of umbraco, to fit your specific needs. By hooking into rendering events on the content/media/member tree, you could make your own assertions on whether this user is allowed to click on this member or not, and then choose not to render ti if the user has no permissions.
This is of course not the same as having it out of the box, but might solve you immediate needs. Let me know if this is a road you might consider taking, and we can try and work out a way of doing this.
I understand about keeping it simple but let's be honest Umbraco is way beyond that point now. :)
User inheritance seems like something that would have made sense to implement from the beginning.
The membership thing I could probably create by extending Umbraco and adding another section much like the "Members" that would use the users credentials to show the correct member group. The backoffice users is another thing. I could create my own UsersMembershipProvider coupled with extension...but I don't know the user api well enough yet to know if I could pull it off. Let me look into the api a bit more and I will let you know if I move forward with writing an extension.
Cheers.
Hi Rick!
You have absolutely 100% hit the core of an earlier problem I had. In v4.0 I made a shadow Member set in a custom section with matched the original exactly, simply because I used everything I could find on the Koders site (classes and what more). I then added the missing functionality in several places using a 'simple table' which stored which member belonged to which root. In this way the members were separated in the 'Back End' of Umbraco and depending on the rootnode website 'owners' could only see and deal with their own members. I did this only for the members, not for member groups, because there was no need for that.
I was very pleased with my own approach, because it did exactly what I and you (and others perhaps) were/are also missing.
To me it is a big question why this is not part of the original plan since my solution was relatively simple. Why should anyone have to wait for v5 is a mistery tot me.
In v4.6.1 I had to re-invent the trick, because there I bumped into an XmlDocument problem which I did not have the time (or the knowledge) for to tackle. So I made things a little easier. In short, the 'simple table' holds a few parameters for each member. Among them are the domainId and the nodeId of the member. It allows members to join more than one website with their login name (which equals their e-mail code) and the manager of the website only 'sees' his own members, whereas in the original Member menu you still see all members, independent of their domeinId. Allthough you can edit any data in the 'Back End' I allow members to join the system only in the ' 'Front End' because that is the place and time where the system knows who is who and where.
Maybe you have created your own solution months ago, but I hope that others may also benifit from this little shortstory.
Jacques
Hi Rick,
This is exactly the kind of thing I want to do. Did you come up with a solution?
Jaques - Is there any chance you could share more of the details of how you implemented this/solved this issue?
Mike
Gotta say i'm running into the same problem now - not found anything yet to only allow a user to see/create/modify the users they are supposed to and the only way I can see forwards is to create a new dashboard control that provides this functionality
is working on a reply...