July 2024 - Koha-bugs - lists.koha-community.org

[Bug 25781] New: Remove duplicate days_forward method from Koha::Calendar
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25781 Bug ID: 25781 Summary: Remove duplicate days_forward method from Koha::Calendar 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 With bug 15260 the 'next_open_days' method learnt to accept an integer number of days to add before calculating the next open day date. This, in effect, removes the requirement for the days_forward method that does the same. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[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 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 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

[Bug 26275] New: Deleting item should not automatically delete volume
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '25

28 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26275 Bug ID: 26275 Summary: Deleting item should not automatically delete volume Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: - create a bib - add an item - create a volume - add item to volume - in the Holdings table on detail.pl, check the box to select your item and pick Delete selected items - on the next page, do not check "Delete records if no items remain" - click Delete selected items - return to your bib. the item and volume are both gone I don't think we should automatically delete the volume when removing the last item. I'd like to see another check box on the batch deletion screen -- "delete volumes if no items remain" to parallel "delete records if no items remain" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 27964] New: Link to subscription in serial collections view is broken - the field subscriptionid is undefined in the subscription object.
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '25

28 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27964 Bug ID: 27964 Summary: Link to subscription in serial collections view is broken - the field subscriptionid is undefined in the subscription object. Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org The functions C4::Serials::GetSubscription and C4::Serials::GetSubscriptionsFromBiblionumber return subscriptions where subscriptionid is undefined when the subscription have no subscription history. The database queries use wildcards to include fields from a left joined table. subscriptionhistory.subscriptionid will be NULL, which might be the value choosen as the field subscriptionid. How the field is chosen may depend on the version of DBI as this problem was discovered after an upgrade to Ubuntu Focal Fossa from Bionic Beaver. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8