- Saving of stale records and optimistic concurrency (https://issues.folio.org/browse/MODINV-109 as an example)
- When a record is saved in the UI, it is based upon the representation when it was fetched, with changes reflecting the edits. This means that if an edit page is open for an extended period of time, changes by other clients might be lost
- How to do in non-storage modules?
- How to grant permissions to other endpoints?
- How to segregate between tenants?
- How to avoid collisions between scheduled tasks when running multiple instances of a module?
- Publish / Subscribe
- Is there work planned that is intended to use this?
- There are existing features that have significant compromises (e.g. patron notice sending)
- Record migration during module upgrades
- When to perform this e.g. during the invocation to the Tenant API?
- How should the system behave whilst it is happening (if not done during activation)?
- Standardise API behaviour, for example:
- should PUT allow for creation of records
- what status code should PUT return when record replaced vs. created
- what status code should delete return record does not exist
- In order for clients to make decisions (e.g. localisation) based upon validation errors provided by the API it is necessary to uniquely identify them in some way
Jira server FOLIO Issue Tracker serverId 6ccf3fe4-3301-368a-983e-20c466b11a49 key FOLIO-1716