Patron access to designated library branches during un-staffed periods.

[colinparkeruk]

AUT03 (ACC) was added to indicate that a patron was allowed access to libraries during un-staffed periods. We have now had a request to restrict such access on a per-branch basis, e.g. only after the patron has completed an induction.

[franciscave]

If one or more branches need to be specified in the authorisation, I believe that the best way to achieve this would be to add a (repeatable) location reference to the Authorisation entity, as below:

Id	Element	SIP2 ID	Card.	Format	Description
E13D01	Authorisation identifier		1[4]	String	The LCF entity identifier used when referring to this authorisation.
E13D02	Authorisation type		0-1	Code	LCF code list AUT
E13D03	Authorisation heading		0-1	String	A heading or name for the authorisation. Must be omitted if E13D02 is included.
E13C04	Authorisation description / note		0-n
E13D04.1	Note type		0-1	Code	LCF code list NOT
E13D04.2	Note date-time		0-1	DateTime
E13D04.3	Note text		1	String
E13D05	Location reference		0-n	String	A location to which this authorisation relates.

[colinparkeruk]

That would work, I was just wondering if this new location list would be a duplicate of the existing Patron -> Associated locations list or if that has a distinct usage.

On Wed, 24 Aug 2022 at 17:02, Francis Cave @.***> wrote:

If one or more branches need to be specified in the authorisation, I believe that the best way to achieve this would be to add a (repeatable) location reference to the Authorisation entity, as below: Id Element SIP2 ID Card. Format Description E13D01 Authorisation identifier 1[4] <#m_3843587543268292876_Notes> String The LCF entity identifier used when referring to this authorisation. E13D02 Authorisation type 0-1 Code LCF code list AUT http://LCF-CodeLists.md#AUT E13D03 Authorisation heading 0-1 String A heading or name for the authorisation. Must be omitted if E13D02 is included. E13C04 Authorisation description / note 0-n E13D04.1 Note type 0-1 Code LCF code list NOT http://LCF-CodeLists.md#NOT E13D04.2 Note date-time 0-1 DateTime E13D04.3 Note text 1 String E13D05 Location reference 0-n String A location to which this authorisation relates.

— Reply to this email directly, view it on GitHub https://github.com/bic-org-uk/bic-lcf/issues/295#issuecomment-1225925800, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6VLPFEFZTOKG7BESFQPETV2ZBS5ANCNFSM57PVTV3A . You are receiving this because you authored the thread.Message ID: @.***>

[franciscave]

That would be a possibility, although we'd need to add a slightly complicated code to list LAT that means "a library location that the Patron is authorised to enter when un-staffed". But it seems to me that some kind of Authorisation needs to be recorded, in which case we would either have to add Associated authorisation to the Patron entity, or Associated patron to the Authorisation entity, or both.

My original suggestion was on the assumption that such Authorisations would not be Patron-specific, but apply to Patrons in general. However, that leaves open the question of how a Patron would be informed about the Authorisation. Would there be a message/alert sent to specific or all Patrons about such an Authorisation?

I may be over-complicating this, but it seems to me that we need to understand whether the Authorisation applies primarily to specific Patrons or primarily to specific Locations or a combination of the two.

[colinparkeruk]

The Authorisation would apply to specific patrons. A patron would contact the library, requesting out of hours access to a specific branch or branches and the library would then contact them to arrange an induction session or sessions (one per branch). Once completed, their record would be updated, they would be notified, and they would then have access.

Does that help? I still think that your first suggestion caters for this.

On Fri, 26 Aug 2022 at 12:21, Francis Cave @.***> wrote:

That would be a possibility, although we'd need to add a slightly complicated code to list LAT that means "a library location that the Patron is authorised to enter when un-staffed". But it seems to me that some kind of Authorisation needs to be recorded, in which case we would either have to add Associated authorisation to the Patron entity, or Associated patron to the Authorisation entity, or both.

My original suggestion was on the assumption that such Authorisations would not be Patron-specific, but apply to Patrons in general. However, that leaves open the question of how a Patron would be informed about the Authorisation. Would there be a message/alert sent to specific or all Patrons about such an Authorisation?

I may be over-complicating this, but it seems to me that we need to understand whether the Authorisation applies primarily to specific Patrons or primarily to specific Locations or a combination of the two.

— Reply to this email directly, view it on GitHub https://github.com/bic-org-uk/bic-lcf/issues/295#issuecomment-1228373020, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6VLPHQCPAVHS2ERQ7VM6DV3CSDVANCNFSM57PVTV3A . You are receiving this because you authored the thread.Message ID: @.***>

