Backend Work for UICIRC-54: Anonymize Loan History

I think this is likely superceded by the anonymization work that the Concorde team are now responsible for, so am closing

Indeed, implementing this in mod-circulation-storage is the most expedient way to start the work.

I think there are a few of questions which might contribute to that decision. I have tried to order them in terms of priority and tangibility.

I believe these questions are relevant wherever we choose to do this work, only the impact may differ. It may be those impacts are deferrable, or even desirable.

Questions

1. Where would the configuration for anonymization be kept (within circulation or as general configuration)?

2. What collaborators need to be involved in the anonymization decision (e.g. fees and fines)?

3. When would the capture of loanee information occur? (w.g. when should patron group be stored with the loan?)

4. What parts of the system need visibility of this behaviour (e.g. reporting)?

5. Where would we expect this to happen (is this conceptually a storage or business logic concern)?

Location of configuration

This likely affects dependencies between modules in our reference environments. For example, if configuration is stored centrally, whichever module performing anonymization would need a dependency on the configuration interface.

If mod-circulation-storage is chosen, I think it would likely the first explicit storage -> storage level dependency (maybe apart from authentication which is a slightly special case, and has implicit dependencies).

Decision making collaborators

Whilst it is out of scope of [UICIRC-54], a likely factor in the anonymization decision will be whether a loan has open fees or fines associated with it. That likely means that the module making the decision whether to anonymize a loan will need to have a dependency on the feesfines interface.

The impact of this would be similar to if we choose to have the configuration kept centrally.

Combined with the configuration question (and maybe the note about loanee information capture below) this might increase the priority for being able to declare optional dependencies (and be able to take compensating action).

Visibility of output

My current understanding is that the forthcoming reporting implementation is going to be based upon interception within Okapi and dispatch via some form of messaging. Which means that only changes made via Okapi are visible to the process.

If the change from non-anonymized -> anonymized is made within mod-circulation-storage and we want it to be visible to this process, we would likely need an additional, alternate mechanism. Particularly as this is likely the last time a loan would be changed (possibly unlike)

Capture of loanee information

[UICIRC-54] suggests that we need to store the patron group of the loanee, so that it is usable after anonymization. We need to decide when to capture this information. Typically this has occurred when a record is created / updated, and is done within the business logic module, as this is aware of the related records.

If this is to be captured at these points, then it could likely occur within the business logic module process. If it is not, and is to be captured at the point of anonymization, this would have a similar impact to the configuration and collaborator decisions.

Conceptual responsibility

This probably the least tangible aspect, and is likely the most deferrable, it likely affects more non-functional qualities. For example, which interfaces would need re-implementing or which module implementation needs forking in order to extend this behaviour beyond the reference?

How about we do the anonymization in the mod-circ-store module (which is RMB). What would be the disadvantages of such approach?

I thought I'd describe the scheduling options here (as it seemed a better fit for the audience than and the needs are similar).

Mod-circulation is not based upon RAML Module Builder and does not currently support scheduling.

I believe we have 4 (or 5) options available to provide this:

• Migrate mod-circulation to RAML Module Builder version 19.x (or 20.x)

• Extract the scheduler mechanism in RAML Module Builder to a library that can be used independently of other features

• Implement a FOLIO scheduler, that is a shared capability, independent of implementation language choice etc

• Implement a scheduler within mod-circulation independent of RAML module builder