Open eporter23 opened 2 weeks ago
PR made: #616
A rake task was also added. Once this is deployed we will run the rake task and then test the transfer functionality.
The rake task now reindexes pre-existing objects including FileSets - this work is still in progress.
I created a new work and captured its alternate ID. This is working well with the new Dashboard search, but doesn't seem to be entirely functional in the main Public Search.
Example: 733rv15dz5-emory
https://oe24-test.libraries.emory.edu/purl/733rv15dz5-emory
Search for 733rv15dz5-emory
: https://oe24-test.libraries.emory.edu/catalog?locale=en&search_field=all_fields&q=733rv15dz5-emory
It's in the search return, but since the id contains emory as a substring, we might need to weight that particular field so that it comes first.
I'll do that with my next PR, since I've run into some unexpected kinks in my remediation process. I'm going to iron those out and run the remediation manually (step by step).
More reliable remediation rake task running now.
This ticket follows previous work to implement Valkyrie alternate_id scheme using our own NOID scheme. We also learned when doing so, that the Valkyrie alternate_id creates an extra Fedora resource for each ID minted.
For this ticket, we want to build on lessons learned in earlier tickets, and implement the findings from #541.
Note: at this time, we do not need to present persistent URLs in the UI for FileSets, but we do want to continue minting and storing the local NOID ID for them.
TBD: do we need to spend any time remediating existing Collections and Works that use the older alternate_id implementation? Could we also write a rake task to do a cleanup on the older IDs to move them to the new attribute?