Purpose of this document

It needs to be decided which module "automated patron blocks" functionality has to be implemented in. There are few options:

• mod-circulation (Approach 1)

• new "automated blocks" module (mod-automated-blocks)

  • fetching data from mod-circulation (circular dependency)

  • fetching data from mod-circulation-storage

  • consuming events published by mod-circulation

    • mod-circulation requests block from mod-automated-blocks
    • mod-automated-blocks publishes block events

Overview

It is required for a number of modules (both BE and FE) to be able to check if a patron should be blocked from borrowing, renewing and/or requesting items and why. mod-circulation should check for these blocks every time one of these actions is performed. Also, we need to provide an endpoint (at least for UI modules, see UIU-1273) for checking patron block conditions. Each of these condition checks has a dependency on functionality implemented in various modules:

Approach 1 (mod-circulation)

API

Even though most of the checks will be happening internally in mod-circulation, other modules (UIU-1273) will need to use this functionality to display existing patron blocks to the user, so it is proposed to add a new endpoint:

GET /automated-patron-blocks/{patronId}

Response example:

{
  "automatedPatronBlocks": [
    {
      "blockBorrowing": true,
      "blockRenewal": false,
      "blockRequest": false,
      "message": "Patron has reached maximum allowed number of items charged out"
    },
    {
      "blockBorrowing": false,
      "blockRenewal": false,
      "blockRequest": true,
      "message": "Patron has reached maximum allowed outstanding fee/fine balance for his/her patron group"
    }
  ]
}

Dependencies

No new dependencies are required in mod-circulation for Approach 1.

/patron-block-condition

/patron-block-limits?query=(patronGroupId=={patronGroupId})

/accounts?query=(userId=={patronId} AND status=="Open")

/calendar/periods