When adding media as Admin, and assign to Window in layout, user with Permission for this layout will unable to delete/edit the media from the playlist.
as Admin, change the to specific media permissions for this user, including ownership for this media, will not grant edit/delete in playlist.
for now, i simply add the media logged in as the user, however i think removing the media and allow the user to reassign to the window from library will work…
shouldn’t permission of media should be inherited automatically to playlists ?
You are confusing different permission sets.
Media has permissions, as does playlists. Just because a user has permission to a media item, doesn’t mean that they automatically have permission to all playlists that media item is used in.
So say you had a company logo, which all your users had permission to see. It wouldn’t make sense for everyone who could see that logo to automatically have permission to edit any layout that used that logo on it.
I understand, but this is not the case.
i have user with full permission to layout, and windows…
as a different (Admin) user i added new content to the same Window the user has permission to.
user in this case, lacks permissions to delete/edit - that fine… the media assigned to the window is not for him to deal with…
in this point, Admin user modifies the permission to the media and changed full permission for this user, including ownership…
in this point, user, which has already full permission to the layout/window/playlist - still doesn’t have permission to the media the admin assigned previously and modified the ownership/permission to the user.
It sounds like you don’t have permission cascade turned on, but probably want that turned on.
It means that permissions for new items added to a region or layout cascade down. It’s in the CMS settings.
the “inherit Permissions” is checked… i think this is the default settings.
Which CMS version are you using please? How is it installed?
Using 1.8.3, installed on Ubuntu 16.10 and docker 17.05-ce
Can you please upgrade to 1.8.7 as a first step, and then see if the issue still happens there.
You’ll need to recreate it from scratch (the issue, not the CMS!) as any existing permissions assignments won’t be updated as part of the upgrade process.
OK, any limitations working with Xibo 1.8.3 Android clients?
also, i noticied that if the user copy layout (he is the owner, and also has full permissions ) the new layout created with his ownership, but he has no permission to edit anything in design…
same permission problem ?
There is no such thing as a Xibo for Android 1.8.3 client.
You’ll be running 1.8 R10 something. They all should be compatible with 1.8.7 CMS.
There have been many many fixes in the interim. If you’re running with Docker, it’s trivial to take a copy of your live system, and then upgrade that, and see if the issues are already resolved directly.
I’d suggest you do that.
Stop the containers, copy your install directory, start the original containers back up.
Then in the copy directory, amend the ports for XMR and CMS, and then you can bring the new containers up. You’ll then have a copy of your production CMS running on a different port. Upgrade that (by changing the
image: line for XMR and web containers, and then you can test on the copy.
Starting preparation for the upgrade, i noticed that in the cms_custom_ports
the default xmr image version was modified from the standard versioning to
before proceeding, i would lie to know if this something in need to change, or an intended changed you made…
Yes XMR versions move from 1.8.x to 0.7 - that is intended.
You need to copy the image lines from the 1.8.7 docker-compose file exactly.