Bug 36996

OpacHiddenItems gives me nightmares. Are we sure that we want to add more things like it?

Shouldn't OpacHiddenItems already cover off this scenario?

(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?

(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

*** Bug 28981 has been marked as a duplicate of this bug. ***

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>

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>

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".

(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.

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>

Created attachment 169194 [details] [review]
Bug 36996: (QA follow-up) Fix number of unit tests

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Thanks for all the hard work!

Pushed to main for the next 24.11.00 release as RM Assistant

Enhancement will not be included in 24.05.x