Bug 18436 - Add home library to the SIP2 patron info response 64
Summary: Add home library to the SIP2 patron info response 64
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-14 17:28 UTC by george
Modified: 2024-07-04 20:37 UTC (History)
3 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Crowdfunding committed: 0
Crowdfunding contact:
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 18436: SIP: Add home library to the SIP2 patron info response 64 (1.26 KB, patch)
2017-04-14 21:16 UTC, Marc Véron
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description george 2017-04-14 17:28:33 UTC
Koha's SIP2 server should provide additional patron related info, in this case the
patron's home library.  This will be a new segment and should be the key not the name.

The following is an example from another ILS SIP2 response with the segment AQ providing the home library info.

SIP2:response:: 64              00020170412    183400000000000001000000000000AOzzz|AA21391999999999|AEWALKER JONNY|AQpcl|BZ0050|CA0020|CB0250|BLY|CQY|BHUSD|CC10.|BD12655 S KOHA AVE, HELLO, AZ, 99999|BF111-222-3333|DJWALKER MOLLY|PB19950808|PCres|PE20190412    235900|PS20190412    235900|ZYres|AY2AZB936

Thanks... George
Comment 1 Marc Véron 2017-04-14 21:16:07 UTC
Created attachment 62183 [details] [review]
Bug 18436: SIP: Add home library to the SIP2 patron info response 64

This patch adds the patron's home library code as AQ segment to response 64 (patron
information)

To test:
- Set up Koha SIP2 server ( https://wiki.koha-community.org/wiki/Koha_SIP2_server_setup )
- Test without patch, verify that AQ segement does not appear in response 64
- Apply patch, stop / start SIP2 server (maybe restart plack and memcached
  as well)
- Verify that AQ segment with patron's home library code appears in response
  64
Comment 2 Colin Campbell 2017-04-18 07:59:06 UTC
Would be useful to know which supplier has added the AQ field to the 64 response as the published sip2 and sip3 specs define it as permanent item location
Comment 3 george 2017-04-19 01:40:59 UTC
The example was from Sirsi Dynix (Horizon).

My understanding now is that the AO segment can be an option for providing the patron home "UsePatronBranchForPatronInfo; If ON, the SIP patron information response (64) will use the patron branch rather than the institution ID in the AO field."

The issue I have with this is that multiple third party access may encounter a conflict.  But this patch is a nice to have.
Comment 4 Nick Clemens (kidclamp) 2017-05-02 09:46:02 UTC
Why not use the existing functionality to send patron's homebranch in the AF field?

send_patron_home_library_in_af="1"
Comment 5 Colin Campbell 2017-05-02 16:56:29 UTC
(In reply to Nick Clemens from comment #4)
> Why not use the existing functionality to send patron's homebranch in the AF
> field?
> 
> send_patron_home_library_in_af="1"

AF is a screen message. I'm assuming that the point of this feature is to supply the information to be used by the sip unit and that will expect it in a specific field. In practice suppliers are unlikely to even attempt to parse such data out of AF. 
I'd still be interested to know which machine supplier is requiring AQ (I was asking about SIP devices not LMSs above), if we dont have one then AF would be the logical place if we want to display this info.
Comment 6 george 2017-05-05 06:29:36 UTC
We provide a solution that supports multiple ILS providers and SIP2 is the underlying service across those various ILS.  When I cannot provide the needed feature using SIP2 I have to look to the ILS in hopes that they have an "api" that  provides third-party support.

In this case there was a need to derive the patron "home library" and this was not available via SIP2 and there are no third party api.  So, the path was to ask for a change to SIP2, otherwise plan B was to develop a work around that in the long run was not sustainable.

In the end I was able to verify that this patch works, but they were not ready to accept this patch.  Instead, there was an option to utilize the AO segment to provide the patron home library.  I am hoping they will incorporate this patch at a later point.
Comment 7 george 2017-05-05 06:31:51 UTC
We provide a solution that supports multiple ILS providers and SIP2 is the underlying service across those various ILS.  When I cannot provide the needed feature using SIP2 I have to look to the ILS in hopes that they have an "api" that  provides third-party support.

In this case there was a need to derive the patron "home library" and this was not available via SIP2 and there are no third party api.  So, the path was to ask for a change to SIP2, otherwise plan B was to develop a work around that in the long run was not sustainable.

In the end I was able to verify that this patch works, but they were not ready to accept this patch.  Instead, there was an option to utilize the AO segment to provide the patron home library.  I am hoping they will incorporate this patch at a later point.
Comment 8 Katrin Fischer 2023-09-10 21:39:56 UTC
It seems like this suggestion is not standard compliant and we now provide other API that this information could be drawn from (think ILS-DI or REST API)

I am closing, please reopen if you see a need for this still.