Re-uploading a Soft Deleted Image

[RichardLe]

Thread arising from Guardian/BBC meeting on 28/06/21 around Soft Deletion and the use cases that arise.

Akash highlighted that soft delete gives rise to some additional edge-cases because the image that's re-uploaded will have the same id as the original image and therefore inherit the original soft-deleted status from the database. We need to devise a solution that enables:

• A user to re-upload an image and be alerted the image already exists in the system and to be able to restore the image to a normal state
• An image that has been removed from the system for compliance reasons (e.g. a kill notice) to continue to be deleted despite the attempt to re-upload

Users can currently be alerted to the fact that an image already exists in the catalogue as they upload, there's possibly a solution based on this process that enables them to restore the image.

[paperboyo]

Question: what is the interplay between canArchive and canSoftDelete (in the future just a replacement for canDelete) permissions? At the Guardian anyone can Add to Library any image and no special permission is necessary. Asking because archiving basically becomes unSoftDelete.

Without any changes to the permissioning system:

For the Guardian

1. When the user is the original uploader and also they have deleted it, Upload page should provide a message explaining they need to use Add to Library button on that page to reinstate the image
2. When the user is the original uploader, but image wasn’t deleted by them, they will still be able to do the above, but maybe the message should discourage that (kill notice example)

For the BBC, the 1 & 2 will be different depending on user’s canArchive status, I believe? If they don’t have canArchive, they won’t be able to undelete in use case 1, let alone in use case 2.

[abdelrahmansd]

Question: what is the interplay between canArchive and canSoftDelete (in the future just a replacement for canDelete) permissions?

the interplay between canArchive and can canSoftDelete is canArchive becomes unSoftDelete for soft-deleted images
also canSoftDelete will be a replacement for DeleteImages permission
so I'm thinking about reusing DeleteImages Permission on the soft-delete endpoint

[honorcb]

For agency pictures, are the original uploaders usually an automatic process, ( there are some agency pictures that are manually select from a picture library and uploaded in BBC ) ,

[paperboyo]

Hi, some loose thoughts about mostly UI-related issues, that I think we need to consider. I think we can safely postpone working on them until after main work is done?

Since Add to Library (userMetadata.archived:true) is going to be the way to undelete images:

1. it probably shouldn’t (?) remove the softDeleted metadata, otherwise external systems applying it would constantly override users’ actions (lambda soft-deleted, I added to Lib, lambda soft-deleted again, I’m bored)
   1. should archived images that were undeleted appear in is:deleted searches? (as they will still carry soft-deleted metadata) Probably yes?
   2. archived images that were undeleted should definitely appear in all normal searches, as they are effectively “brought back to life”
2. Delete button (shown for permissioned users) should either disappear for soft-deleted images, or (better?) turn into greyed out one saying Deleted (because Remove from Library will be doing that job as pt. 1)
3. Currently it’s not possible to delete images that have crops or have been used (have usages). We may want to (?) allow deletion of them in the future (since they will be soft-deleted, so current usages will continue to work until replaced)? If we do, we need a way of signalling that in the UI for unpermissioned users arriving directly at deleted image page (This image has been deleted, contact the authorities. or somepin)
4. do we need any changes to the UI (and model?) for how persisting rules (persisted.value/reasons) are interacting and are shown in UI for deleted images?
   
   1. currently, persisted images can be deleted and should continue to be, but current UI will make it impossible to undelete them as Add to Library button turns into Kept in Library one:
      

I suspect at least pt. 4 may get a little hairy, so we need to be careful and have both the minimum plan as well as a long-term one?

[abdelrahmansd]

1.it probably shouldn’t (?) remove the softDeleted metadata

soft-deleted metadata should be removed (if exist) on Add to library action , because soft-delete lambda will get all images that have soft-deleted metadata and hard delete them

should archived images that were undeleted appear in is:deleted

will not, because it will be removed on add to library action

2. Delete button (shown for permissioned users) should either disappear for soft-deleted images

yes, turn into greyed out one saying Deleted is better

3.Currently it’s not possible to delete images that have crops or have been used (have usages)

now we are applying the same validation on soft-delete images action like the existing delete images action
for unpermissioned users should not see the image and see 404 page or message saying the image been deleted

4. but current UI will make it impossible to undelete them as Add to Library button turns into Kept in Library one

yes, this one is a little bit tricky and needs more discussion

[paperboyo]

I’ve created these mockups, more to get my head around it than anything else.

Unpermissioned user:

Permissioned user:

Notice:

1. Additional text next to Your uploads
2. Unusable image to turn into View image, so it’s clear that even unusables can be viewed (fine to be changed globally, I think)
3. Kept in Library button should change to Add to Library for Deleted images
4. Delete button should change to Add to Library (for permissioned) and to greyed out Deleted (for unpermissioned)

All for discussion. cc @tjsilver @abdelrahmansd @adrielulanovsky @twrichards @AWare @andrew-nowak FYI @akash1810 @sihil

[paperboyo]

We will be discussing merging of #3425 tomorrow. As it fundamentally changes how Grid works, we need to make sure it’s safe. If we decide it is, we need to at least

• change our integration tests as they are doing deletion and reupload of the same image

After that, the remaining issues to fix (moved from comments on the above PR):

• 1. PRIORITY Add to Library button in the actions bar for a selection of soft-deleted images doesn’t show (it should say Undelete, just like in Viewer) (FIXED in Add Undelete in Select View Toolbar Components #3535):
  
• 2. For a permissioned user, small Add to Library/Undelete image button next to View image looks broken (FIXED in add undelete button in Image Thumbnail #3536):
  
• 3. (see also pts. 1–2 here) For an unpermissioned user, small Add to Library/Undelete image button next to View image doesn’t do anything, but highlights on hover. Tootlip shown is correct, but maybe let’s get rid of the highlighting on hover? (FIXED in add undelete button in Image Thumbnail #3536)
  
• 4. unpermissioned users can see all deleted images when they hit the search directly. Should they be seeing only their own deleted images? (fixed in 534e030)

Independently, we need to decide these points:
A. Currently, it’s possible to have an image in both deleted and archived states (after you delete an archived image). Should they be exclusionary states? UI is OK: in Viewer, the button says Undelete and after clicking, it says Remove from Library. So maybe it‘s fine?
B. Is Undeleting behind archivist permission (which we don’t use at the Guardian)? Or is it under delete_image permission? Which one should it be behind? Latter, I think? (ANSWER: it’s under delete_image permission)
C. [for the future] Should we have hard-delete via UI (behind separate permission)? or, at least, Empty Trash?
D. [related to 2&3] Should we do anything about the browser badges for deleted images? (at least tooltip seems wrong?:

E. Should a user without delete permissions be able to undelete an image (that they uploaded) that someone else (with permissions) deleted? (currently, they can)

[paperboyo]

We’ve discussed next steps we feel are needed for soft-deletion to go into production in here.
I have removed those steps (they were C & D) from the comment above that now holds only the outstanding fixes that can be worked on later.

[paperboyo]

All the fixes now landed. I think , for completness, the only issue that remains is related to D above: badges and iconography for Undelete. I think we should use this icon.