U4-10265 - 7.7 Beta - User cannot create content if they have Browse + Create permissions (why would they also need Update?)

Created by Jeffrey Schoemaker 08 Aug 2017, 07:29:01 Updated by Mads Rasmussen 18 Aug 2017, 12:06:06

Tags: Unscheduled

Subtask of: U4-8632

Original title: 7.7 Beta - Tree keeps refreshing + saving fails

I've set permissions to a group "Newseditors" => The have a startnode of "News overview" and on that node they only have Browse and Create rights (so they can Browse the newsoverview node, but not edit it. And create new newsitems under the overviewpage).

But when you do it like that the issue that you see in the screencast happens. The tree keeps refreshing by clicking on a node, and you're not able to save the node because you get an error.

Also if you create a new newsitem you won't have the publish button.

That's probably because permission that you set on a parent node flow to their child nodes.

I would have expected that I could create new newsitems and publish them.

6 Attachments

Download Weird save errors.mp4


Shannon Deminick 18 Aug 2017, 05:02:52

I believe in previous versions we had a slight hack where if you do not have save permissions on children you would still be able to save the ones you've created if you had create permission on the parent. I'll need to check but i think that is the scenario.

Shannon Deminick 18 Aug 2017, 05:57:31

Since beta, some things have changed so i cannot replicate the issue you have exactly, but there are some other quirks i'll need to fix.

Shannon Deminick 18 Aug 2017, 06:46:21

Ah, i know why you were getting the tree refresh thing. Before we didn't have true inherited permissions, just like prior to 7.7 permissions were all copied which didn't work so well and was actually very slow for things like moving or copying. So when you change permissions higher up prior to 7.7 it doesn't cascade down automatically, it only does that for creating new content. Prior to 7.7 you'd need to use the permissions manager in the user section to reset all sorts of stuff.

In 7.7 it's real inheritance so that issue doesn't exist any more (tested today).

However, there was an issue - in order to create you'd actually need Browse/Create/Update permissions which doesn't make sense because then the user would be able to Save everything below the parent which you might not want. So I've fixed that. Another thing that needed fixing is that if you 'browse' a node without save or publish permissions you'll get the preview button BUT preview automatically saves the item! So needed to fix that scenario so the browse user can just preview what is there.

But... we've got another interesting thing. For quite a long time one of the permissions quirks for content editors is that if you create a content item, you will always have access to Delete it even if you don't have Delete permissions. Here's why that is:

  • In order to delete child content you'd need to set Delete on the parent
  • If you set delete on the parent, you can delete the parent... but the admin doesn't want you to do that

To resolve that scenario a long time ago, it was decided that a happy medium would be to allow any content item created by a user to be deleted by that user and that made a few folks happy. We'll need to keep this quirk for a while so ... Similarly, would it also make sense to say that a user should be able to Update their content if they've created it?

@jeffrey.schoemaker@perplex.nl I know you've proposed many of other solutions for permissions and we'll look into those post 7.7.0 release (since we obviously need to get it out!) but another solution I proposed a long time ago on the task that Andy Butland created the permissions PR for was to implement 'Deny' permissions. In this case, Deny permissions would always take precedent and they would not cascade. So you could have 'Allow Delete' permissions on the parent and also 'Deny Delete' permissions on the parent meaning that you by default can delete all children but not the parent. Anyways, just thought I'd mention that (no time to implement that for 7.7 either of course ;)

PR here: https://github.com/umbraco/Umbraco-CMS/pull/2137

To test:

  • Create this tree structure: Root -> Parent -> Child (make 2 of these children)
  • Create a user group with access to Content with a start node of "Parent", set granular permissions for this group on "Parent" of only Browse + Create
  • Create a user that is in this group
  • Login with that user
  • Navigate to both of the children, ensure you can see the node and can only preview - test the preview, ensure there are no js errors or error responses
  • Create an item under Parent - ensure that the Save button appears and that you can actually create the item

Mads Rasmussen 18 Aug 2017, 12:05:58

It works perfectly 🙌

Priority: Normal

Type: Bug

State: Fixed


Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.7.0

Due in version: 7.7.0

Sprint: Sprint 65

Story Points: