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

[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

[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 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gmcharlt(a)gmail.com |nick(a)bywatersolutions.com CC| |lucas(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38815] New: Optionally block local login of accounts set for SSO
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38815 Bug ID: 38815 Summary: Optionally block local login of accounts set for SSO Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Bug 18506 added the ability to completely prevent local login (login using the koha username and password) when using SSO, but many libraries using SSO find it necessary to allow local login for some users or situations -- community borrowers at an academic library, support vendors who lack SSO credentials, etc. If both SSO and local login must be allowed, libraries want to ensure that any given account can only log in one way -- if your account can authenticate via SSO, you should not be able to authenticate via local login. Libraries enforce this by setting NULL passwords in Koha on accounts using SSO, but at the very least any superlibrarian is able to change that password. It would be helpful to be able to flag an account as "SSO only" and thereby force Koha to null the password and keep it null, hiding the Change Password button and the password field from patron edit. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0