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

[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

[Bug 38814] New: Add helper information to circ rules of system prefs that can impact refund behavior
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38814 Bug ID: 38814 Summary: Add helper information to circ rules of system prefs that can impact refund behavior Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com System preferences like NoRefundOnLostReturnedItemsAge and the new NoRefundOnLostFinesPaidAge can create exceptions to circ rule refund settings. It would be nice if the Default lost item fee refund on return policy section of the circulation rules provided either a hint that the preferences may impact refund behavior, or even expose the values in those preferences, as the circ rules table and default holds policy tables do. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 26024] New: Purge undone of zebraqueue in cleanup_database.pl
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26024 Bug ID: 26024 Summary: Purge undone of zebraqueue in cleanup_database.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com Purge script misc/cronjobs/cleanup_database.pl with --zebraqueue DAYS will delete entries from zebraqueue table with done=1 We now start to use Elasticsearch only so entries of zebraqueue with done=0 stay in database. I propose we purge all entries in cleanup_database.pl. Even with zebra, if indexing does not occur after several days (30 by default), there is a problem and one need a full rebuild. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 37738] New: Framework update accessibility for existing installations
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37738 Bug ID: 37738 Summary: Framework update accessibility for existing installations Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice if updated frameworks were available for download in some way. As frameworks are periodically updated in Koha to stay up-to-date with Library of Congress changes. it becomes difficult for existing installations to know about/receive those updates. While it is possible for existing installations to monitor bugs and see what the changes are, they don't receive those updates in the frameworks with an upgrade. This requires a library to seek out the bugs and do manual updates. There may be a number of ways to alert a library that updates are available and/or provide a download of the new framework. Perhaps there could be an alert in Administration that says updates are available, with a link to download the new framework from somewhere. This way a library can choose whether to overlay or manually update a framework as needed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 38811] New: Clarify "Hide in OPAC" in itemtype configuration
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38811 Bug ID: 38811 Summary: Clarify "Hide in OPAC" in itemtype configuration Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de The manual states: Hide in OPAC: for items that you are suppressing from the OPAC, you can hide their item type from being searched in the OPAC. I think it's not quite correct: you can still search for it, but the option hides the item type from the tab in the advanced search page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #141 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Hi, as far as I understand, Comment 126 is about Comment 125 about plan for no_return, which is what I introduced in the follow up, did I miss something ? :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32168] New: Editing date/datetime fields without the dateaccessioned.pl plugin can cause errors
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32168 Bug ID: 32168 Summary: Editing date/datetime fields without the dateaccessioned.pl plugin can cause errors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When editing items that are date or datetime formatted without the dateaccessioned cataloging plugin it is quite easy to cause an error. To recreate: 1. Make sure some 952 field with dates (datelastseen, dateaccessioned ) are visible in the editor but make sure the dateaccessiond plugin is turned off. 2. Set the date format system preference to mm/dd/yyyy 3. Edit an item and attempt to edit one of the date fields to something in the correct dateformat, like 11/11/2018. 4. You get an error as Koha is expecting the SQL date type format of YYYY-MM-DD. I'm not sure how to best solve this. My first thought is that we should require the dateaccessioned.pl plugin on date fields. Or we could add a hint about format? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5