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

[Bug 24035] New: When recording local use, there is no alert for holds
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24035 Bug ID: 24035 Summary: When recording local use, there is no alert for holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com One way of recording local use is through a statistical patron. Checking an item out to a statistical patron records a local use but does not actually check the item out. However, if the item is on hold, there is no indication that it is so, since the item doesn't go through the checkout process. But since the staff is already processing the item to scan it for local use, I feel like it would be logical to alert them that there is a hold on this item. To reproduce: 1- Create a statistical patron category 1.1- Go to Administration > Patron categories 1.2- Create a new patron category 1.3- Fill in the code, description and expiry date 1.4- In the 'Category type' field, choose 'Statistical' 1.5- Save 2- Create a patron of that category 3- Place a hold on an item (for another patron) 4- Check out the item to the statistical patron => It says 'Local use recorded' but there is no pop-up saying the item is on hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 20844] New: Reset a hold when it is missing after allocation
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Bug ID: 20844 Summary: Reset a hold when it is missing after allocation Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: hughr(a)brimbank.vic.gov.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There currently is no simple way to 'deallocate' a hold if it has gone missing after it is allocated to a patron but before they collect it. This enhancement would work as follows: 1. item is allocated 2. item cannot be located when patron tries to collect it 3. staff member marks item as Lost 4. if hold was originally a bib-level hold, hold reverts from being specific to the missing item, back to a bib-level hold with priority 1. 5. if hold was originally item-level, staff member gets an alert asking whether to cancel or retain the hold 6. (optionally?) a 'lost hold' notice is queued to be sent to the patron This bug is related to the original description of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19287#c32 and also to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15679 To do it properly, it may require a couple of new settings, something like: LostBibLevelHoldsRevert SendLostHoldNotices -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 150

[Bug 23998] New: Messages REST API
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23998 Bug ID: 23998 Summary: Messages REST API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi Expose messages table via REST API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 34460] New: Patron category should regulate if account can have permissions
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34460 Bug ID: 34460 Summary: Patron category should regulate if account can have permissions 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Permission management would be simpler if there were a setting in patron categories that indicate whether that category of patron can have permissions. - If no, that option would not appear in the patron menu. - If patron category is changed to a category that does not allow permissions, any existing permissions should be cleared when change is saved. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 25122] New: Authority lookup shouldn't include non-authority fields
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '26

28 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25122 Bug ID: 25122 Summary: Authority lookup shouldn't include non-authority fields Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 21826 taught the linker that it should only consider certain subfields while looking for a match and while creating authority records, but authority lookup from the plugin link in the basic editor or from ctrl+shift+L in the advanced editor still considers them. Given "700 1_ $aBurns, Ken,$d1953-$etelevision director,$etelevision producer." the linker will search for an authority without the director/producer bits and if it doesn't find a match will create an authority without them, but ctrl+shift+L will fill the Search main heading search field with "1953- television director, television producer." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 30312] New: letter.pl All libraries selection should only show All libraries
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '26

28 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30312 Bug ID: 30312 Summary: letter.pl All libraries selection should only show All libraries Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org This page drives me nuts. It would be appreciated if the "All libraries" selection would only show the templates that are for (All libraries). Maybe it should be changed to "Defaults" to show (All libraries), and have the (All libraries) show everything. Either way, it would be helpful to change this so you could see it one way or the other. The way it is now is maddening. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 25390] New: Login box is removed from opac-main.tt if Shibboleth or CAS is enabled
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '26

27 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25390 Bug ID: 25390 Summary: Login box is removed from opac-main.tt if Shibboleth or CAS is enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On the OPAC main page (opac-main.tt) if CAS or Shibboleth are enabled than we remove the login box on the right side of the page (#login). I am wondering if this is necessary: 1. It does not remove local login functionality as you can still login via the modal in the top right corner. 2. In multi library systems this can be a problem as some might use a SSO service while others would like to see the login box on the right side. 3. Maybe it would be simpler to keep the login box regardless of sign in method and hide it via CSS for libraries that don't want it? -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 27785] New: Point of sale needs a note field
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '26

27 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27785 Bug ID: 27785 Summary: Point of sale needs a note field Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org In the patron account, when making a payment, you have a note field. This note field was left off the Point of sale interface. This is REALLY NEEDED. We have a payment type of Check that we offer because, we accept checks. It is this note field where we record the check number. WE REALLY NEED THIS NOTE FIELD! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 17772] New: Allow to sort lists by date the record was created
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '26

27 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17772 Bug ID: 17772 Summary: Allow to sort lists by date the record was created Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Lists in OPAC and staff can be sorted by different fields. It would be nice if we could offer 'date created' as an additional option for sorting. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 23849] New: Update the list of sysprefs to share with Hea
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23849 Bug ID: 23849 Summary: Update the list of sysprefs to share with Hea Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org We have a lot of sysprefs that are not recorded in Hea. We lack a process to keep the list up-to-date. We are going to have an updated list for 19.11. For next releases it should be a new post release task (https://wiki.koha-community.org/wiki/Post_major_release_tasks) This bug report could be reused for the next releases. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 81