D2IR Local Endpoint (Circulation): Patron Verification Endpoint in mod-inn-reach

Purpose/Overview:

The INN-Reach central server attempts to verify that the requesting user is a valid patron of the library they claim to be. To do this, they call the edge-inn-reach endpoint:

/innreach/v2/circ/verifypatron

via POST (see INN-Reach D2IR API Reference.pdf pg. 82 for details on query parameters and POST body). The Edge api passes this request to mod-inn-reach

Requirements:

1. Requirement:
   • Given the patron provides their name in format "First Last", and
   • Given the patron provides their User attribute configured by the system to act as their publicId (externalSystemId or barcode)
   • Given that the local server is not configured to require a PIN/Password
   • When the patron verification request is passed to mod-inn-reach
   • Then the module looks up the user by externalSystemId and verifies that the provide name string is composed of two or more of the user's first, last, middle, or preferred first names
   • Then the module checks if there are any blocks in place for the patron that would prevent requests or loans
   • If the attributes match, and there are no relevant blocks, then return the required response payload (see below for logic to construct the patronInfo object)
2. Requirement:
   • Given the patron provides their name in format "First Middle Last", and
   • Given the patron provides their Library ID (externalSystemId)
   • Given that the local server is not configured to require a PIN/Password
   • When the patron verification request is passed to mod-inn-reach
   • Then the module looks up the user by externalSystemId and verifies that the provide name string is composed of two or more of the user's first, last, middle, or preferred first names
   • Then the module checks if there are any blocks in place for the patron that would prevent requests or loans
   • If the attributes match, and there are no relevant blocks, then return the required response payload (see below for logic to construct the patronInfo object)
3. Requirement:
   • Given the patron provides their name in format "Middle Last", and
   • Given the patron provides their Library ID (externalSystemId)
   • Given that the local server is not configured to require a PIN/Password
   • When the patron verification request is passed to mod-inn-reach
   • Then the module looks up the user by externalSystemId and verifies that the provide name string is composed of two or more of the user's first, last, middle, or preferred first names
   • Then the module checks if there are any blocks in place for the patron that would prevent requests or loans
   • If the attributes match, and there are no relevant blocks, then return the required response payload (see below for logic to construct the patronInfo object)
4. Requirement:
   • Given the patron provides their name in format "First Last", and
   • Given the patron provides their User attribute configured by the system to act as their publicId (externalSystemId or barcode)
   • Given that the local server is configured to require a PIN/Password
   • Given that the patron provides the correct PIN/Password (NOT IMPLEMENTED YET)
   • When the patron verification request is passed to mod-inn-reach
   • Then the module looks up the user by externalSystemId and verifies that the provide name string is composed of two or more of the user's first, last, middle, or preferred first names
   • Then the module checks if there are any blocks in place for the patron that would prevent requests or loans
   • If the attributes match, and there are no relevant blocks, then return the required response payload (see below for logic to construct the patronInfo object)
5. Requirement:
   • Given the patron provides their name in format "First Middle Last", and
   • Given the patron provides their Library ID (externalSystemId)
   • Given that the local server is not configured to require a PIN/Password
   • Given that the patron provides the correct PIN/Password (NOT IMPLEMENTED YET)
   • When the patron verification request is passed to mod-inn-reach
   • Then the module looks up the user by externalSystemId and verifies that the provide name string is composed of two or more of the user's first, last, middle, or preferred first names
   • Then the module checks if there are any blocks in place for the patron that would prevent requests or loans
   • If the attributes match, and there are no relevant blocks, then return the required response payload (see below for logic to construct the patronInfo object)
6. Requirement:
   • Given the patron provides their name in format "Middle Last", and
   • Given the patron provides their Library ID (externalSystemId)
   • Given that the local server is not configured to require a PIN/Password
   • Given that the patron provides the correct PIN/Password (NOT IMPLEMENTED YET)
   • When the patron verification request is passed to mod-inn-reach
   • Then the module looks up the user by externalSystemId and verifies that the provide name string is composed of two or more of the user's first, last, middle, or preferred first names
   • Then the module checks if there are any blocks in place for the patron that would prevent requests or loans
   • If the attributes match, and there are no relevant blocks, then return the required response payload (see below for logic to construct the patronInfo object)
7. Requirement:
   • Given any other combination of Name, Public ID, and PIN/Password
   • Then return the appropriate error state to the central server when the verification request is sent to /innreach/v2/circ/verifypatron

Additional Information:

Constructing the patronInfo payload:

Acceptance criteria:

• AC: If provided with valid patron information that is verified by the module, the module should pass the required payload (according to III-provided documentation) back to the edge module.
• AC: If provided with invalid patron information that is rejected by the backend, the module should return an appropriate error message back to the edge module.