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

[Bug 38820] New: On demand hold delivery management
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '25

03 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38820 Bug ID: 38820 Summary: On demand hold delivery management Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com One of my libraries is interested in starting an on demand delivery service for holds (think food delivery apps) where the patron can choose to have their holds delivered rather than picking them up. Bug 29089 proposes that the patron be able to choose delivery at the point of placing the hold but that gets awkward when holds are coming from multiple branches and there's no way to tell when they'll all arrive. Maybe the patron wanted it delivered when they placed the hold but change their mind by the time it finally gets to the library. The curbside pickups module has almost the exact functionality needed to make this work well and avoid the aforementioned awkwardness, since the patron isn't scheduling the pickup (or delivery) until the hold is there and waiting. The only workflow change from pickups to deliveries would be that an item would move from staged to the 'delivery vehicle', rather than from staged to the 'patron is outside'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 3492] Move hold fee setting into circulation rules
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '25

03 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3492 Hannah Dunne-Howrie <hdunne-howrie(a)westminster.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hdunne-howrie(a)westminster.g | |ov.uk --- Comment #15 from Hannah Dunne-Howrie <hdunne-howrie(a)westminster.gov.uk> --- We would also like to see the ability to set a hold fee based on item type instead of patron category. For example, we don't charge for CD holds but we have no way to disable this so we have to mainly waive the charge for patrons when they ask us to do this. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 25323] New: Patrons can act as their own guarantor
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '25

03 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25323 Bug ID: 25323 Summary: Patrons can act as their own guarantor 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: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When searching for a patron to act as a guarantor, if the guarantee's record is returned it can be selected, therefore becoming his/her's own guarantor. This makes no sense. To reproduce: 1) Create two users, a parent and a child both with the same surname (for example Parent Smith and Child Smith) 2) Edit the child record and under the Guarantor information, use the "Search to add" button to search for a guarantor. 3) Search for Smith. Both Parent Smith and Child Smith will be listed in the results. 4) Select Child Smith and save the user record. Child Smith is now the guarantor for Child Smith. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 14907] Item search: Call Numbers in Item search results are ordered alphabetically
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '25

