Prevent deletion of published videos, infographics, and files by non-admins

[bryanpizzillo]

Basically, the same workflow rule as content. An image_manager should be able to delete any images that are draft and never have been published. However, once they have been published they may be in use, and therefore no one should be allowed to willy-nilly delete them.

Lindsay Asking Bryan: if an image is published, but no longer being used on the site, can it be deleted? I don't think it's a "willy-nilly" deletion if the image has no relationship with other content in the CMS.

There may be limitations with Drupal core WRT media items and being able to hook into the permission checks like we do with content.

RULES: Story 1: Remove image deletion for image managers from both Image (cgov_image) and Contextual Image (cgov_contextual_image) when an image is published.

• Scenario 1: User has image manager permissions (creates an image, changes their mind before publishing. The user should be able to delete the image from the unpublished state.
• Scenario 2: An image manager creates an image and publishes it. They should not have the option to delete the image.

Task 2: Add “request delete” option for published images

• Scenario 1: An image manager publishes an image. The image manager can request to delete the image.
• Scenario 2: Site admins have the ability to delete images
  • Story 1 (Surya): Site admins will need to remove all links to image before deletion. (we would need to request reports from Min)
  • Spike (Adrian): If there are any references to the image within the system, make it so that site admins are not allowed to delete the image (system throws an error stopping users from deleting the image). - determine tasks and LOE for this one. Is there a way to find all the media fields that allow for an image? Body fields, entity references to media items in paragraphs, etc. How do we ask the system "which fields can have images" and how do we do this, as we add new fields in the future, no one has to know this is happening because its covered. What is the list of fields right now? Covers all media items. Spike for media references, and spike for node references

Task 3: For videos, infographics, and files, authors can request archive, editors can approve archive request, and only site admins can delete.

• Scenario 1: An author or editor creates a video, infographic or file but does not publish it. Author/Editor can delete the file.
• Scenario 2: An author or editor publishes a video, infographic or file. The author can then only request archiving of the content.
• Scenario 3: Editors can archive the content directly once its been published
  • Editors should request link report to check for broken links, and request redirects if needed/speak to SEO.
• Scenario 4: Editors can review request to archive, and approve or deny (if denied, back to published state).
• Scenario 5: Site Admins have the option to delete content that has been archived
  • Site admin manually ensures content linked is not used anywhere before deletion (through reports from Min).

This follows the same editorial workflow as nodes.

[amydugan]

This is not a blocker for May 2019, but it is riskier if we don't do it. Marking in scope for May 2019 for now.

[adriancofie]

This ticket covers not only images, but other cgov media as well.

Task 1: Remove image deletion for image managers.

Scenario 1: An image manager creates an image, changes their mind before publishing. The user should be able to delete the image from the unpublished state.

Scenario 2: An image manager creates an image and publishes it. They should not be able to delete the image.

Scenario 3. An image manager, executes scenario 2. The image manager archives the image. Once archived the image can be deleted by a site admin.

Task 2: Ensure all other media follows the content workflow. For videos, infographics, and files, authors can request archive, editors can approve archive request, and only site admins can delete.

[VictoriaSunNIH]

This ticket is only for the other media items, we have moved images out into its own thing #3104