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

[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

[Bug 14959] Support for Library Communications Framework (LCF)
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14959 Chris Rowlands <chris.rowlands6(a)nhs.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris.rowlands6(a)nhs.net -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36281] New: Restricted info is displayed even if item is not restricted (OPAC details)
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36281 Bug ID: 36281 Summary: Restricted info is displayed even if item is not restricted (OPAC details) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org If you define a description for restricted = 0 : In OPAC details, restricted info is displayed even if item is not restricted (value 0). -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 36489] New: Making fields 386$m and 386$a visible for the users
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36489 Bug ID: 36489 Summary: Making fields 386$m and 386$a visible for the users 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: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 164250 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=164250&action=e… Fields 385$m and 385$a. Could fields 386$m - Demographic group and 386$a - Creator/contributor be shown on the page: cgi-bin/koha/catalogue/detail.pl? as the fields 385$m and 385$a already are shown? The information in the 386 - Creator/Contributor Characteristics -field is currently not visible in any screen other than the MARC-record, but it is useful information for the users. Fields 386$m and 386$a would look on the catalogue-page for example like this: Creator/Contributor Characteristics: Occupation/field of activity: singer-songwriter I attached a picture of how fields 385$m and 385$a are shown on that same page: cgi-bin/koha/catalogue/detail.pl? That is how we would like fields 386$m and 386$a to be shown. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 36450] New: SIP2: Login ignores branchcode in optional CP field
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36450 Bug ID: 36450 Summary: SIP2: Login ignores branchcode in optional CP field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org The spec allows passing a branchcode in the 93 request. Koha just ignores it in MsgType::login_core. Even an unexisting branch can be passed. 9300CNTermNRD02|COtest1234|CPWRONG| 941 The WRONG branch does not exist! Should Koha compare the passed branch with the one recorded in the config? What if there would be no branch in the config? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 30627] New: koha-run-backups may delete the backup files after work done
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30627 Bug ID: 30627 Summary: koha-run-backups may delete the backup files after work done Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: mengu(a)devinim.com.tr QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz I've a doubt about the koha-run-backups script that it deletes its backup files if the backup destination directory is empty. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 23943] New: koha-run-backups --days is misleading
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23943 Bug ID: 23943 Summary: koha-run-backups --days is misleading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net The documentation for the --days option to koha-run-backups says: --days: the number of days to keep backups around for (default: 2) Sometimes I do the following: 1. Rename a backupfile, e.g. from instance-2019-10-22.sql.gz to instance-2019-10-22-1230.sql.gz 2. Run koha-dump to create a new instance-2019-10-22.sql.gz This reveals that --days does not really care about days at all, just the number of files in the backup dir. This means that if I have adjusted the cronjob to keep backups for 14 days, after the next time it runs, I actually have backups for 13 days. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 36479] New: Z39.50 responder does not support element set / composition "B"
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '24

02 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36479 Bug ID: 36479 Summary: Z39.50 responder does not support element set / composition "B" Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The Z39.50 responder currently has a hard-coded expectation that the element set / composition provided by the client is either blank or "F". It would be handy if it also supported "B" (brief) for backwards compatibility, since the default Zebra configuration also supports "B" (as effective a synonym for "F" (full)). Doing this would avoid a compatibility issue when switching from zebrasrv as the Z39.50 server to the Z39.50 responder for clients that happen to set the element set to "B". In particular, we've seen at least one case where the EBSCO/EDS item availability checker was configured to request "B". The error message associated with this is returning error 239: Unsupported syntax/composition 1.2.840.10003.5.10/B Koha::Z3950Responder::Session::log_error /usr/share/koha/lib/Koha/Z3950Responder/Session.pm (341) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1