03 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907 --- Comment #24 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Heather from comment #23) > (In reply to Marcel de Rooy from comment #15) > > (In reply to PTFS Europe Sandboxes from comment #14) > > > barcode TEST1 callnumnber D1015.B4 1965 > > > barcode TEST2 callnumnber D102.D3 1930 > > > barcode TEST3 callnumnber D101.2.A8 1951 > > > 8 - order is TEST3,TEST2,TEST1 (or reversed depending on sort direction) > > > > > > Signed-off-by: Heather Hernandez <flyingendpaper(a)gmail.com> > > > > While reading comment4 of Heather, I am not sure what the LCC order now > > should be. IIUC the order should be 1-11-2. But this test marks 101-102-1015 > > as correct while I expected 101-1015-102 ? > > > > Please clarify. > > > > PS The general scheme sorts also like 1-11-2 for our callnumbers like 10 A > > 1, 100 A 2 or 1000 A 3. Which is a pain since we started. > > The correct order for LC Classification of the above example is: > TEST3, TEST2, TEST1 > i.e., D101.2.A8 1951, D102.D3 1930, D1015.B4 1965 > i.e.: > D One hundred and one point 2 > D One hundred and two > D One thousand and fifteen > > One would expect "101-1015-102" if these were decimal numbers in the initial > alphanumeric sequence (i.e., "D point one zero one, D point one zero one > five, D point one zero two), but they are whole numbers. > > So that's why I signed off on the bug--it was sorting these LC Class numbers > correctly, as whole numbers. I.e., an alphanumeric sequence of a letter > plus whole numbers. > > With Library of Congress Classification, the initial alphanumeric sequence > contains whole numbers. The following alphanumeric sequence(s) contain > decimal numbers. I.e., D1015.B4 1965 is "D One thousand fifteen B four > tenths One thousand nine hundred sixty five." In USian English, that is.:) > > Does that help? > --h2 Thanks Heather, it does :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38787] New: "Paid for?" message in item info lists patrons who did not pay for item
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38787 Bug ID: 38787 Summary: "Paid for?" message in item info lists patrons who did not pay for item Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com Depends on: 19919 To confirm: - have an item checked out - mark it lost, generating a fee on the patron account - check it in, generating a full refund on the patron account - mark the item lost again (it doesn't matter if it's checked out to another patron or not) - go to moredetail.pl, see your item shows "Paid for: [your patron]" Bug 19919 introduced logic to determine whether or not an item had previously been lost and then paid for. It will show the "Paid for" message and a patron's name and barcode if: - the item is currently lost - there is an accountlines entry linked to that item number with the following qualities: -- accountlines.debit_type_code = LOST -- accountlines.status != 'RETURNED' -- accountlines.amountoutstanding = 0 So, show this if the item has an associated charge that reached $0 via means other than a return. But when a lost item gets checked in we update that status to "FOUND" and anyway the debit for a lost item that gets paid off has a NULL status, so it won't be found by looking for status != "FOUND". Would it work to look for lines with debit_type_code='LOST', amoundoutstanding=0, and status IS NULL? I don't have a good enough handle on accountlines statuses to be sure. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19919 [Bug 19919] Writing off a Lost Item Fee marks as "Paid for by patron" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 35402] Update the OPAC and staff interface to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |38816 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38816 [Bug 38816] Vue sidebars in ERM and Preservation are italic after Bootstrap 5 update -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38816] New: Vue sidebars in ERM and Preservation are italic after Bootstrap 5 update
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38816 Bug ID: 38816 Summary: Vue sidebars in ERM and Preservation are italic after Bootstrap 5 update Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bootstrap 5 added italics to .breadcrumb-item. Vue generates the sidebar menu with that class, so it becomes italic. This is a mismatch to non-vue modules. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 37460] New: Skip Issues Seems to Not Work for Subscriptions Using the Publication Date Parts
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37460 Bug ID: 37460 Summary: Skip Issues Seems to Not Work for Subscriptions Using the Publication Date Parts Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 169512 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169512&action=e… pattern With bug 32392, a user can receive an issue and then skip the next issue or multiple issues. However, this does not seem to be working when using the bug [35646] Allows using the publication date parts for serial numbering. It will not skip an issue as instructed. Using this skip issues option for other numbering patterns does work, such as a simple Volume Number Issue. Attaching my Pattern for more clarification -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 14907] Item search: Call Numbers in Item search results are ordered alphabetically
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907 --- Comment #23 from Heather <flyingendpaper(a)gmail.com> --- (In reply to Marcel de Rooy from comment #15) > (In reply to PTFS Europe Sandboxes from comment #14) > > barcode TEST1 callnumnber D1015.B4 1965 > > barcode TEST2 callnumnber D102.D3 1930 > > barcode TEST3 callnumnber D101.2.A8 1951 > > 8 - order is TEST3,TEST2,TEST1 (or reversed depending on sort direction) > > > > Signed-off-by: Heather Hernandez <flyingendpaper(a)gmail.com> > > While reading comment4 of Heather, I am not sure what the LCC order now > should be. IIUC the order should be 1-11-2. But this test marks 101-102-1015 > as correct while I expected 101-1015-102 ? > > Please clarify. > > PS The general scheme sorts also like 1-11-2 for our callnumbers like 10 A > 1, 100 A 2 or 1000 A 3. Which is a pain since we started. The correct order for LC Classification of the above example is: TEST3, TEST2, TEST1 i.e., D101.2.A8 1951, D102.D3 1930, D1015.B4 1965 i.e.: D One hundred and one point 2 D One hundred and two D One thousand and fifteen One would expect "101-1015-102" if these were decimal numbers in the initial alphanumeric sequence (i.e., "D point one zero one, D point one zero one five, D point one zero two), but they are whole numbers. So that's why I signed off on the bug--it was sorting these LC Class numbers correctly, as whole numbers. I.e., an alphanumeric sequence of a letter plus whole numbers. With Library of Congress Classification, the initial alphanumeric sequence contains whole numbers. The following alphanumeric sequence(s) contain decimal numbers. I.e., D1015.B4 1965 is "D One thousand fifteen B four tenths One thousand nine hundred sixty five." In USian English, that is.:) Does that help? --h2 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11530] Recalculating a book's total issue count from items.issues or statistics-table with update_totalissues.pl ignores deleted_items.
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11530 --- Comment #5 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- This is a nice fix that I know many libraries will appreciate. -- You are receiving this mail because: You are watching all bug changes.

1 0