Images not editable when permission to remove files is not enabled

[dowadidi]

Description

When the deleteFilesAndFoldersInVolume permission is not set, the user cannot edit the image. And dragging files into other folders result in an error.

Steps to reproduce

1. Doubleclick an image and hover over the thumbnail (No 'edit' button appears)
2. Drag an asset to or from a subfolder (A permission error appears)

Additional info

• Craft version: 3.0.26.1
• PHP version: 7.2.7
• Database driver & version: MySQL 5.7.22

[riusi88]

I'm curious to know if this issue is going to be resolved in any upcoming Craft 3 updates?

I've ported a Craft 2 site to Craft 3 that was utilizing a combination of Imagur, Focal Point, and Crafts Asset Transform, and AWS cloud storage, to allow our clients User Groups to fine tune images within a templated out entry type. It was an important feature to lock out specific User Groups from deleting assets since the site functioned as an asset Library connected to the AWS cloud. If an asset was deleted, it would have ramifications across multiple entries, and other collateral on the web that uses the asset Library.

After porting the site to Craft 3 we were excited to use the native image editing feature built into the CMS. Unfortunately, the clients User Group can no longer edit images without giving them access to deleting the images. This is problematic for our client since they can't 100% enforce people in there User Group from not deleting images. Mistakes happen, and mismanagement among many things can lead to images being lost forever.

A programatic solution would be ideal in this situation. Would you be able to expose permissions to edit images, without granting a group access to deleting the images?

[andris-sevcenko]

Sorry for the super-late response, @DiederikVanHoorebeke. The deleteFilesAndFoldersInVolume permission is required for dragging files to a different folder because you are copying it to the new folder and then deleting it from the old folder, so you need the delete permission for that.

As far as image editing goes, the logic behind that was that when saving the image with any changes, it would overwrite the existing image, so could also classify as a destructive operation. However, in hindsight, that seems a bit silly.

Another permission seems to be a good way to go here.

[riusi88]

Thanks for the response @andris-sevcenko! It makes sense that due to the destructive nature of the editing / copy process that it would prevent users without deletion permissions from making asset changes.
It sounds like you'll be working on an update to this, which is much appreciated. Would this update also remove the destructive operations involved with image editing as well? I imagine this would involve setting up an entirely new folder structure though, where original images are maintained separately from cropped versions.

[andris-sevcenko]

Closed via 1d048e7

This will be released as part of 3.2.

Would this update also remove the destructive operations involved with image editing as well?

There will be no other changes - the new permission will be required for saving as new or replacing the image.

[furioursus]

Hi all, we're on 3.3 and still seeing this exact bug. I have authors with the permission for "Edit Images" set, but the EDIT button doesn't appear over images unless I also enable "Remove files and folders."

[brandonkelly]

@onebrightlight We’ll look into that and get back to you.

[andris-sevcenko]

My apologies, @onebrightlight, should be all better with the next release!