ACQ Unit Scalability Considerations

Table Of Contents

Implementation details

1. Adding this model to additional records would require schema changes in all of the desired records to capture acq unit assignments

2. A new "teams" api would potentially need to be developed for tracking the user/group assignments... or work this into the actual user records

3. Each of the modules associated with those records would need to implement business logic to consult the teams API and enforce the teams logic.
4. We need to update the UI for managing the teams and team assignments.

Functional Issues

1. We would need to handle precedence in cases where there's a record hierarchy... instance -> holdings -> items

2. Need to consider system users (e.g. used in mod-search to access inventory data so it can index it in elasticsearch... those types of system users would need to be assigned to the appropriate teams) Even integration like GOBI/EBSCONET creating or updating records that may have unit assignments. Should system users need to be added to each appropriate team or always be considered a part of every team?

Possible improvements

1. OKAPI for instance supports the notion of filters. A filter can be registered with OKAPI to fire on every request, prior to OKAPI proxying the request to the target module. There's an auth filter that sends the request context to mod-authtoken, who then either allows the request or rejects it. if it's allowed, OKAPI proceeds to proxy it. Possible performance issues here as FOLIO has developed and later abandoned modules which use this filter functionality.