February 2025 - Koha-bugs - lists.koha-community.org

[Bug 37849] New: Permissions for additional content - HTML Customizations, Pages, News, OPAC, etc
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37849 Bug ID: 37849 Summary: Permissions for additional content - HTML Customizations, Pages, News, OPAC, etc Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: Slodico(a)knoxlib.org QA Contact: testopia(a)bugs.koha-community.org We need more granular permissions to control who is allowed to create and edit additional content now that so many options to edit both the staff interface and the OPAC continue to be moved out of systems preferences. The only permission is edit_additional_content and it's all or nothing. It's one thing to allow a branch manager to add some news to the staff interface for their branch. It's another thing entirely to allow them to create and edit information that will display everywhere, or damage (intentionally or not) pages and content created by others. I suggest there be 2 new permissions that allow editing News items in the staff interface. One permission would be to edit their own library's News e.g. edit_own_news and the other to edit all News items e.g. edit_any_news. Creating or editing any other type of additional content would be reserved for those with the edit_additional_content permission. Bug 35693 Granular Permissions to Everything also mentions this issue, but appears to be intended to encourage developers to remember to address permissions issues when rolling out enhancements and new features. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 31097] New: Patron restriction types should display in Staff and OPAC
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31097 Bug ID: 31097 Summary: Patron restriction types should display in Staff and OPAC 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 23681 Where we display the patron restrictions in the OPAC and Staff client, we don't always display the type description.. only the comment. We should add this to the display. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23681 [Bug 23681] Patron restrictions should be user definable -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 47

[Bug 33401] New: Diakrits in authorities
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33401 Bug ID: 33401 Summary: Diakrits in authorities Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: klas.blomberg(a)skovde.se QA Contact: testopia(a)bugs.koha-community.org Created attachment 149122 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149122&action=e… Different subject heading in same authority record Koha doesn't take diakrits in consideration when authority records are created. In swedish we have three extra letters in the alphabet - ÅÄÖ. Koha treats those letters as AAO, and creates one unified authority record for the subject headings "Ankor" (ducks) and "Änkor" (widows) So, if you search for widows as subject you will get matches for Donald Duck. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 38879] New: Vendors only used for ERM should not be visible for print acquisitions
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38879 Bug ID: 38879 Summary: Vendors only used for ERM should not be visible for print acquisitions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org A vendor used for ERM should not be visible for print acquisitions, or print serials subscription. We need a field in vendor records to manage that visibility -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 28860] New: Add system setting to mark Patron fields important
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28860 Bug ID: 28860 Summary: Add system setting to mark Patron fields important Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be nice to add a system setting similar to the BorrowerMandatoryField for the patron form to mark fields important. This would give a visual clue for fields that should be filled in but are not necessarily required. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 25295] New: Allow customization of staff client based on login location
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25295 Bug ID: 25295 Summary: Allow customization of staff client based on login location Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With more library systems or multiple-branch libraries using Koha, it would be really helpful to be able to customize the look of the staff client based on the library a staff member is logged in at. For instance, allow a library system to designate a header or background color on the staff client based on the branch. So branch A would be green, branch B would be purple, etc. This would allow users to easily and quickly identify which branch they are logged in to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 34444] New: Statistic 1/2 not saving when updating fund after receipt
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34444 Bug ID: 34444 Summary: Statistic 1/2 not saving when updating fund after receipt Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 25763 OK in master, not ok in 22.11, untested in 23.05. When the fund is changed after receipt, the statistic values are also updated and show the correct funds, but selected values are not saved. If you change the fund again you can see that pull-downs jump back to the first entry instead of showing the previously selected values. To test: Setup: * Make sure you have at least 2 funds with different stat settings, using AV and not * Create a basket with an order line * Close it and receive shipment * Create an invoice and receive the order line * Finish receiving * Click "Modify fund" * Switch fund, verify the stat fields are updated accordingly * Change values for statistical values * Update fund * Edit fund again = pull downs will jump back to first entry instead of showing the previously picked value free text input seems to work ok at first glance. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25763 [Bug 25763] Allow update of order fund after receipt -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 38045] New: Patron messaging preference table says it is loading but never does if fieldset is collapsed
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38045 Bug ID: 38045 Summary: Patron messaging preference table says it is loading but never does if fieldset is collapsed Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Add Patron messaging preferences to `CollapseFieldsPatronAddForm` system preference. 2. Go to a patron record, new or existing. 3. Scroll down to the message pref section and see `Loading new messaging defaults `. 4. It never loads If the fieldset is collapsed we shouldn't load the table but we also shouldn't show a message saying `Loading new messaging defaults...` -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 37349] New: Use cache for authority types when linking bibs to authorities
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37349 Bug ID: 37349 Summary: Use cache for authority types when linking bibs to authorities Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 LinkBibHeadingstoAuthorities fetches the authority type for the heading for each heading, sometimes more than once, we can improve this -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 37258] New: Locked records can still be modified/deleted by an unauthorized librarian with merge and in advanced editor
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37258 Bug ID: 37258 Summary: Locked records can still be modified/deleted by an unauthorized librarian with merge and in advanced editor Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 31791 Locked records can still be modified/deleted by an unauthorized librarian with merge and in advanced editor. Although the Edit record action is grayed out from the regular Edit pulldown, and also an attempt to open directly the basic editor (.../cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=<biblionumber>) results with Error 403 page, an unauthorized user is still able to modify/delete a locked record in several ways, including: 1. merge operation: if a locked record has been chosen as the destination (ref) record, fields can be inserted/deleted from it as a result of a merge and so modifying the locked record; 2. merge operation: if a locked record has NOT been chosen as the destination (ref) record, the locked record will be deleted; 3. a user cat launch directly the advanced editor (wit URL .../cgi-bin/koha/cataloguing/editor.pl#catalog/<biblionumber>) and save the modified version, with no respect for the lock status and edit_locked_records permission. Theoretically, such an a user could be restricted from using advanced editor, but this does not seem as a right way of solving this issue. And the merge path would still remain open. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31791 [Bug 31791] Add the ability to lock records to prevent modification through the Koha staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13