Bug 21045 - Default checkout limit by patron category for all libraries not managed by SIP2
Summary: Default checkout limit by patron category for all libraries not managed by SIP2
Status: RESOLVED DUPLICATE of bug 27834
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low minor (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-06 10:05 UTC by abernaud
Modified: 2023-06-06 14:49 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description abernaud 2018-07-06 10:05:18 UTC
Hello
We're on Koha 16.05, using selfcheck machines from Nedap.
In our circulation rules, we defined Default checkout limit by patron category for "all libraries". This limit is only configured in the "all libraries" page, and not for each library.
The Circcontrol syspref is set to "the library you are logged in at".

In this configuration, the selfcheck machines, using the SIP protocol, ignore the "Default checkout limit by patron category".
For example, for a patron category called "L", the limit is set to 20 documents. I'm able to check out 20 documents in library 1 through the staff client, and then to add some more check outs through the selfcheck machine.

Please note that the Default checkout limit by patron category defined for all libraries is correctly managed by the staff client (for a patron having the patron category "L", I can't check out more than 20 documents, whatever library I'm logged in at).

Also please note that this problem seems to happen only with selfcheck machines from Nedap. The problem apparently doesn't exist for Bibliotheca selfcheck machines. Could someone confirm this ?

Thanks
Anne-Claire (from Rennes, France)
Comment 1 Lisette Scheer 2023-06-06 14:49:07 UTC

*** This bug has been marked as a duplicate of bug 27834 ***