PDF Deletion and Retention

[EWashb]

User Story or Problem Statement

A Drupal Core bug prevents PDFs from being deleted. This has caused an undesirable user experience for removing PDFs from the FE and also an undesirable user experience for editors looking to replace PDFs with new versions.

Description or Additional Context

• Currently, the only way to remove an unwanted PDF is to remove the link to it in the content. This does not remove it from our system, it only removes it from being actively published. They can still be found in the CMS media library. Not only does this make it hard for editors to understand what is currently published, it burdens our system with a large amount of old and unused files. However, there may be record retention concerns with deleting these altogether, especially if they must be retained as public record and in the event of a FOIA request.
  • Could we explore moving PDFs upon "deletion" to an S3 bucket? That way we are retaining what we need and for how long we need to?
• VHA DM is the owner of most PDFs in the system. Other editors, like Vet Centers, do not have the ability to add PDFs at all
• VHA DM is working to create a PDF strategy and guidance for their editors, but it is hard to do when our current PDF inventory accounts for both published and unpublished items

Acceptance Criteria

• [x] technical discovery on options related to deletion and retention PDFs in the CMS is completed
• [ ] ticket(s) are created for next steps on storage and the Drupal bug preventing delete
• [ ] An estimation of the level of effort to complete this work
• [ ] Path forward is discussed with PM/PO
• [ ] Review options with Accelerated Publishing team to inform them of our work

Team

Please check the team(s) that will do this work.

• [X] CMS Team
• [ ] Public Websites
• [ ] Facilities
• [ ] Accelerated Publishing

### Tasks
- [ ] https://github.com/department-of-veterans-affairs/va.gov-cms/issues/17648
- [ ] https://github.com/department-of-veterans-affairs/va.gov-cms/issues/17604
- [ ] https://github.com/department-of-veterans-affairs/va.gov-cms/issues/17939
- [ ] https://github.com/department-of-veterans-affairs/va.gov-cms/issues/10117
- [ ] https://github.com/department-of-veterans-affairs/va.gov-cms/issues/18195
- [ ] https://github.com/department-of-veterans-affairs/va.gov-cms/issues/18524
- [ ] https://github.com/department-of-veterans-affairs/va.gov-cms/issues/19159

[EWashb]

@BerniXiongA6 I have spoken with VHA DM about this initiative being the smarter way to go before we open up the current PDF audit without purging the unpublished items and they agreed that this would be the more holistic and positive approach to the situation. I would like to see about getting this as a top priority for Q1 2024. I will also put it as blocking both enhancements and additional permissions to the current audit tickets.

[gracekretschmer-metrostar]

Next steps: bring in Edmund's audit, then we need Erika's retention policy, and then come up with a plan of action to address the deletions.

[srancour]

@edmund-dunn and I had a quick catch up this morning on this and came up with some thoughts and questions:

• Eventually adding in a check for when a user uploads a file to see if the filename already exists and then ask the user if this is replacing the old one could be useful.
  • Currently by default, Drupal will append the new file name with _i, where i = number of instances of the file, and do nothing with the old file.
  • This could allow us to delete the old file in favor of the new, thus cutting down on extra files in the system
  • We could also potentially build it so the ties to the pages that the old file have come over to the new one saving the editor time, creating no chance of the pages being shown to vets without the document still attached, and saving us from having files not associated with content.
• @EWashb do we know why some editors are adding pdfs and not associating them with content? In just the last week we have 31 pdfs uploaded that aren't associated with any content page in the site.
  • Are editors using the CMS as a file system?
  • When testing we realized that this can only happen if the files are uploaded through Content > Media > Add media > Document.
  • Should we look at changing it so editors don't have access to be able to add files through this method?

[EWashb]

@srancour we determined that the PDF audit is actually incorrect. Those PDFs being added are in paragraphs, but the report is not pulling them because they are inside of paragraphs and not a specific field. That is unexpected and could be deemed a bug. If you look at the usage details you will get the link to the published page and you can go the FE and see that those PDFs actually are being used. @edmund-dunn can give you more info on that. CC: @gracekretschmer-metrostar

[srancour]

@EWashb thank you for that added information! I do now see that in there those files that are in paragraphs.

[srancour]

This relates to the Discovery: Non-compliant PDF Report ticket that was opened by the last team. Linking it for visibility.