While Airrecord does have a default find method, it takes the actual Airtable record id (not the value for the ID column) so I'm using .all with a filter to get the necessary uuids
We can’t assume the latest version is what should be in Airtable, particularly if it's a draft. The latest version might be a draft with a request to curate (likely already in airtable & should be there) or a draft that is a result of a curation in progress in which case the latest published version (what is being curated) should be in Airtable instead of the draft version.
The original 60 day window in the go script was because the only timestamp from the catalog API is for when the first draft of a work was created, not published, so 60 days was giving a reasonable margin to capture future versions. By making this an internal process, we have access to actual published timestamp & can shorten that range to 2 days (runs daily but allows for overlap)
Originally we were considering removing stale curation tasks from Airtable, but after discussing with Admins, are holding off on that for now. We don't want to remove their notes on existing curations when a new version is added. Instead, we're putting an 'Updated Version' label on what we’re adding if it has a version already in the table. Admins will be responsible for removing things as they see fit. It is possible we could pull notes from existing curation tasks, merge them into the entry we are adding, and remove the stale version as a future feature.
At this time, the error coming from Airrecord doesn’t have any helpful methods (status, code, etc) so all we can do is string match the message.
Fixes #1458
Couple things to note:
findmethod, it takes the actual Airtable record id (not the value for the ID column) so I'm using.allwith a filter to get the necessary uuids