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

[Bug 39275] New: Merging records can destroy records if page has not fully loaded
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '25

14 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39275 Bug ID: 39275 Summary: Merging records can destroy records if page has not fully loaded Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We just had a case where a lot of records where merged while the instance was slowed down significantly (crawlers) and the records ended up emptied out completely. As far as we can tell, this is what happened: * Select 2 records to merge from catalog or cataloguing search * Select "winner" record * On the next page, the second column with the "winner" is loaded a little after the rest of the page -> When you merge before it's loaded, the record is emptied out -> Wait until the page is fully loaded, the record will be ok. Maybe we could lock the "Merge records" button, until the page is fully loaded? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 17815] New: Problems with search for dateaccessioned
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '25

14 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17815 Bug ID: 17815 Summary: Problems with search for dateaccessioned Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Tested this as described in bug 14861: Search from advanced search by accession date: 2011-09-01 - 2011-09-30 9461 results Searched with SQL: select distinct biblionumber from items where dateaccessioned between '2011-09-01' and '2011-09-30' 805 results The date range search doesn't seem to work right. The search for a single date appears to work correctly. It's also possible to truncate dates using *. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 27945] New: Limit the number of article requests per day per patron category
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '25

14 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27945 Bug ID: 27945 Summary: Limit the number of article requests per day per patron category 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We propose adding an "Article Request Limit" field to the patron category configuration. "Allow __ article requests per day" This limit would be enforced by querying the existing article requests in the database that have been placed during the day and allowing the patron to proceed or deny the request. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 172

[Bug 37784] Patron password hash can be fetched using report dictionary
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '25

14 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37784 --- Comment #34 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Pushed for 25.05! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37784] Patron password hash can be fetched using report dictionary
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '25

14 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37784 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)|25.05.01,24.11.03,24.05.08, |25.05.01,25.05.00,24.11.03, released in|23.11.13,22.11.25 |24.05.08,23.11.13,22.11.25 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31165] "Public note" field in course reserve should restrict HTML usage
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '25

14 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31165 --- Comment #26 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Pushed for 25.05! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31165] "Public note" field in course reserve should restrict HTML usage
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '25

14 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31165 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)|25.05.01,24.11.03,24.05.08, |25.05.01,25.05.00,24.11.03, released in|23.11.13,22.11.25 |24.05.08,23.11.13,22.11.25 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37784] Patron password hash can be fetched using report dictionary
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '25

14 Apr '25

1 0

[Bug 31165] "Public note" field in course reserve should restrict HTML usage
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '25

14 Apr '25

1 0

[Bug 39621] New: invalid marcxml records can be imported
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '25

14 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39621 Bug ID: 39621 Summary: invalid marcxml records can be imported Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: furtadojaden(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 180891 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180891&action=e… Invalid marcxml that can be staged for imports but which crashes when attempted to be imported into a catalog Hello, This is my first bug report for any OSS. Sorry for any mistakes that I might make given my inexperience :) Issue: The issue is that it is possible to import invalid marcxml files in Koha, which then causes an import of this staged record into the catalog to fail. I have attached an example marcxml record for reference, that can be staged in koha, but which is invlaid. Below is the snippet that causes the issue, i.e. notice the tags 001 and <subfield code="p"> M18325</subfield>, have a space before the data M18325. --------------------- <?xml version="1.0" ?> <collection xmlns="http://www.loc.gov/MARC21/slim"> <record> <leader>00000nam a2200000 a 4500</leader> <controlfield tag="001"> M18325</controlfield> ... ... <datafield tag="952" ind1=" " ind2=" "> ... ... <subfield code="p"> M18325</subfield> ... ... </datafield> ... ... ---------------------- Proposed fix: When checking the validity of an imported XML file, a check needs to be added to ensure that this case of trailing and leading spaces in record data fields is handled at the time of staging XML records. I would also suggest that errors should be logged/shown on the frontend, when an import into catalog fails, since it took me a while to dig through a batch of over 5000 records before I could find the cause of the crash. I went through worker and koha error logs but found nothing. Not sure if I was looking in the wrong place. P.S.: I see that there was a previous discussion: Bug 35104 - We should warn when attempting to save MARC records that contain characters invalid in XML However, I am not sure if this bug falls under that or not. Thanks for the help. Regards, Jaden -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4