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

[Bug 35966] New: Koha should not strip limits from SQL queries
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '24

05 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35966 Bug ID: 35966 Summary: Koha should not strip limits from SQL queries Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: nick(a)bywatersolutions.com Koha removes LIMIT from queries in some cases, which can cause incorrect results. For example, consider this report to give the 5 oldest items in the collection, sorted into callnumber order: SELECT * FROM ( SELECT itemnumber, cn_sort, dateaccessioned FROM items ORDER BY dateaccessioned LIMIT 5 ) foo ORDER BY cn_sort That query should get all the items, put them in dateaccessioned order, drop all but the first 5, and then put those 5 in cn_sort order. But Koha processes that by dropping the LIMIT and then re-applying it at the end: SELECT * FROM ( SELECT itemnumber, cn_sort, dateaccessioned FROM items ORDER BY dateaccessioned ) foo ORDER BY cn_sort LIMIT 5 That makes the query get all the items, put them in dateaccessioned order, then put them in cn_sort order, then drop all but the first 5. It changes the query hugely. It only does this in queries without a WHERE, so that first query can be made to work by editing it to: SELECT * FROM ( SELECT itemnumber, cn_sort, dateaccessioned FROM items ORDER BY dateaccessioned LIMIT 5 ) foo WHERE 1=1 ORDER BY cn_sort -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 35995] New: Real time holds queue jobs for the same record should run in serial, never parallel
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '24

05 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35995 Bug ID: 35995 Summary: Real time holds queue jobs for the same record should run in serial, never parallel Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com As described in bug 34596 there are times when multiple jobs to rebuild the holds queue for a single job will run where the first job as the last to execute ( or at least the last to finish ). We need to force these jobs to run in serial, and only the newest job for a given record *needs* to run, older jobs can exit early. To this end, I propose a "holds queue job lock" table. The table will have rows for the record id, and the timestamp of job initiation. When a job begins processing, it will attempt to insert a row into this table. If that insert succeeds, the job will process then remove the lock from the table. If the insert fails, it means another job has already written a lock. The blocked job can then read the row in the table. If the queued time for the job that got the lock is newer than the time queued for the blocked job that is checking it, that job can exit as it is obsolete. If the queue time for the job that got the lock is older than the time queue for the blocked job, that job needs to reinsert itself into the job queue before exiting so it may try again in the future. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 5374] Update date/time last transaction (MARC 005) when saving biblio record
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '24

05 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5374 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=35993 -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 23033] New: C4::Items::AddItemBatchFromMarc does not queue bib record for indexing
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '24

05 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23033 Bug ID: 23033 Summary: C4::Items::AddItemBatchFromMarc does not queue bib record for indexing Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul(a)flo.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Callers of C4::Items::AddItemBatchFromMarc must call ModZebra (directly or indirectly) afterwards, which strikes me as wrong. AddItemBatchFromMarc used to call C4::Biblio::ModBiblioMarc, which calls C4::Items::ModZebra[*] but the call to ModBiblioMarc was commented out in commit 3584c442 (2010-09-03 12:16:52 +0200, see bug #5579) and the comment was never removed. The only code in Koha 18.11 that calls AddItemBatchFromMarc is in migration_tools/bulkmarcimport.pl, which dutifully calls MobBiblioMarc once after each call to AddItemBatchFromMarc -- even(!) if AddItemBatchFromMarc fails, which seems weird but I don't fully understand the code. We could add a call to ModZebra in AddItemBatchFromMarc but I assume it would be better to reinstate the call to ModBiblioMarc. I'll attach a patch shortly. [*] C4::Items gets ModZebra from C4::Biblio, which implements and exports it, so my will also change this to a call to C4::Biblio::ModZebra. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24710] New: patron-title.inc should have seperate span classes for firstname, othername, surname
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '24

04 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24710 Bug ID: 24710 Summary: patron-title.inc should have seperate span classes for firstname, othername, surname 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries would prefer to be able to customize how the name is displayed in the patron details. If these included <span> classes we could easily move/hide/reorder bits we don;t want. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 34699] New: add a notforloan_on column in items table to store the date of last notforloan change
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '24

02 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34699 Bug ID: 34699 Summary: add a notforloan_on column in items table to store the date of last notforloan change 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It could be useful to add a notforloan_on column in items table to store the date of last notforloan change. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 14180] Make "Always show checkouts immediately" a global setting
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '24

02 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14180 Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply CC| |andrewfh(a)dubcolib.org --- Comment #29 from Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> --- This looks like maybe it should have been set to Signed Off when Kelly tested it 1/26. As of today, the patch doesn't apply. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5920] Optionally remove HTML from downloaded reports
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '24

02 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5920 --- Comment #21 from George Williams (NEKLS) <george(a)nekls.org> --- How about switching the "Download" drop-down from a list of options to a checkbox drop-down that allows the user to specify the format and whether or not HTML is stripped from the output. That would be the most granular way of going about it. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 34950] New: ILS DI Availability is not accurate for items on holds shelf or in transit
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '24

02 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34950 Bug ID: 34950 Summary: ILS DI Availability is not accurate for items on holds shelf or in transit Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org The ILS DI web service is a handy way for a third party system, such as a mobile app, to check for the availability of items for a given bib record in your system. If you make a call like https://{OPAC_DOMAIN}/cgi-bin/koha/ilsdi.pl?service=GetAvailability&id={BIB_ID}&id_type=bib the response shows the availabilitystatus of items that are on the holds shelf or in transit as 'available'. While these items may be technically available to be checked out, it's not ideal to send the message to patrons that these items are available because they may show up at the library to get the book and be disappointed :( It would be more accurate and informative if ILS DI could show availabilitystatus 'not available' with availabilitymsg indicating 'on hold shelf' or 'in transit' for these items. Alternatively it would be nice to have a REST API endpoint for item availability to easily get this info to third party developers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 35510] New: Non-patron guarantor missing from CollapseFieldsPatronAddForm options
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '24

02 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35510 Bug ID: 35510 Summary: Non-patron guarantor missing from CollapseFieldsPatronAddForm options Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 25654 The CollapseFieldsPatronAddForm system preference controls whether sections of the patron add/edit form are collapsed by default. Since Bug 25654 we have an additional section for Non-patron guarantor. This should be added to the list of CollapseFieldsPatronAddForm options. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25654 [Bug 25654] Make the contact and non-patron guarantor sections separate on patron entry form -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16