Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • [email protected] 406 posts 2135 karma points MVP 7x c-trib
    Aug 08, 2017 @ 09:45
    jeffrey@umarketingsuite.com
    19

    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)

    • 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:

    enter image description here

    And created a content editor like this:

    enter image description here

    But when the content editor logs on it looks like this:

    enter image description here

    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:

    enter image description here

    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:

    enter image description here

    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:

    enter image description here

    (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:

    enter image description here

    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:

    enter image description here

    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:

    enter image description here

    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:

    • Account locked (see this issue; http://issues.umbraco.org/issue/U4-10243. I’m wondering now if it needs to be buttons, or just checkboxes)
    • 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?)
    • Edit users
    • Delete users
    • Update users
    • Create groups
    • Edit groups
    • Delete groups
    • Update groups

    Reported it in issue: http://issues.umbraco.org/issue/U4-10267.

    • Forms section

    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:

    enter image description here

    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:

    enter image description here

    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.

    enter image description here

    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”:

    enter image description here

    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.

    enter image description here

    Groups have a different display (not table wise with columns, but more block-ish)

    enter image description here

    • Introducing new colors to the backoffice:

    enter image description here

    • Not using the same (new) contentpicker as in the content section:

    Content section:

    enter image description here

    User/Group-section:

    enter image description here

    • Sometimes highlighting what is already selected and sometimes not:

    Sections in groups:

    enter image description here

    But not when editing/adding startnodes:

    enter image description here

  • Nicholas Westby 2054 posts 7100 karma points c-trib
    Aug 08, 2017 @ 15:45
    Nicholas Westby
    0

    Just thought I'd add an alternative solution to this problem:

    Multiple Similar Start Nodes

    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.

  • Marcio Goularte 374 posts 1346 karma points
    Aug 08, 2017 @ 19:24
    Marcio Goularte
    0

    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:

    enter image description here

    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

  • Nicholas Westby 2054 posts 7100 karma points c-trib
    Aug 08, 2017 @ 20:02
    Nicholas Westby
    0

    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.

  • [email protected] 406 posts 2135 karma points MVP 7x c-trib
    Aug 09, 2017 @ 09:10
    jeffrey@umarketingsuite.com
    2

    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 :)

  • Zihadul Azam 26 posts 171 karma points c-trib
    Sep 21, 2017 @ 14:31
    Zihadul Azam
    1

    Hi All,

    Currently, I'm building a collection of websites similar to this one:

    enter image description here

    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

  • Nicholas Westby 2054 posts 7100 karma points c-trib
    Sep 21, 2017 @ 15:10
    Nicholas Westby
    1

    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?

  • John Bergman 483 posts 1132 karma points
    Sep 22, 2017 @ 00:17
    John Bergman
    0

    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?

Please Sign in or register to post replies

Write your reply to:

Draft