RA/UM (problematic): have discovered deprecated fields by surprise, just looking at API documentation (examples: createdDate and updatedDate fields in users table, patronGroup from requests)
RA/UM (positive): extensive discussion with stakeholders on
CIRC-1112
-
Getting issue details...STATUS
, including reporting
change in SRS fields: instance_id → external_id, instance_hrid → external_hrid
Note that the LDP pulls these data straight from the database, and Metadb will pull all data from the database, so it's important to be notified of changes that occur in the database; for other parts of LDP and other groups, changes to APIs are important
PO Line change in Kiwi: we did request a direct linkage to holdings, but when it was implemented, it didn't do anything retroactive, so there is old data that each institution will have to deal with separately
Changes to property name:
mod-inventory: Rename holdingsId to holdingId - being reviewed in code commit for pull request 453. This is linked to the work on duplicate identifiers in the holdings, instance, and item records. See this Jira for reference.
MODINV-589
-
Getting issue details...STATUS
RM/ERM:
new or deprecated fields (example: transactions encumbrance, amountAwaitingPayment)
FOLIO processes, such as fy rollover, that affect calculations in reports
Inconsistency with property name for holdings records id → sometimes holdingsRecordsIds or holdingsId
Reasons why Release Notes and Sprint Reviews are not sufficient:
note: we're not really interested in UI changes, which is what the sprint review focuses on. We really want to know the changes that affect the database. Those seem to show up more in GitHub PRs, not even in release notes. For example, Data Import will say, "we have better logging capability, you can click on...". That's very high level and focused on UI, not the API or the database.