| Summary: | Add home library to the SIP2 patron info response 64 | ||
|---|---|---|---|
| Product: | Koha | Reporter: | george |
| Component: | SIP2 | Assignee: | Bugs List <koha-bugs> |
| Status: | CLOSED WONTFIX | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | colin.campbell, nick, veron |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| 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 | ||
|
Description
george
2017-04-14 17:28:33 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 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 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. Why not use the existing functionality to send patron's homebranch in the AF field? send_patron_home_library_in_af="1" (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. 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. 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. 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. |