SPIKE: Trigger Aspace DigitalObject updates based on ASpace URI changes, etc.

[mikeapp]

Story

See #1625 for background. We want to be able to keep ASpace Digital Object records up to date.

There are use cases that would require knowing the value a attribute is changed from, such as:

• An object's metadata source change from ASpace, resulting in the need for the Digital Object to be removed.
• An object's ASpace URI is changed, resulting in the need to remove the Digital Object reference from the original archival object and add it to the new one.

Note that we will eventually need to do the same for Voyager, but considering multiple IDs (bib, holding, barcode)

https://api.rubyonrails.org/classes/ActiveModel/Dirty.html might be an option?

Acceptance

• [x] Determine how to determine the need for updates based on the previous value of these attributes.
• [x] Create tickets after team feedback.

[martinlovell]

See info about using active record dirty: #1699

[martinlovell]

After re-reading the specs from Mark, we need to add a call to the metadata cloud digital object API so that digital objects can be updated when they are moved to another archival object.

(The plan was to delete the old DO and create a new one when the aspace URI changed for a Parent in DCS; however, we should move the existing DO instead as the spec says. Management would provide OID, old archival object, and new archival object for this call.)

[mikeapp]

That sounds even better if it is a single call/atomic event!

[martinlovell]

Draft PR: https://github.com/yalelibrary/yul-dc-management/pull/851 with some initial work to monitor for changes.

The PR adds a field to store the digital object representation of the parent as JSON. When a parent is saved, it regenerates the JSON and compare to what is stored in the database. If it's different, it updates the database and calls a send_digital_object_update method (which currently just logs.)

The idea is that management just detects changes in the DO representation of the parent object and sends an update to metadata cloud with the prior value and the new value. The prior or new value can be nil, which would indicate create and delete respectively.

DO representations of private or non-aspace items are currently nil.

This will work well since it won't have to check for special field changes, it just checks to see if the json DO representation changed. And will be easy to expand if we want to create DOs for ILS later by adding a DO representation for those parents.

Metadata cloud will read the prior and new digital object from the request and delete/create/update based on the values.

[martinlovell]

I updated the model so that that JSON is stored in a different table to avoid after_update feedback.

[martinlovell]

Added a feature flag check before attempting to sent to metadata cloud. Also updated logic so that the database JSON doesn't update unless the post to Metadata cloud is successful. This will cause the next update of the Parent to re-post to MC. It will also make sure the JSON isn't updated when the feature flag is not present.

[martinlovell]

https://github.com/yalelibrary/yul-dc-management/pull/851

[FCRodriguez7]

Released management v2.54.3