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

[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

[Bug 38486] New: No block checkouts are still blocked by fines, checkouts, and blocked item types
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '25

31 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38486 Bug ID: 38486 Summary: No block checkouts are still blocked by fines, checkouts, and blocked item types Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The purpose of no block checkouts in SIP is to indicate that the SIP machine has made an offline ( "store and forward" ) transaction. The patron already has the item. As such, the item must be checked out to the patron or the library risks losing the item do to lack of tracking. As such, no block checkouts should not be blocked under any circumstances. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[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

[Bug 26867] New: Holds to Pull should use cn_sort
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '25

28 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26867 Bug ID: 26867 Summary: Holds to Pull should use cn_sort Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: - create three bibs, each with one item. those items should have these call numbers: -- JC43 .G6 1890 -- JC330 .F74 2000 -- JC480 .R63 2006 - place an item level hold on each item - go to Holds To Pull, sort by call number - notice items are order incorrectly, going 330, 43, 480 - use a report to pull the cn_sort values for your 3 items, confirm that ordering by cn_sort in your report correctly orders them 43, 330, 480 We should use cn_sort here to get them in the correct order. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 33516] New: Accessibility: WCAG 1.4.1 - Content reflow
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '25

27 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33516 Bug ID: 33516 Summary: Accessibility: WCAG 1.4.1 - Content reflow Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org 1.4.10 Reflow: Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for: (Level AA) • Vertical scrolling content at a width equivalent to 320 CSS pixels; • Horizontal scrolling content at a height equivalent to 256 CSS pixels. Except for parts of the content which require two-dimensional layout for usage or meaning. These 2 requirements are to be met simultaneously and are not independent of each other. A user should be able to increase the size of text to 200% even when the information is displayed on a narrow mobile phone screen. Alternatively, a user should be able to magnify the screen to 400% and increase the text size a further 200% Users with visual impairments often enlarge web content to make it easier to see. When content is enlarged to 400% zoom or viewed on a screen with a width of 320 CSS pixels, content should be presented to a user with no loss of information or functionality, and without requiring scrolling in two dimensions. The value of 320 CSS pixels was chosen as a reasonable minimum size that authors could achieve and also replicates the smaller screen sizes of common mobile devices. The width of 320 CSS pixels exactly corresponds to a desktop browser window set to a width of 1280px and zoomed in to 400%. FAIL: When the browser window is set to a width of 320px on the homepage, the horizontal scroll bar is displayed. FAIL: When the browser window is set to a width of 320px on the ‘Details for: Biblio title’ page, the horizontal scroll bar is displayed. Other pages may also be failing on this criteria.. To reach AA standard, we are required to rework these pages and how they reflow for such zoom levels/screen sizes. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 17507] New: Preference to limit how old an offline circ file can be when uploaded
by bugzilla-daemon＠bugs.koha-community.org 26 Mar '25

26 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17507 Bug ID: 17507 Summary: Preference to limit how old an offline circ file can be when uploaded 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We recently ran into an issue where old transactions were uploaded from offline circ. This caused a BIG MESSS. Mistakes will happen. It would be great if there was a setting in Koha to limit the number of days old a file can be when uploaded. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11