SIP2: Protocol for self-checkout (UXPROD-1001)

[SIP2-28] SIP2: Backend Configuration - store configs per tenant Created: 19/Nov/18  Updated: 25/Jun/19  Resolved: 20/May/19

Status: Closed
Project: sip2
Components: None
Affects versions: None
Fix versions: 1.0.0
Parent: SIP2: Protocol for self-checkout

Type: Story Priority: P2
Reporter: Hkaplanian Assignee: Martin Tran
Resolution: Done Votes: 0
Labels: q1-2019-spillover
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines UXPROD-1002 SIP2: Protocol for self-checkout - in... Closed
Sprint: 3Ms-SIP2-62, 3Ms-SIP2-63
Story Points: 2
Tester Assignee: Magda Zacharska
Epic Link: SIP2: Protocol for self-checkout

 Description   

The configs retrieved from mod-configuration module are stored without taking into account the tenant and the values of the configs are shared between requests. Potentially in case several tenants are going to use the same instance of the service and have different configs, there might be issues that unexpected configs are used within the flow.

The logic of RepositoryConfigurationHelper implemented should be something like:
• get data from mod-config
• put the returned configs to the vert.x context overriding already existing values



 Comments   
Comment by Magda Zacharska [ 20/Mar/19 ]

We need a way to configure each station for each tenant, to determine what given station can do. Those values should be used in the FOLIO status response to SC kiosk. For the initial release we do not plan adding any GUI for setting up configuration so this configuration should be handled by mod-config

Comment by Magda Zacharska [ 25/Mar/19 ]

The configuration should include:

  • Supported Messages (for this initial implementation it should contain at least Checkin, Checkout, Login,Request SC/ACS Resend, End Patron Session)
  • Number of retries allowed
  • Timeout periods in seconds
  • Terminal location (service point?)
Comment by Magda Zacharska [ 03/Apr/19 ]

Cate suggested that we set SC as their own service points without (1) making them pickup service points for requests and (2)not associating them with any shelving locations. That way there is a clear audit trail from getting items from the self check station to the circ desk and then wherever they need to go from there.

Comment by Martin Tran [ 30/Apr/19 ]

??The configuration should include:

Supported Messages (for this initial implementation it should contain at least Checkin, Checkout, Login,Request SC/ACS Resend, End Patron Session)
Number of retries allowed
Timeout periods in seconds
Terminal location (service point?)??

Magda Zacharska The first 3 items seem global, belonging to ACS's configuration, only Terminal location (service point) is tenant/SC-specific. Can you please confirm?

Comment by Magda Zacharska [ 30/Apr/19 ]

Martin Tran Supported Messages are definitely not global. There might be one tenant that supports Checkin and Checkouts only and another tenant might support Chekin, Checkout and Paid Fees and Patron Block messages. I agree that Number of retires allowed and Timeout period might be global but if different hardware might require a different setup as well.

The list of parameters listed above was meant as an example as there are other parameters that could be tenant/SC dependent. We obviously should also consider Institution id

Also, there could be a tenant that uses one of their SCs for paying fees, so desensitize/resensitize might not be applicable. Not all tenants would like to have SC sounding alarms as well.
SC language will differ from tenant to tenant, PIN required as well.

Debug settings - should they be identical for all SC for all tenants?

Comment by Martin Tran [ 02/May/19 ]

Tenant Configuration
Supported messages
on-line status
status update ok
off-line ok
date/time sync
protocol version
institution/tenant id
screen message
print line
Retries allowed
Timeout periods

Local Timezone

"Home" address type UUID for tenant.

Hold items limit
Overdue items limit
Charged items limit
Fee limit
Currency type
Language

SC Configuration
Terminator delimiter
Field delimiter
Error Detection Enabled
Char set
SC time zone
checkin ok
checkout ok
ACS renewal policy
library name
terminal location
maxPrintWidth

Comment by Magda Zacharska [ 03/May/19 ]

Following properties are patron level specific so there should not be a part of the tenant level configuration:

Hold items limit
Overdue items limit
Charged items limit
Fee limit

I am not sure what screen message and print line configuration would contain as the values of those fields would depend on the ACS response.

Comment by Magda Zacharska [ 13/May/19 ]

Reviewed list of configuration parameters with different levels of configuration

Hardcoded
protocol version

Tenant Confguration
Supported messages
status update ok
off-line ok
Homeaddresstype

SC
Retries allowed
Timeout periods
check in/ Ok
Location code (to follow up with Johan)

SC Startup
Delimiters (terminal/field)
Error detection enabled
Charset
InstitutionId
Folio Okapi Url
SSL support
SIP port

Dynamic
Date/time sync
Screen Message (empty for now)
Print Line (empty for now)
Online status (HC?)
timezone
lang (HC?)
library name (HC?)

Questions for Johan:
Terminal location usage
ACS Renewal Policies
Library Name: campus, library name or code or uuid?

Comment by Matt Reno [ 14/May/19 ]

I think we should add "terminal password" to this list somewhere. Most likely in the kiosk (SC) configuration. It can be sent in every command except "login" and "sc status". I don't think Chalmers requires this, so it is likely not a high priority, but adding support for this field should be considered or at least documented here. Perhaps acting on the field should be deferred.

Generated at Fri Feb 09 00:14:56 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.