Following conversations with Cate , Jakub and Ian . We have come with an initial design and development goal for this work.

At the moment, the circulation context will only have a loan resource (will likely to be followed by requests / reservations, fines etc).

A loan will initially have the following fields:

• A user ID (required, cannot be changed)

• An item ID (required, cannot be changed)

• A loan date (required, cannot be changed)

• A return date (optional, if present implies that the loan is completed and therefore historical)

A loan refers to an item and a user, in the context of the loan, is the user always playing the role of a patron? If so, should we reflect this by changing the user ID property to be a patron ID property?

Which means we can support the following activities:

Checking out an item

Create a new loan record with the user and item, with no other information, that will appear as a current loans for that user.

Change the item status to Checked Out (or maybe Charged?).

Attempting to check out an item which is currently checked out to a different user is a bad which needs to be relayed to the user. Is this still the case when the user is the same as who has already borrowed the item or can it be treated as an idempotent repeat request?

Checking an item in

Update the relevant loan based upon item ID and no return date (inferred as current) with a return date (effectively completing the loan).

Change the item status to Available.

This effectively moves the loan from the set of current loans for a patron to the historical set.

Attempting to check in an item which is not currently checked out results in no changes. Is this a bad request that needs relaying to the user?

Development goal

The first version of the capability will involve:

• A storage module for persistent storage of loans in PostgreSQL (using the RAML-module-builder, in mod-loan-storage)

• A business logic module, which will initially mostly forward on requests to the storage module (possibly in mod-circulation?)

The intention is to have this initial work completed (or at least sufficiently underway to start UI work) by the start of sprint 10.

Additional questions

Batch operations

Both checking in and out might be conveniently performed as a batch, we need further analysis to decide what the behaviour of these operations are, for example, should these operations be atomic and therefore either completely succeed or fail?

Item status

We need to determine if this is directly changed, derived at the time of reading or searching for items, or derived in the background (and stored)?

Hugs,

Marc

Some rough comments/ideas:

• I think to model a loan we need a standalone loan object, as eventually we will need to retain those objects for historical records, audits, etc. Also for circulation we will need a notion of other types of transaction/status objects: requests (holds), fines, loan rules, etc.

• circulation sits exactly in the middle between mod-users and mod-metadata, I think initially we were thinking about modelling it in a separate module (mod-circulation). I don't know whether that still holds, that's one of the things we need to establish on Monday.

• we also know that there may be use-cases where it would be useful to have info like whether item is checked out or not, available directly in the inventory, e.g to filter all checked out item out when browsing/searching them in ui-items. We could probably get by but not leaving those use-cases out for the time being (maybe even for v1?) but I have this nasty feeling that we would be sweeping it under the rug.