You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Archivists frequently "re-process" a collection. To do this, they export the records from ASpace in bulk, edit them outside of ASpace, and then re-import them. When this happens all the component IDs change. For public items they can see that it has a DAO, so they need to go fix up Figgy for that record (or more likely, provide to us a CSV of old ID -> new ID and we'll process it - if that happens a lot maybe we'll need a feature for that too), but for private items there's no DAO, so the record in Figgy gets orphaned (its component ID is now wrong, and the archivist has no way to know that the item ever had a Figgy object other than by individually checking every one of thousands of private component IDs.)
They've proposed fixing this by having Figgy ALWAYS insert a DAO into ArchivesSpace, but making it "unpublished" if it's a private item.
Acceptance Criteria
When a private finding aid is marked complete it creates an "unpublished" DAO
When a private finding aid item is marked public it updates the DAO to become "published"
When a public finding aid item is marked private it updates the DAO to become "unpublished"
Priority recommendation
asap
within the next 3 months
PO will prioritize
In talking to stakeholders, it'd be great if we could get to it in November, but if it got pushed out until the beginning of the new year that would be okay.
Sudden Priority Justification
Until this is fixed records will continue to become orphaned, the efforts we took to digitize them wasted and making them inaccessible to patrons. There aren't any large reprocessing projects coming up, but they can come up suddenly.
Staging should update records to https://aspace-staging.princeton.edu/staff/ - we can create a record in Figgy staging with a component ID from there and mark it complete to test this functionality. When downloading an EAD from the ASpace interface without unpublished records, the DAO should not appear.
The text was updated successfully, but these errors were encountered:
Description of Problem
Archivists frequently "re-process" a collection. To do this, they export the records from ASpace in bulk, edit them outside of ASpace, and then re-import them. When this happens all the component IDs change. For public items they can see that it has a DAO, so they need to go fix up Figgy for that record (or more likely, provide to us a CSV of old ID -> new ID and we'll process it - if that happens a lot maybe we'll need a feature for that too), but for private items there's no DAO, so the record in Figgy gets orphaned (its component ID is now wrong, and the archivist has no way to know that the item ever had a Figgy object other than by individually checking every one of thousands of private component IDs.)
They've proposed fixing this by having Figgy ALWAYS insert a DAO into ArchivesSpace, but making it "unpublished" if it's a private item.
Acceptance Criteria
Priority recommendation
In talking to stakeholders, it'd be great if we could get to it in November, but if it got pushed out until the beginning of the new year that would be okay.
Sudden Priority Justification
Until this is fixed records will continue to become orphaned, the efforts we took to digitize them wasted and making them inaccessible to patrons. There aren't any large reprocessing projects coming up, but they can come up suddenly.
Technical Tips
The "publish" field:
figgy/app/services/dao_updater.rb
Line 77 in 0f4ede3
Checking for visibility:
figgy/app/services/dao_updater.rb
Lines 11 to 12 in 0f4ede3
Staging should update records to https://aspace-staging.princeton.edu/staff/ - we can create a record in Figgy staging with a component ID from there and mark it complete to test this functionality. When downloading an EAD from the ASpace interface without unpublished records, the DAO should not appear.
The text was updated successfully, but these errors were encountered: