Disclaimer: I've started typing and it became a huge forum post and didn't have enough time to rewrite everything so it had some more structure. Hopefully it still makes any sense... I've typed everything that I could thought of that would be important regarding Users and Groups. And don't get me wrong. Umbraco HQ is doing great work on this (#h5yr), but I these issues come for our experience with clients and I think not all are solved yet. End of disclaimer
Last week I did some testing on Umbraco 7.7 and as I was clicking through the backoffice I came into some weird constructions. But to start I went back to those use cases that I couldn’t solve easily before in Umbraco and I was wondering whether it would be easier in Umbraco 7.7.
Thought 1: Multiple start nodes
We have a multisite-solution with a structure like this (usecase 1.1)
Primary School A
News
Blog
Contentpages
Primary School B
News
Blog
Contentpages
Primary School C… Etcetera
In the simple situation there are contenteditors that would to have the option to create Newsitems for School A and B only (usecase 1.2).
Or we have a multidepartment solution like this:
Hospitalwebsite
Departments
Cardiology
News
Contentpages
Radiology
News
Contentpages
Oncology
News
Contentpages
Urology… Etcetera
The simple situation we were having here were contenteditors that work for two departments and should edit news and contentpages.
In Umbraco 7.6 and before they should have a common starting node and you should settings to their childnodes. But everytime there was a new school added or department you would have to set these permissions again.
In Umbraco 7.7 we could pick multiple startnodes like “News” in School A and B. I’ve setup a testsite that looks like this:
And created a content editor like this:
But when the content editor logs on it looks like this:
And that is quite confusing because which “News” is related to which site? And keep in mind that this is a simple use case.
It could also be the case that this person could edit one page under the “About us”-page. In that case the tree looks like this:
In that case it’s no longer obvious that History and one of the News-items (Which one?) is part of the same site / parent node. (Problem 1: No relation between nodes when having multiple start nodes)
If you give the news nodes a prefix of (1) and (2) so the structure looks like this:
The news editor will see it in a different order, where you even less see that the page History and Nieuws (1) share the same parent node:
(Suggestion 1) My suggestion of solving this would be showing always the common parent nodes, if any. And you could not open these nodes themselves but the still give some relation to where they are in the sitemap/contenttree.
We did the same when we introduced folders in our Umbraco Forms On Steroids-package (https://our.umbraco.org/projects/backoffice-extensions/umbraco-forms-on-perplex-steroids/). We’ve made a video about it: https://www.youtube.com/watch?v=vaQsr2uY3bA&feature=youtu.be. And ther you see if you give someone access to a nested node you will see the contextual parent nodes, but you cannot open them (they’re greyed out).
I think that could be a good option for this use case too.
Ok, next… Usecase 1.2….
But if we want this content editor only to create and update news and not edit the newsoverviewpage (which has settings and really important content that they may not edit). We still would use this structure, but we would have to set individual permissions for this group.
In the new situation I would click on “Nieuws (1)” and would edit the permissions so that the editor would only have “Create” permissions on the “Newsoverview”-page; like this:
But if I set it like this the permission settings on the ‘Newsoverview’ flow down to their child nodes and thus you have no publish rights. Although it first looks like that. (Problem 2: And raised an issue here http://issues.umbraco.org/issue/U4-10265)
Another problem is that even if this would work, all these permissions needs to be set for every newsoverview-page (so also in site B, site C, etcetera).
Suggestion 2: A suggestion I’ve raised two years ago in my Skrift-blogpost about Usermanagement (http://skrift.io/articles/archive/i-have-a-dream-about-user-management-in-umbraco/) is to have basis CRUD-options per doctype per usergroup. See the security-tab on http://umbraco.usermanagement.perplex.eu/doctypeeditor.html.
I know this is a totally different approach than what currently is in place in Umbraco, but I think that would solve the real underlying issue that we need in real life. We want to give groups rights to create certain document types, update them (essentially publish them or save them, depending on their permissions… Or separate ‘Save’ and ‘Publish’-rights??), delete them (nobody, except Administrator should ever delete the Homepage for example. But if you have “Delete” permission by default (because you’re allowed to delete newsitems, you’ll also would have delete rights on the Homepage)) and Read-rights (you see the node, but cannot do anything about it).
If you compare these to the current permission set on usergroups:
I would say that you would have to remove the following permissions and put them on document types:
Browse Node (“Read”)
Delete (“Delete”)
Create (“Save”)
Publish (“Publish”)
Send to Publish (“Save”)
Update (“Publish”)
Copy (“Create” => If you have Create rights for that type of content, you may always copy… Why not?)
Move (“Create”)
Sort (“Publish”??)
(Headache 1) This is giving me headaches for a few nights now… Because this is a whole different approach than currently, but I think this is what we need to achieve that what we need in real life.
In my use case where I have a newseditor that could see the newsoverviewpage as startnode and could create newsitems;
He/she would have “Read”-rights to the Newsoverview-doctype, and “Read/Create/Update/Delete”-rights to the Newsitem-doctype.
Ok, next use case 1.3: Linking to the homepage or a certain page…
We will reset the startnodes of the newseditor to only see the news of school 1 and 2 (and no longer that one content page under “About us” because that was kind of a silly example)
Let’s say my news editor creates a fantastic newsitem that the company exists 50 years and want to link in that item to the ‘History’-page under ‘About us’.
If you would use the Contentpicker-datatype, or an Rich Text Editor and click the Link-option you would only see this:
I get why they see that, but why can’t I pick other content and link to my history page. I can input directly the Url in the Rich Text Editor, but what if somebody changes the nodename from ‘History’ to ‘Our fantastic history’. The link would no longer work, and that is essentially why we’re using a CMS, aren’t we. (Ok, I know we have a 301 redirect now in Umbraco, but let’s say we’ve disabled that one, because we don’t want 301’s be used in our own site. That should only be used when other websites are linking to us…).
Suggestion 3: If we would always show the whole content tree to pick from (even if it’s outside our startnodes) we could pick this history-page and all would be solved.
But wait (headache 2)… By doing this I would see the content structure of all websites in this solution, so also from school 4, 5 and 6 where I don’t have access to. And that is not what I want.
But would I then need a “Starting node” for in the content tree, and a “Starting browsing node” for pickers…. Aargh, drives me crazy…
Ok, next use case for this section 1.4: Where is my recycle bin?
As a news editor I don’t see a recycle bin. Is that a bug or by design? If my newseditor deletes a newsitem, it should be able to restore these newsitems. Don’t they? Apparently this was an issue in older versions too: http://issues.umbraco.org/issue/U4-239
Use case 1.5 Edit my own userdetailpage as administrator
No user can edit their own userdetailpage. But as an administrator I cannot specify my start nodes either. Is that weird?
Thought 2: Show more on the user detailpage
This one gives me a lot less headaches than the previous one. So that’s nice :)
When writing my blog two years ago I’ve made this page for the users (http://umbraco.usermanagement.perplex.eu/user.html). You guys really did an awesome job on the design of the user page, but in my opinion you should add some properties. Those are already currently available in the database or should be added. (Suggestion 4)
User must change password on next logon. A really important one in my opinion that could also be misused to create “Password aging” (just run a script on the database that if your password hasn’t changed for 6 months now, you could set this field to true). I know there are different opinions about this functionality, but I think it should be in core and every administrator can determine for themselves if they will use it or not.
Account expires. So to make sure that people with temporary contract don’t get overlooked when they quit their job. Fairly easy in my opinion
Failed password attempts; already stored in the database
Last lockout date; already stored in the database
Last password change date; already stored in the database
Create date; already stored in the database
Update date; already stored in the database
All events regarding the user from a logging table (see the ‘Logging’ tab in my page http://umbraco.usermanagement.perplex.eu/user.html). I know currently we do not have these yet, but I think it’s coming pretty soon (Sebastiaan created the events to trigger them (http://issues.umbraco.org/issue/U4-6878)) and it would be fairly easy to store them in a table and show them on a user. As requested in this feature request (http://issues.umbraco.org/issue/U4-10039) I would love to see that (package) developers could add their own info to this page.
Thought 3: More granular permissions for other sections
Ever since Umbraco 4 (and maybe even before that) we have some nice permission sets for the content section (although not for the recycle bin which is a node in the content section), but not for all the other sections. A related discussion to this thought was here (https://our.umbraco.org/forum/umbraco-forms/86655-umbraco-form-encryption) where we will be having issues with GDPR if we don’t have more granular permissions to the Member and Forms-section I guess.
(Suggestion 5) In my opinion (http://umbraco.usermanagement.perplex.eu/usertype.html) we would need more granular permission than only access to a whole section and all rights. But how complex do we want to make it (headache 3):
User section
If you’re having rights to the user section you can always give yourself superadmin rights. If you click to your own userdetailpage, you cannot do anything (not adding groups, not adding startnodes, media nodes, etc), but if you go to the user groups you can click on the “administrator” group (that has access to everything) and just add yourself to it.
An option would be to not make it possible to add yourself to any new groups and only give access to other users. But in that case you could fix this together with a second account and grant yourself more access rights. That doesn’t feel good. So I think you would need more granular permissions like these:
Create users (with no more rights than the current user itself is having?)
With GDPR coming I think there should be a difference between users that can create, edit and delete forms and users that can look to the contents of the filled-in records. Or should they see the form records (a new form entry this morning at 10:00), but they cannot see the field contents of specific fields, where you have check a checkbox ‘Content can only be seen by persons with the permission “See all content”’. So by doing this we would need the granular permissions for this section:
Create form
Edit form
Delete form
Read form submissions
Read form field submissions
Member section
The same concept applies to the member sections and GDPR. Am administrator/developer should have access to member types and edit these, but they should by default not see which members are registered and also not their personal data that are stored in the member properties. So would we need permissions like this:
Create member
Read member
Update member
Delete member
And should we move the “Member types” to the Settings-section where we also store “Document types” and “Media types”
And so on for all other sections…
Or is this making it all too complex for everyone? But on the other we need this probably before May 28, 2018, can we extend this in Umbraco 7.8 or something like that? Or would that require another rewrite of all the work that is done for 7.7… (Still headache 3)
Thought 4: Visual inconsistency
I think the new user section looks great, but still it’s really inconsistent with the rest of Umbraco. I’m wondering if these are the new design guidelines and should be applied eventually to the rest of Umbraco or not.
Some stuff that confuses me:
The users-tree doesn’t really have any more function:
Option 1: Remove the tree all together
Option 2: Add groups also, and maybe the groups and users as children of the node. And if not; give the Users the ListView-symbol in the tree.
A whole lot of button styles together:
To me this looks like as a bit too much colors and styles together. Should be “Disable” just be a checkbox?
Should there be an option “Update password” after clicking “Change password”. Now you only have a cancel option and you’ll have to click there if you want to cancel, and somewhere else to actually change the password. That confuses me. And it would make logging the event “User changed password” much easier to implement.
The checkbox for permission look “Apple-like” but essentially they are checkboxes.
Why is that? Should all checkboxes in the backoffice be updated to this option? Like when you copy content and you have the option “Relate to original” and “Include descendants”:
By the way. For accessibility it would be great if there would be a hover-class so you can see where you’re interacting with.
Different styles for the listview of users and groups
Users have columns and a checkbutton as the first option in a row.
Groups have a different display (not table wise with columns, but more block-ish)
Introducing new colors to the backoffice:
Not using the same (new) contentpicker as in the content section:
Content section:
User/Group-section:
Sometimes highlighting what is already selected and sometimes not:
Just thought I'd add an alternative solution to this problem:
Start Node Suffixes
When choosing start nodes, perhaps the person choosing the start nodes can specify a custom suffix for each of them. That way, they could display like this:
Nieuws (First)
Nieuws (Second)
Why a suffix rather than a custom label to replace the entire content node name? Because a suffix still allows for the content node itself to be renamed and to show the new name in the content tree.
I also like the idea of having the ancestors visible (but inactive) as you've described, though I wonder if maybe some people wouldn't want that information to be visible. For one, it would show content editors what they're missing (making them more inclined to ask for greater permissions). Secondly, it may reveal information that could be sensitive (e.g., if you group a bunch of sites under a "Shared Clients" parent node, the user would then be made aware that they are just one among many clients). Those are fringe considerations, but still thought I'd mention that it could hypothetically be an issue for some people.
Excellent post. I also had these same impressions when testing version 7.7. My case is that of properties in users. I have a client who has several blog editors and he wanted to create custom properties (exactly the same as creating members). I had to customize backoffice editUser.aspx and create custom table. It would be interesting to have a way to add properties to the user.
Just thought I'd add an alternative solution to this problem 2:
An alternative is to display the parent nodes similar to the node selection when configuring the start node in content picker. But it would be interesting only if there is more than one root node
An alternative is to display the parent nodes similar to the node selection when configuring the start node in content picker.
That's a good point. Now that I think about it, the URL list on the properties tab sort of gives you that already (i.e., a path to the node), depending on the URL provider and whether or not domains are configured. Would still be nice to see it in the tree before doing trial and error by clicking through the nodes.
thanks for all feedback! Just a quick update: I've chatted to Niels and Mads from HQ yesterday for about an hour and went through all the feedback.
It was a really positive session and they will figure out how to get some/most of the points in 7.7, or if that's not possible create a roadmap to put in 7.7.x or 7.8.
They're listening and really appreciating the feedback, so keep it coming! Maybe you won't get a immediate response, but they are watching :)
Currently, I'm building a collection of websites similar to this one:
Now I want to create an admin for each site and give him the permission to manage his site users (create an editor, delete editor...). But I noticed that, if I give him the User Section permission he can see also the other sites users.
In short words: "I would like to have: every site has a group of user & there is on Admin who can manage them"
I like the idea about the suffix after the node name for the starting nodes, why not include either the root or the parent node name with some ellipses that you could hover over to see the whole path while using the pickers?
Umbraco 7.7 thoughts regarding Users and Groups
Hi all,
Disclaimer: I've started typing and it became a huge forum post and didn't have enough time to rewrite everything so it had some more structure. Hopefully it still makes any sense... I've typed everything that I could thought of that would be important regarding Users and Groups. And don't get me wrong. Umbraco HQ is doing great work on this (#h5yr), but I these issues come for our experience with clients and I think not all are solved yet. End of disclaimer
Last week I did some testing on Umbraco 7.7 and as I was clicking through the backoffice I came into some weird constructions. But to start I went back to those use cases that I couldn’t solve easily before in Umbraco and I was wondering whether it would be easier in Umbraco 7.7.
Thought 1: Multiple start nodes
We have a multisite-solution with a structure like this (usecase 1.1)
In the simple situation there are contenteditors that would to have the option to create Newsitems for School A and B only (usecase 1.2).
Or we have a multidepartment solution like this:
The simple situation we were having here were contenteditors that work for two departments and should edit news and contentpages.
In Umbraco 7.6 and before they should have a common starting node and you should settings to their childnodes. But everytime there was a new school added or department you would have to set these permissions again.
In Umbraco 7.7 we could pick multiple startnodes like “News” in School A and B. I’ve setup a testsite that looks like this:
And created a content editor like this:
But when the content editor logs on it looks like this:
And that is quite confusing because which “News” is related to which site? And keep in mind that this is a simple use case.
It could also be the case that this person could edit one page under the “About us”-page. In that case the tree looks like this:
In that case it’s no longer obvious that History and one of the News-items (Which one?) is part of the same site / parent node. (Problem 1: No relation between nodes when having multiple start nodes)
If you give the news nodes a prefix of (1) and (2) so the structure looks like this:
The news editor will see it in a different order, where you even less see that the page History and Nieuws (1) share the same parent node:
(Suggestion 1) My suggestion of solving this would be showing always the common parent nodes, if any. And you could not open these nodes themselves but the still give some relation to where they are in the sitemap/contenttree.
We did the same when we introduced folders in our Umbraco Forms On Steroids-package (https://our.umbraco.org/projects/backoffice-extensions/umbraco-forms-on-perplex-steroids/). We’ve made a video about it: https://www.youtube.com/watch?v=vaQsr2uY3bA&feature=youtu.be. And ther you see if you give someone access to a nested node you will see the contextual parent nodes, but you cannot open them (they’re greyed out).
I think that could be a good option for this use case too.
Ok, next… Usecase 1.2….
But if we want this content editor only to create and update news and not edit the newsoverviewpage (which has settings and really important content that they may not edit). We still would use this structure, but we would have to set individual permissions for this group.
In the new situation I would click on “Nieuws (1)” and would edit the permissions so that the editor would only have “Create” permissions on the “Newsoverview”-page; like this:
But if I set it like this the permission settings on the ‘Newsoverview’ flow down to their child nodes and thus you have no publish rights. Although it first looks like that. (Problem 2: And raised an issue here http://issues.umbraco.org/issue/U4-10265)
Another problem is that even if this would work, all these permissions needs to be set for every newsoverview-page (so also in site B, site C, etcetera).
Suggestion 2: A suggestion I’ve raised two years ago in my Skrift-blogpost about Usermanagement (http://skrift.io/articles/archive/i-have-a-dream-about-user-management-in-umbraco/) is to have basis CRUD-options per doctype per usergroup. See the security-tab on http://umbraco.usermanagement.perplex.eu/doctypeeditor.html.
I know this is a totally different approach than what currently is in place in Umbraco, but I think that would solve the real underlying issue that we need in real life. We want to give groups rights to create certain document types, update them (essentially publish them or save them, depending on their permissions… Or separate ‘Save’ and ‘Publish’-rights??), delete them (nobody, except Administrator should ever delete the Homepage for example. But if you have “Delete” permission by default (because you’re allowed to delete newsitems, you’ll also would have delete rights on the Homepage)) and Read-rights (you see the node, but cannot do anything about it).
If you compare these to the current permission set on usergroups:
I would say that you would have to remove the following permissions and put them on document types:
(Headache 1) This is giving me headaches for a few nights now… Because this is a whole different approach than currently, but I think this is what we need to achieve that what we need in real life.
In my use case where I have a newseditor that could see the newsoverviewpage as startnode and could create newsitems;
He/she would have “Read”-rights to the Newsoverview-doctype, and “Read/Create/Update/Delete”-rights to the Newsitem-doctype.
Ok, next use case 1.3: Linking to the homepage or a certain page…
We will reset the startnodes of the newseditor to only see the news of school 1 and 2 (and no longer that one content page under “About us” because that was kind of a silly example)
Let’s say my news editor creates a fantastic newsitem that the company exists 50 years and want to link in that item to the ‘History’-page under ‘About us’.
If you would use the Contentpicker-datatype, or an Rich Text Editor and click the Link-option you would only see this:
I get why they see that, but why can’t I pick other content and link to my history page. I can input directly the Url in the Rich Text Editor, but what if somebody changes the nodename from ‘History’ to ‘Our fantastic history’. The link would no longer work, and that is essentially why we’re using a CMS, aren’t we. (Ok, I know we have a 301 redirect now in Umbraco, but let’s say we’ve disabled that one, because we don’t want 301’s be used in our own site. That should only be used when other websites are linking to us…).
Suggestion 3: If we would always show the whole content tree to pick from (even if it’s outside our startnodes) we could pick this history-page and all would be solved.
But wait (headache 2)… By doing this I would see the content structure of all websites in this solution, so also from school 4, 5 and 6 where I don’t have access to. And that is not what I want.
But would I then need a “Starting node” for in the content tree, and a “Starting browsing node” for pickers…. Aargh, drives me crazy…
Ok, next use case for this section 1.4: Where is my recycle bin?
As a news editor I don’t see a recycle bin. Is that a bug or by design? If my newseditor deletes a newsitem, it should be able to restore these newsitems. Don’t they? Apparently this was an issue in older versions too: http://issues.umbraco.org/issue/U4-239
Use case 1.5 Edit my own userdetailpage as administrator
No user can edit their own userdetailpage. But as an administrator I cannot specify my start nodes either. Is that weird?
Thought 2: Show more on the user detailpage
This one gives me a lot less headaches than the previous one. So that’s nice :)
When writing my blog two years ago I’ve made this page for the users (http://umbraco.usermanagement.perplex.eu/user.html). You guys really did an awesome job on the design of the user page, but in my opinion you should add some properties. Those are already currently available in the database or should be added. (Suggestion 4)
Most important are:
Thought 3: More granular permissions for other sections Ever since Umbraco 4 (and maybe even before that) we have some nice permission sets for the content section (although not for the recycle bin which is a node in the content section), but not for all the other sections. A related discussion to this thought was here (https://our.umbraco.org/forum/umbraco-forms/86655-umbraco-form-encryption) where we will be having issues with GDPR if we don’t have more granular permissions to the Member and Forms-section I guess.
(Suggestion 5) In my opinion (http://umbraco.usermanagement.perplex.eu/usertype.html) we would need more granular permission than only access to a whole section and all rights. But how complex do we want to make it (headache 3):
An option would be to not make it possible to add yourself to any new groups and only give access to other users. But in that case you could fix this together with a second account and grant yourself more access rights. That doesn’t feel good. So I think you would need more granular permissions like these:
Reported it in issue: http://issues.umbraco.org/issue/U4-10267.
With GDPR coming I think there should be a difference between users that can create, edit and delete forms and users that can look to the contents of the filled-in records. Or should they see the form records (a new form entry this morning at 10:00), but they cannot see the field contents of specific fields, where you have check a checkbox ‘Content can only be seen by persons with the permission “See all content”’. So by doing this we would need the granular permissions for this section:
Read form field submissions
Member section
The same concept applies to the member sections and GDPR. Am administrator/developer should have access to member types and edit these, but they should by default not see which members are registered and also not their personal data that are stored in the member properties. So would we need permissions like this:
Or is this making it all too complex for everyone? But on the other we need this probably before May 28, 2018, can we extend this in Umbraco 7.8 or something like that? Or would that require another rewrite of all the work that is done for 7.7… (Still headache 3)
Thought 4: Visual inconsistency
I think the new user section looks great, but still it’s really inconsistent with the rest of Umbraco. I’m wondering if these are the new design guidelines and should be applied eventually to the rest of Umbraco or not. Some stuff that confuses me:
Option 1: Remove the tree all together Option 2: Add groups also, and maybe the groups and users as children of the node. And if not; give the Users the ListView-symbol in the tree.
To me this looks like as a bit too much colors and styles together. Should be “Disable” just be a checkbox?
Should there be an option “Update password” after clicking “Change password”. Now you only have a cancel option and you’ll have to click there if you want to cancel, and somewhere else to actually change the password. That confuses me. And it would make logging the event “User changed password” much easier to implement.
The checkbox for permission look “Apple-like” but essentially they are checkboxes.
Why is that? Should all checkboxes in the backoffice be updated to this option? Like when you copy content and you have the option “Relate to original” and “Include descendants”:
By the way. For accessibility it would be great if there would be a hover-class so you can see where you’re interacting with.
Users have columns and a checkbutton as the first option in a row.
Groups have a different display (not table wise with columns, but more block-ish)
Content section:
User/Group-section:
Sections in groups:
But not when editing/adding startnodes:
Just thought I'd add an alternative solution to this problem:
Start Node Suffixes
When choosing start nodes, perhaps the person choosing the start nodes can specify a custom suffix for each of them. That way, they could display like this:
Why a suffix rather than a custom label to replace the entire content node name? Because a suffix still allows for the content node itself to be renamed and to show the new name in the content tree.
I also like the idea of having the ancestors visible (but inactive) as you've described, though I wonder if maybe some people wouldn't want that information to be visible. For one, it would show content editors what they're missing (making them more inclined to ask for greater permissions). Secondly, it may reveal information that could be sensitive (e.g., if you group a bunch of sites under a "Shared Clients" parent node, the user would then be made aware that they are just one among many clients). Those are fringe considerations, but still thought I'd mention that it could hypothetically be an issue for some people.
Excellent post. I also had these same impressions when testing version 7.7. My case is that of properties in users. I have a client who has several blog editors and he wanted to create custom properties (exactly the same as creating members). I had to customize backoffice editUser.aspx and create custom table. It would be interesting to have a way to add properties to the user.
Just thought I'd add an alternative solution to this problem 2:
An alternative is to display the parent nodes similar to the node selection when configuring the start node in content picker. But it would be interesting only if there is more than one root node
That's a good point. Now that I think about it, the URL list on the properties tab sort of gives you that already (i.e., a path to the node), depending on the URL provider and whether or not domains are configured. Would still be nice to see it in the tree before doing trial and error by clicking through the nodes.
Hi all,
thanks for all feedback! Just a quick update: I've chatted to Niels and Mads from HQ yesterday for about an hour and went through all the feedback.
It was a really positive session and they will figure out how to get some/most of the points in 7.7, or if that's not possible create a roadmap to put in 7.7.x or 7.8.
They're listening and really appreciating the feedback, so keep it coming! Maybe you won't get a immediate response, but they are watching :)
Hi All,
Currently, I'm building a collection of websites similar to this one:
Now I want to create an admin for each site and give him the permission to manage his site users (create an editor, delete editor...). But I noticed that, if I give him the User Section permission he can see also the other sites users.
In short words: "I would like to have: every site has a group of user & there is on Admin who can manage them"
Is there any solution to solve this problem?
-Thanks
Hierarchical user management would be fantastic.
Not entirely sure how to go about it though; I wonder what you'd use to indicate which users can manage which other users.
Anybody have ideas?
I like the idea about the suffix after the node name for the starting nodes, why not include either the root or the parent node name with some ellipses that you could hover over to see the whole path while using the pickers?
is working on a reply...