August 2023 - Koha-bugs - lists.koha-community.org

[Bug 31457] New: Move Koha::Patron::Debarment into Koha::Object based classes
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31457 Bug ID: 31457 Summary: Move Koha::Patron::Debarment into Koha::Object based classes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Collector bug for removing the Koha::Patron::Debarment which is written in C4 style and replacing it with the new Koha::Object based class pair, Koha::Patron::Restriction(s). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 33277] New: Correctly handle linking subfields with no defined thesaurus
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33277 Bug ID: 33277 Summary: Correctly handle linking subfields with no defined thesaurus Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is a follow-up to bug 33159, which is a followup to bug 30280 Currently we are handling all subfield other than 6XX as if they are lcsh - this doesn't work in all scenarios. When a record has 008 character 11 =n - "Not applicable" the match won't go through -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 100

[Bug 22322] New: Self-checkin module should provide for automatic logins (like self-checkout)
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22322 Bug ID: 22322 Summary: Self-checkin module should provide for automatic logins (like self-checkout) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: oliver.behnke(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- The self-checkin (SCI) module currently requires to set up a dedicated kiosk terminal for its purpose. The reason being that you can't provide user/password system preferences for an automatic login, like you can for the self-checkout (SCO) counterpart. Our use case is the following: we are already using the SCO module with automatic login of the dedicated SCO patron, and our actual patrons identify themselves via their cardnumber. While they can obviously check in their books via the SCO module, we'd like to streamline the process such that they don't have to login with their cardnumber in order to simply return a book. The SCI module would be ideal for this but, effectively, it can't be used on the same terminal as switching between the modules currently requires a manual login of the dedicated SCI patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 28633] New: Add a preferred_name field and an effective_name method to patrons
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633 Bug ID: 28633 Summary: Add a preferred_name field and an effective_name method to patrons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some institutions store legal names in their directories and for patron imports, but would also like to be able to record 'preferred' names in the patro records. It would be nice to have a field for preferred_name and a method to select the preferred name when it exists, and the firstname when it doesn't Following the item we would suggest 'effective_name' - the additional method can be used in patron-title.inc and in notices to simplify name choice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 195

[Bug 16207] New: Incorporate circulation and fine rules for library groups
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16207 Bug ID: 16207 Summary: Incorporate circulation and fine rules for library groups Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I think we could simplify circulation and fine rules by incorporating library groups into the mix. For example, I have 27 libraries, and 8 of them follow the same set of rules that are different from the defaults. So, what if instead of cloning these special rules to 8 different libraries (and who knows how many other duplicated sets of rules there are), we defined a set of rules for a library group. If the library is part of that group, it goes by those rules. I don't know if we want to use the same library groups that are already defined in the libraries and groups, or if we want to create a unique Circ rule group. Because, there is always the chance that one or more of the libraries in the 8 that are grouped together by affiliation or region could have a slightly different set of rules. However, I think rules by groups would make managing rules far less complicated than managing groups of cloned rules. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 31963] New: Only show reserve fee message on OPAC if they will actually be charged
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31963 Bug ID: 31963 Summary: Only show reserve fee message on OPAC if they will actually be charged Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Hold fees can be set at the patron-category level, and if a patron who could be charged a reserve fee logs into the OPAC and tries the place a hold, a message about being charged a hold fee will show. This message does not take HoldFeeMode into consideration. When HoldFeeMode is set to "any time a reserve is collected" the message will be "You will be charged a hold fee of $X when you collect this item", but if HoldFeeMode is set to anything else, the message will be what we are seeing "You will be charged a hold fee of $X for placing this hold". This message can be a bit unexpected, especially if HoldFeeMode is set so hold fees should only be charged if all items are checked out and the record has at least one hold already. We don't expect we should see the message if there are items available and no holds on the record, when HoldFeeMode is set this way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 27428] New: Show the number of records in the bibliographic record detail page with ElasticSearch.
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27428 Bug ID: 27428 Summary: Show the number of records in the bibliographic record detail page with ElasticSearch. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: ivan.dziuba(a)inlibro.com This preference only for OPAC to show the number of records next to search links in the bibliographic record detail page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 107

[Bug 33711] New: Refine the token passing mechanisms introduced in bug 23336
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33711 Bug ID: 33711 Summary: Refine the token passing mechanisms introduced in bug 23336 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com CC: koha-bugs(a)lists.koha-community.org, tomascohen(a)gmail.com Depends on: 23336 Bug 23336 introduces an API workflow for checkouts by adding two endpoints.. one for availability that creates a token for confirmations that can then be used by the checkouts endpoint to verify that availability has been checked. Whilst I think the availability endpoint is worthwhile in it's own right, I think we could also send back the token in the 409 pre-condition failed response of the checkouts endpoint so one could use that single endpoint for double duty in the right circumstances. I also think we could work on how the confirmation token is sent to the endpoint.. it's currently a simple query param but may lend itself to being part of the x-koha-overrides header or another header? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23336 [Bug 23336] Add an API endpoint for issuing an item to a patron -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. You are on the CC list for the bug.

1 5

[Bug 33709] New: Add override options to checkouts
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33709 Bug ID: 33709 Summary: Add override options to checkouts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com CC: tomascohen(a)gmail.com Depends on: 23336 I stripped out the local overrides when creating a checkouts POST route.. we should add them back in using the accepted x-koha-overrides method. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23336 [Bug 23336] Add an API endpoint for issuing an item to a patron -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 25870] New: Add a q_ccl query parameter to /biblios
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Bug ID: 25870 Summary: Add a q_ccl query parameter to /biblios Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com It would be great if we could just pass a CCL query to the /biblios route -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 90