SIP2: Protocol for self-checkout
(UXPROD-1001)
|
|
| 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: |
|
||||||||
| 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: |
| 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:
|
| 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) 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. Debug settings - should they be identical for all SC for all tenants? |
| Comment by Martin Tran [ 02/May/19 ] |
|
Tenant Configuration Local Timezone "Home" address type UUID for tenant. Hold items limit SC Configuration |
| 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 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 Tenant Confguration SC SC Startup Dynamic Questions for Johan: |
| 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. |