Create custom report to check for broken links

[erussey]

Develop a custom report to capture URLs in notes and digital object file versions and check them for bad requests (404, 500, etc.). This report will need to run periodically (yearly) so archivists can fix any issues.

UGA has a plug-in that does the above, but may need to be tweaked for local use cases. Ideally, archivists would be able to run/receive the report without having to have access to the plug-in directory. Otherwise this can be run similarly to the API reports for restrictions.

https://github.com/uga-libraries/uga-archivesspace-reports

[erussey]

Posted to basecamp to see if there's something Lyrasis could help with on their end.

[erussey]

Per Blake at Lyrasis, there are a few sites with that plug-in installed and he seemed to think that there's a link in the background jobs manager in the UI. @rotated8 should we try to install it in our plug-in directory and see if it works?

[abelemlih]

@rotated8 @erussey I tried installing the https://github.com/uga-libraries/uga-archivesspace-reports plugin, and I was unable to get the report to show up under the reports section. This may be due to the way custom reports are retrieved from the the plugins directory. I reached out to Lyrasis on Basecamp to ask if there is any additional setup needed to get a custom report plugin working.

As for the report itself, I copied the code to a custom report I created in my local instance, and tested it, and so far it seems to work exactly as expected, without the need for any additional adjustments. Once I hear back from Basecamp, I will push changes to the deployment repository to add the report to our list of plugins. Let me know if you have any questions.

[erussey]

@abelemlih : Saw the response from Lyrasis about the plug-in. What would you recommend that we do? For now, it's ok to have the report run once over production data to get a list of all the broken links so we can address them. Note that production data is not yet available but will be loaded next week. Perhaps getting the report to be able to re-run should be an enhancement?

[abelemlih]

@rotated8 @erussey I added the plugin to the list of plugins in our deployment repository, and Collin and I decided to give it a try on the Test environment and see if it loads properly. Blake from Lyrasis mentioned that other institutions are using the plugin, so the issues loading the report could be limited to my local environment (or local development in general).

If the report is not showing up on the Test environment after we deploy, we will need to figure out an alternative approach to getting this report working. One possible alternative is asking Lyrasis to add the report manually to the list of reports available in our ArchivesSpace instance. This approach will require further conversation with the Lyrasis team.

[abelemlih]

@erussey the plugin is working on the Test instance and the report is ready for testing:

[erussey]

@abelemlih : I think I managed to break it. I ran it once, realized it was going to take a while, and canceled it. Then tried to run it again and it is just listed as queued. I've posted a message in Basecamp about it: https://3.basecamp.com/3410311/buckets/29543127/messages/6095613663

[erussey]

@abelemlih : This ran successfully and the report is exactly what I need. Blake did have to restart the server, which sounds like something we'll just have to be aware of. I'm going to mark this story as done.