Delete Permission not Inherited when copying layout

Get Help
1

Server Setup: Xibo CMS 1.8.9 running inside Docker
Relevant Settings/Permissions: Layout Permissions, Public Write; Media Permissions, Public Write; How to Colour Media: Media Colouring; Schedule with view permissions: Yes; Inherit Permissions: Checked.

I have one admin user (me) - and am setting up another user account for another user. This other user should have permissions to modify existing layouts, copy layouts, delete layouts, edit the copies, add regions, delete regions, edit text areas, etc, and schedule all layouts. But - not be able to change other system type setting.

Situation: An existing layout (say “SaturdaySchedule”) has permissions listing Everyone as “View, Edit, and Delete” - and those permissions were set with the “cascade permissions to all items underneath this one” box checked. The second user account can edit, delete, modify regions within SaturdaySchedule. However - say there is a special event and the second user needs to create a special version of the SaturdaySchedule just for that event (to be set as priority layout when scheduled. Second user account goes to list of layouts, locates the SaturdaySchedule, and then in the pull-down box, chooses copy. They give it a name “SaturdayEvent” - and click Copy.

When they then click “Design” for SaturdayEvent - they can edit text in one region, but when they go to delete a region that shouldn’t have any content for this special event, they get an Access Denied message.

If I check the permissions for the SaturdayEvent layout, everyone is listed as “View and Edit” - but no delete permission. If I check delete for Everyone, and click the “Cascade Permissions” box, and click save, then the second user is able to then delete the region they would need to delete.

It behaves the same if I copy the layout as myself (admin) - the copied layout SaturdayEvent does not have the “delete” permission for everyone, even though the SaturdaySchedule layout did.

Is there some other setting I should be enabling to allow the Delete permission to be inherited by the copy the second user is making?

Thanks,
-Eric

2

That is correct and by design.

Copied layout is a new entity, as such the permissions are not copied.

Since you have Public Write permissions on layout, then every new entity will have view and edit permissions assigned to Everyone - but not delete.

We also do not change the owner if different user is copying a layout, as such that new user will not be able to delete copied layout - unless super admin gives him explicit permission to Delete as well.

I suppose there are few ways in which we could “fix” this, either directly copy the permissions from source layout on copy or add delete permissions to the Permissions in CMS Settings (similar like view/edit are now) or change owner of the copied layout if other user is doing that - each approach would solve your problem, but could potentially create set of different issues.

I’m not convinced what we will want to do there, perhaps @dan will comment further once he has a moment.

3

I believe the owner on the copy should be set to the person copying - but permissions not copied. @Peter - if it doesn’t work like that can you submit a bug please, thanks.

4

Created, with possible solution in the commit - https://github.com/xibosignage/xibo/issues/1511

5

Thanks for taking a look at this - changing the owner to the person doing the copy will be a big help. If I’m thinking this through correctly - to see how this will affect our use case:

Since they will now be the owner of the copy, they will then be able to go to the permissions of the new copy and give themselves delete permission, and check the Cascade Permissions box to then get the permission effective on all regions within the new copy. For the way we have out signage setup, being able to add or remove regions for specific special event days are a key detail.

And, if it was needed for other use cases, they could then give other users/groups the appropriate permissions besides the defaults.

Am I understanding this change correctly? If so - is this something use see being rolled out to a release reasonably soon?

Thanks again, -Eric

6

With the change in my commit, the user copying the layout will become an owner of the copied layout, as such that user will have full access to layout/regions on it.

If there are any library media files on the layout then it is also possible to make a copy of those while copying the layout ( the Make new copies of all media on this layout? checkbox), then user would be an owner of the copied media files as well - with that I think we have one more issue here as well I will look into that later today.

All those changes will be in the 1.8.10 release, we do not have release date for it yet.