We have moved to GitHub Issues
Created by Jeffrey Schoemaker 08 Aug 2017, 07:29:01 Updated by Mads Rasmussen 18 Aug 2017, 12:06:06Tags: 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.
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.
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.
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:
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?
@firstname.lastname@example.org 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 ;)
It works perfectly 🙌
Backwards Compatible: True
Affected versions: 7.7.0
Due in version: 7.7.0
Sprint: Sprint 65