Bug 36996 - Add a system preference to mark items unavailable in z9350 responder
Summary: Add a system preference to mark items unavailable in z9350 responder
Status: Needs documenting
Alias: None
Product: Koha
Classification: Unclassified
Component: Z39.50 / SRU / OpenSearch Servers (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Nick Clemens (kidclamp)
QA Contact: Kyle M Hall
URL:
Keywords:
: 28981 (view as bug list)
Depends on:
Blocks: 37230
  Show dependency treegraph
 
Reported: 2024-05-30 18:57 UTC by Nick Clemens (kidclamp)
Modified: 2024-08-28 20:26 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
24.11.00
Circulation function:


Attachments
Bug 36996: Add z3950Status system preference (9.00 KB, patch)
2024-05-30 19:07 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 36996: Add z3950Status system preference (13.36 KB, patch)
2024-06-18 19:04 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 36996: Add z3950Status system preference (13.40 KB, patch)
2024-06-20 22:40 UTC, Phil Ringnalda
Details | Diff | Splinter Review
Bug 36996: Add z3950Status system preference (13.32 KB, patch)
2024-07-19 10:41 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 36996: (QA follow-up) Fix number of unit tests (704 bytes, patch)
2024-07-19 10:41 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens (kidclamp) 2024-05-30 18:57:11 UTC
Some libraries would like to use additional item fields for determining if an item is available when showing z3950 results.

This bug is to add a new system preference to determine availability (yes|no) via a YAML system preference - similar to OPacHiddenItems
Comment 1 Nick Clemens (kidclamp) 2024-05-30 19:07:17 UTC Comment hidden (obsolete)
Comment 2 David Cook 2024-05-31 02:03:30 UTC
OpacHiddenItems gives me nightmares. Are we sure that we want to add more things like it?

Shouldn't OpacHiddenItems already cover off this scenario?
Comment 3 Katrin Fischer 2024-05-31 07:53:14 UTC
(In reply to David Cook from comment #2)
> OpacHiddenItems gives me nightmares. Are we sure that we want to add more
> things like it?
> 
> Shouldn't OpacHiddenItems already cover off this scenario?

I think this is a different thing. They don't want to hide the items, they want a simplified version of availability and Nick just meant "a yaml preference".
Koha uses several fields and attributes to determine availability (damaged, restricted, notforloan...) and not all systems are happy to deal with that.

But I wonder about the functionality that was built into the z39.50 responder - didn't that have a similar goal?
Comment 4 Nick Clemens (kidclamp) 2024-05-31 10:41:18 UTC
(In reply to Katrin Fischer from comment #3)
> (In reply to David Cook from comment #2)
> I think this is a different thing. They don't want to hide the items, they
> want a simplified version of availability and Nick just meant "a yaml
> preference".

Exactly, I just meant using the same structure for defining the rules

> Koha uses several fields and attributes to determine availability (damaged,
> restricted, notforloan...) and not all systems are happy to deal with that.
> 
> But I wonder about the functionality that was built into the z39.50
> responder - didn't that have a similar goal?

This extends that functionality - currently it checks the various statuses - if none are found then the item is available.

This adds a new check, based on a system preference, that will add a status of 'SYSPREF' to the list

If no statuses are found, then we pass a single 'AVAILABLE' status
If other statuses are found, they can either be sent as a single field, with all statuses concatenated, or multiple fields, one per status
Comment 5 Nick Clemens (kidclamp) 2024-06-18 18:53:35 UTC
*** Bug 28981 has been marked as a duplicate of this bug. ***
Comment 6 Nick Clemens (kidclamp) 2024-06-18 19:04:49 UTC
Created attachment 167864 [details] [review]
Bug 36996: Add z3950Status system preference

This bug adds a new system preference 'z3950Status' which takes a yaml block and marks any items matching
the conditions as unavailable via z3950 results

It obeys the existing z3950 extra fields, adding item ststus to field $k

To test:
0 - Apply patch, update database
1 - Setup your koha to use itself as a z39 source in Administration/Z3950/SRU servers:
    host: localhost
    port 2100
    database: biblios
    syntax: MARC21 (or UNIMARC if applicable)
2 - Uncomment the config line in /etc/koha/sites/kohadev/z3950/config.xml
    Also make sure to remove the backslashes escaping the hyphens
3 - Restart all
4 - Cataloging - New from Z3950
5 - Search your records, view the marc to confirm status subfield $k is included
6 - Add items to a record with various statuses (lost,damaged,withdrawn) and itemtypes
7 - Edit syspref AdditionalFieldsInZ3950ResultSearch o add 952$k
8 - Search for record above - confirm statuses show as expected
9 - Edit new syspref z3950Status - confirm the language of the pref makes sense
    itype: [BK]
    ccode: [REF]
10 - Search z39 again and confirm items and collection codes are marked 'SYSPREF' in $k
11 - Edit Authorized values - add category Z3950_STATUS
12 - Add authorized vlaue: SYSPREF with Description: System preferenced
13 - Restart all
14 - Search z39 again and confirm statuses show new description

Sponsored by: Northeast Kansas Library System <https://www.nekls.org>
Sponsored by: South East Kansas Library System <https://www.sekls.org>
Comment 7 Phil Ringnalda 2024-06-20 22:40:12 UTC
Created attachment 167943 [details] [review]
Bug 36996: Add z3950Status system preference

This bug adds a new system preference 'z3950Status' which takes a yaml block and marks any items matching
the conditions as unavailable via z3950 results

It obeys the existing z3950 extra fields, adding item ststus to field $k

To test:
0 - Apply patch, update database
1 - Setup your koha to use itself as a z39 source in Administration/Z3950/SRU servers:
    host: localhost
    port 2100
    database: biblios
    syntax: MARC21 (or UNIMARC if applicable)
2 - Uncomment the config line in /etc/koha/sites/kohadev/z3950/config.xml
    Also make sure to remove the backslashes escaping the hyphens
3 - Restart all
4 - Cataloging - New from Z3950
5 - Search your records, view the marc to confirm status subfield $k is included
6 - Add items to a record with various statuses (lost,damaged,withdrawn) and itemtypes
7 - Edit syspref AdditionalFieldsInZ3950ResultSearch o add 952$k
8 - Search for record above - confirm statuses show as expected
9 - Edit new syspref z3950Status - confirm the language of the pref makes sense
    itype: [BK]
    ccode: [REF]
10 - Search z39 again and confirm items and collection codes are marked 'SYSPREF' in $k
11 - Edit Authorized values - add category Z3950_STATUS
12 - Add authorized vlaue: SYSPREF with Description: System preferenced
13 - Restart all
14 - Search z39 again and confirm statuses show new description

Sponsored by: Northeast Kansas Library System <https://www.nekls.org>
Sponsored by: South East Kansas Library System <https://www.sekls.org>

Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Comment 8 Phil Ringnalda 2024-06-21 15:01:39 UTC
Though were I doing QA, I would probably object to how overly general the AV name "SYSPREF" is, and I'd want to scope-creep like crazy, wanting to set multiple statuses and to have them in a ranked order where the highest one wins, so if itype REF sets "Available for local use" and loc REPAIR sets "In repair" the net result is "In repair" rather than the untrue "Available for local use", "In repair".
Comment 9 Nick Clemens (kidclamp) 2024-06-24 19:03:13 UTC
(In reply to Phil Ringnalda from comment #8)
> Though were I doing QA, I would probably object to how overly general the AV
> name "SYSPREF" is, and I'd want to scope-creep like crazy, wanting to set
> multiple statuses and to have them in a ranked order where the highest one
> wins, so if itype REF sets "Available for local use" and loc REPAIR sets "In
> repair" the net result is "In repair" rather than the untrue "Available for
> local use", "In repair".

I do like this idea, I think it is a great extension of the feature and will file a bug for it.
Comment 10 Kyle M Hall 2024-07-19 10:41:42 UTC
Created attachment 169193 [details] [review]
Bug 36996: Add z3950Status system preference

This bug adds a new system preference 'z3950Status' which takes a yaml block and marks any items matching
the conditions as unavailable via z3950 results

It obeys the existing z3950 extra fields, adding item ststus to field $k

To test:
0 - Apply patch, update database
1 - Setup your koha to use itself as a z39 source in Administration/Z3950/SRU servers:
    host: localhost
    port 2100
    database: biblios
    syntax: MARC21 (or UNIMARC if applicable)
2 - Uncomment the config line in /etc/koha/sites/kohadev/z3950/config.xml
    Also make sure to remove the backslashes escaping the hyphens
3 - Restart all
4 - Cataloging - New from Z3950
5 - Search your records, view the marc to confirm status subfield $k is included
6 - Add items to a record with various statuses (lost,damaged,withdrawn) and itemtypes
7 - Edit syspref AdditionalFieldsInZ3950ResultSearch o add 952$k
8 - Search for record above - confirm statuses show as expected
9 - Edit new syspref z3950Status - confirm the language of the pref makes sense
    itype: [BK]
    ccode: [REF]
10 - Search z39 again and confirm items and collection codes are marked 'SYSPREF' in $k
11 - Edit Authorized values - add category Z3950_STATUS
12 - Add authorized vlaue: SYSPREF with Description: System preferenced
13 - Restart all
14 - Search z39 again and confirm statuses show new description

Sponsored by: Northeast Kansas Library System <https://www.nekls.org>
Sponsored by: South East Kansas Library System <https://www.sekls.org>

Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 11 Kyle M Hall 2024-07-19 10:41:53 UTC
Created attachment 169194 [details] [review]
Bug 36996: (QA follow-up) Fix number of unit tests

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 12 Martin Renvoize 2024-07-23 16:02:56 UTC
Thanks for all the hard work!

Pushed to main for the next 24.11.00 release as RM Assistant
Comment 13 Lucas Gass 2024-08-28 20:26:01 UTC
Enhancement will not be included in 24.05.x