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

[Bug 20203] New: Add info about contributing to koha-community.org/documentation/
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20203 Bug ID: 20203 Summary: Add info about contributing to koha-community.org/documentation/ Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Websites, Mailing Lists, etc Assignee: wizzyrea(a)gmail.com Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org It might be nice if the page at https://koha-community.org/documentation/ said something about how to contribute to the documentation, or linked to such info published elsewhere. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 34676] New: Add an option for holds queue to only map unassigned requests to items
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34676 Bug ID: 34676 Summary: Add an option for holds queue to only map unassigned requests to items 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When using the real time holds queue new requests rebuild the entire holds queue - this can mean libraries go to find a book on a shelf, only to find the queue has changed and another item has filled the request in the meantime. Similarly, when not using the real time holds queue, some libraries will limit the cron to running once a day to avoid ever changing holds lists. It would be nice to have an option for both methods that would limit the queue to filling new holds without deleting the current queue -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 23015] New: Create a "GetPickupLocation" endpoint for the ILS-DI Service
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23015 Bug ID: 23015 Summary: Create a "GetPickupLocation" endpoint for the ILS-DI Service Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- That endpoint may take 2 parameters: - a borrowernumber - and a biblio or item number And it would return a list of available pickup location given a user and a biblio or item. On success would return the following example : <?xml version="1.0" encoding="UTF-8"?> <pickup_locations> <pickup_location> <pickup_location_label>First library</pickup_location_label> <pickup_location_id>1</pickup_location_id> </pickup_location> <pickup_location> <pickup_location_label>Second library</pickup_location_label> <pickup_location_id>2</pickup_location_id> </pickup_location> </pickup_locations> On error : - PatronNotFound in case borrowernumber is not found - RecordNotFound in case Biblio doesn't exist - ItemNotFound in case item doesn't exist -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 35391] New: In new order empty first item type is selected
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '24

03 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35391 Bug ID: 35391 Summary: In new order empty first item type is selected Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When creating a new order from suggestion or new empty record, the first item type is selected. There should be an empty value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 25990] New: `WhenLostChargeReplacementFee` and `WhenLostForgiveFine` preferences should be moved into circulation rules to be consistent with `RefundLostOnReturn` rules
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '24

03 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25990 Bug ID: 25990 Summary: `WhenLostChargeReplacementFee` and `WhenLostForgiveFine` preferences should be moved into circulation rules to be consistent with `RefundLostOnReturn` rules 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently there is an inconsistency with the level at which `WhenLostChargeReplacementFee` and `WhenLostForgiveFine` can be set when compared to the complimentary `RefundLostOnReturn` rule. For consortial installations, all these rules should apply at the same level, be that system or branch level.. I propose to move the two 'system' level preferences into 'branch' level by migrating them into the circulation rules area. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 35591] New: bulkmarcimport.pl overwrites data if controlnumber eq authid
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '24

03 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35591 Bug ID: 35591 Summary: bulkmarcimport.pl overwrites data if controlnumber eq authid Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org We had a lot of auth_header (~700.000). Then we decided to import a lot more (10.000.000). We used --update together with a match-rule (based on 024) to prevent duplicates. Which all worked well. Until... We discovered that ~30k of our old auths where overwritten with "random" data (some other auths). What used to be "Graz" was now "Centro Editoriale Valtortiano". After a bit of panic we were able to restore our old auths from a backup. But what happend? The problem is that eg "Graz" had authid=777317. But "Valtortiano" has 001=00777317X. If you squint a bit (and ignore the leading 0s and the X at the end) that's the same number! And it seems that C4::AuthoritiesMarc::GuessAuthId($record) returns the value of 001, which somehow causes the confusion. I'm not entirely sure yet, where the X is stripped, but the effect is that auth-record 777317 is overwritten. An easy fix would be to add a new command line param to bulkmarcimport to either disable the call to GuessAuthId (which keeps with backwards compat, but makes it easy for other people to also run into this problem); or to only call GuessAuthId if the new param is set (saver, but changes behaviour) If you agree that this is a problem, I can prepare a patch. If we did something stupid, please enlighten us! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 33604] New: Show both article_title and title in ILL module and OPAC
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33604 Bug ID: 33604 Summary: Show both article_title and title in ILL module and OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: pedro.amorim(a)ptfs-europe.com The ILL module will sometimes show the article title as title when one exists. This has led to quite some confusion. We should always show both, the article title and the title of the item the article is from (source). One place this is missing is the detail pages of ILL requests in OPAC and staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 36425] New: koha-run-backups deletes old backup files based on number of hours since modification - not date of modification
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36425 Bug ID: 36425 Summary: koha-run-backups deletes old backup files based on number of hours since modification - not date of modification Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Our Koha partner libraries are all configured to pass koha-run-backups with the --days 2 parameter. Therefore, theoretically, any old backup files modified on a date two days ago will be deleted. However, since bug 30627 was pushed to 23.05.x and 23.11.x, we have noticed for our larger Koha instances (which run koha-run-backups for a long time each morning) the .tar.gz file from two days ago is often not deleted. This is because the .tar.gz file is not exactly 48+ hours old when the koha-run-backups runs the find command to identify old files to remove: https://github.com/Koha-Community/Koha/blob/286fc8e9833d55d694955849e4050d2… Often the .tar.gz file will be 47.9 hours old and therefore not deleted. The find command should switch to checking the modification date, to ensure all files created X days ago are deleted. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 25439] New: [Omnibus] Prepare Koha to ElasticSearch 7 - ES7
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25439 Bug ID: 25439 Summary: [Omnibus] Prepare Koha to ElasticSearch 7 - ES7 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net ES6 will be end of life when the version 8 will come out[1]. there is no alpha of version 8 so we have at least half a year[2] before that happens. [1] https://www.elastic.co/support/eol [2] https://discuss.elastic.co/t/elasticsearch-8-release-date/202759/2 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 26274] New: Expose cash register cashup summaries via an API route.
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26274 Bug ID: 26274 Summary: Expose cash register cashup summaries via an API route. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com Depends on: 26172 Blocks: 26272, 26273 It would be useful to expose cashup summaries via an API endpoint to allow for displaying this data in various area's around Koha on demand. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26172 [Bug 26172] Add a cashup summary view https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26272 [Bug 26272] Allow cashup summaries to be displayed from the library summary page https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26273 [Bug 26273] Expose cashup summary historyfor a cash register -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 49