Circulation Audit logs

Circulation Audit logs of all actions filtered by a patron and/or an item with additional filters.

Circulation supports interaction with PubSub. So we can use it for logging of actions. The following approach can be applied:

1) Interceptor generates event for some action and send it to PubSub;

2) Listener handles these events and saves it in storage;

3) Client retrieves logs from Logs Storage.

LogRecord

LogRecord is the main entity for saving/retrieving log info:

Field	Type	Default	Required	Note
eventId	UUID	N	Y
userId	UUID	N	N
itemId	UUID	N	N
Object	String	N	N	enum: Fee/Fine, Item Block, Loan, Manual Block, Notice, Patron Block, Request
Action	String	N	N
Date	DateTime	N	N
ServicePointId	UUID	N	N
Source	String	N	N
Description	String	N	N

DB structure

DB should contain table for each logged object. This will improve performance by reducing the size of the table.

Tables: loans, fees_fines, item_blocks, patron_blocks, manual_blocks, requests, notices

Typical table structure:

id	user	item	action	date	servicePoint	source	description	linkTo	notes
...	...	...	...	...	...	...	...	...	...

HL Flow Design

Flow description:

LogRecord saving:

1) LogUtils provides inline handler that construct event message with request (optional), response (mandatory), metadata (TBD). This handler is built into the logic of each method that handles a specific business process.

2) LogUtils sends event to PubSub/Kafka.

3) LogListener listening to the event bus and gets event.

4) LogRecordResolver determines type of record, extracts needed information, populates LogRecord and saves record to DB.

LogRecord retrieving:

1) Client makes call to LogsService /audit-data/logs with CQL query and shows result.

Open questions