Hei,
Currently the image/media selector will list all images starting from root for which the logged in user has at least “Can read” permission. There are some cases however where it would preferable that a user is only able to select images from the image/media selector for which he has “Full access” permission.
In the config tag for image/media selectors you can already use “allowPath” to limit the images available for selection. Perhaps something like “allowPermission” could be useful too?
Hi Roeland.
I have problems seeing the use case where an editor’s write permissions would be relevant for which relations can be created?
I.e. another editor might later edit and have different permissions, what should then happen? Also, why should editor permissions be relevant to the published result?
Hei,
The use case here is a project that has multiple sites, each having their own editor with write permission. They have read rights for everything but can only edit their own sites. And they work independently from one another.
When there are a lot of sites, each with a lot of images, it can clutter up the imageselector for editors who only want to use pictures they uploaded themselves.
There is also another reason to prevent editors from using pictures that have been uploaded by others. For instance, one editor could decide to clean up his site and delete a bunch of pictures, which could then potentially cause missing image issues in other sites.
Hi again Roeland.
So, with large content structures and mixed editing access, an editor with “higher” permissions would still be able to edit and insert images created elsewhere. Using ${site}, and maybe some other /media folder as the allowed scope may be a safer way to approach this IMHO.
It is not likely we will implement restrictions on linking based on write permissions, as this will not only cause confusion bug also be very volatile to manage.
If you want complete isolation, it may be a better solution to use projects and possibly layers to inherit shared content for your sites than placing everything in one large structure.
Ok, thank you for the feedback!
We will not implement this, but will look into the archive/delete dialog to see if we can improve the UI further - so users are less likely to break links in the future.