[franciscave]

Thanks, Colin. I'm trying to imagine how this would be choreographed in LCF terms. I presume that, when the Patron presents their ID in order to enter the library premises, a GET Authorisations for that Patron would be performed, and if one of their Authorisations has the correct Authorisation type (AUT03) and also has a Location reference that matches the ID of the library premises, the Patron will be granted entry to the premises. If it's as simple as that, I don't think we need a full Associated Location composite in the Authorisation record - one or more Location references would be sufficient.

However, I'm wondering whether such Authorisations would be time-limited and whether the time limit would need to be in the Authorisation record or recorded elsewhere. There's an argument for saying that it doesn't need to be in the Authorisation record, because when the period of authorisation ends, the GET Authorisations will simply not return any expired Authorisations. However, if there is value in reminding the Patron when their Authorisation expires, this would have to be somewhere in an LCF record, in which case life gets more complicated: we'd then need an expiry date-time recorded in the Authorisation - but this could vary from Patron to Patron, which would start to get messy.

Thinking about expiry of Authorisations, type AUT01 would expire when withdrawn, type AUT02 would expire immediately the payment has been made, but type AUT03 could be like AUT01 or could require a specific date-time limit. Hmm...

Simplest would be to let the LMS concern itself with expiry of Authorisations and continue not to provide specific support for this in LCF. Any thoughts?

[colinparkeruk]

Hi Francis I think we can keep it simple. As you say, the LMS can handle any expiries and all we need is your first suggestion of adding a repeatable location reference field.

On Fri, 26 Aug 2022 at 17:19, Francis Cave @.***> wrote:

Thanks, Colin. I'm trying to imagine how this would be choreographed in LCF terms. I presume that, when the Patron presents their ID in order to enter the library premises, a GET Authorisations for that Patron would be performed, and if one of their Authorisations has the correct Authorisation type (AUT03) and also has a Location reference that matches the ID of the library premises, the Patron will be granted entry to the premises. If it's as simple as that, I don't think we need a full Associated Location composite in the Authorisation record - one or more Location references would be sufficient.

However, I'm wondering whether such Authorisations would be time-limited and whether the time limit would need to be in the Authorisation record or recorded elsewhere. There's an argument for saying that it doesn't need to be in the Authorisation record, because when the period of authorisation ends, the GET Authorisations will simply not return any expired Authorisations. However, if there is value in reminding the Patron when their Authorisation expires, this would have to be somewhere in an LCF record, in which case life gets more complicated: we'd then need an expiry date-time recorded in the Authorisation - but this could vary from Patron to Patron, which would start to get messy.

Thinking about expiry of Authorisations, type AUT01 would expire when withdrawn, type AUT02 would expire immediately the payment has been made, but type AUT03 could be like AUT01 or could require a specific date-time limit. Hmm...

Simplest would be to let the LMS concern itself with expiry of Authorisations and continue not to provide specific support for this in LCF. Any thoughts?

— Reply to this email directly, view it on GitHub https://github.com/bic-org-uk/bic-lcf/issues/295#issuecomment-1228688966, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6VLPER7CXQWA4PIHZANILV3DVBTANCNFSM57PVTV3A . You are receiving this because you authored the thread.Message ID: @.***>

[franciscave]

OK, I'll prepare a pull request.

[franciscave]

At the Technical Panel meeting on 11 October 2022 it was agreed that there are two use cases that need to be separated:

1. A Patron attempts to access a library location when un-staffed, and the library management systems needs to determine whether that Patron can be given access.
2. A Patron wishes to find out whether they have access to one or more library locations when un-staffed.

Use case 1 does not require any extension of LCF, because the Patron will be using a terminal to attempt to access the library location, and the LMS will therefore know where the Patron is located and can determine whether the Patron can access the location without using LCF.

Use case 2 is a legitimate LCF use case, for which it was agreed in the Technical Panel meeting that the proposed solution is appropriate, and that the distinction between these two use cases should be made clear in the LCF data framework. The following is a modified proposed revision to address this point:

Id	Element	SIP2 ID	Card.	Format	Description
E13D01	Authorisation identifier		1[4]	String	The LCF entity identifier used when referring to this authorisation.
E13D02	Authorisation type		0-1	Code	LCF code list AUT
...
E13D05	Location reference		0-n	String	A location to which this authorisation relates. NOTE: This element is intended for use in responses to Patron requests to retrieve their authorisation(s), which may include access to one or more library locations when un-staffed (authorisation code 'ACC'). The control of access to a library location is out of scope for LCF. Added in vx.x.0