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

[Bug 29979] New: Remove 'Menu' from top of a printed report
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29979 Bug ID: 29979 Summary: Remove 'Menu' from top of a printed report Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When looking at the print preview of a saved report, there is a 'burger menu' icon and Menu label showing at the top of results. It would be nice to remove this from the print view. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 29973] New: SQL syntax error in Cataloging when accessing pages "Advanced editor" and "New record"
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29973 Bug ID: 29973 Summary: SQL syntax error in Cataloging when accessing pages "Advanced editor" and "New record" Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dhodgins(a)coloradovirtuallibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Recently upgraded to 21.11.01 and the "Advanced editor" page https://chnc-koha-intra.domain/cgi-bin/koha/cataloguing/editor.pl now returns Error 500. The intranet-error.log reports the following SQL syntax error: AH01215: {UNKNOWN}: DBI Exception: DBD::mysql::db selectall_arrayref failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ',servername' at line 3 at /usr/share/perl5/DBIx/Class/Schema.pm line 1118.: /usr/share/koha/intranet/cgi-bin/cataloguing/editor.pl AH01215: \tDBIx::Class::Schema::throw_exception(Koha::Schema=HASH(0x561f387caed8), "DBI Exception: DBD::mysql::db selectall_arrayref failed: You "...) called at /usr/share/perl5/DBIx/Class/Storage.pm line 113: /usr/share/koha/intranet/cgi-bin/cataloguing/editor.pl AH01215: \tDBIx::Class::Storage::throw_exception(DBIx::Class::Storage::DBI::mysql=HASH(0x561f389880d8), "DBI Exception: DBD::mysql::db selectall_arrayref failed: You "...) called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1501: /usr/share/koha/intranet/cgi-bin/cataloguing/editor.pl AH01215: \tDBIx::Class::Storage::DBI::__ANON__("DBD::mysql::db selectall_arrayref failed: You have an error i"..., DBI::db=HASH(0x561f3a9a8f90), undef) called at /usr/share/koha/intranet/cgi-bin/cataloguing/editor.pl line 80: /usr/share/koha/intranet/cgi-bin/cataloguing/editor.pl AH01215: : /usr/share/koha/intranet/cgi-bin/cataloguing/editor.pl Koha 21.11.01.000 MySQL 8.0.27 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 33375] New: Advanced editor crashes when using MySQL 8 due to reserved rank keyword
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33375 Bug ID: 33375 Summary: Advanced editor crashes when using MySQL 8 due to reserved rank keyword Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P1 - high Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 17515 added "rank" to the ORDER BY without quoting it. Since it's a reserved keyword in MySQL 8, this causes a syntax error which causes the advanced editor to throw a fatal 500 error. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 29964] New: SMTP server list not populating
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29964 Bug ID: 29964 Summary: SMTP server list not populating Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: Linux Status: NEW Severity: critical Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: fv(a)spots.school QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 129917 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=129917&action=e… screenshot of SMTP server page After adding an SMTP server to Koha it does not show in the list. Therefore it cannot be chosen, edited, etc. (Mac Chromium-based browser) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 29950] New: Staff client Suggest for purchase clears item type, quantity, library and reason if bib exists
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29950 Bug ID: 29950 Summary: Staff client Suggest for purchase clears item type, quantity, library and reason if bib exists 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: amy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This bug is related to bug 29419; where 29419 fixed this issue in the OPAC, it was not corrected in the staff client. When a similar item is detected and suggested, the staff user can submit the form without replacing the item type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 29945] New: Item Level Hold Library Location
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29945 Bug ID: 29945 Summary: Item Level Hold Library Location Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: daniel.gaghan(a)pueblolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Item level holds ignores selected hold pick up location and reverts to library location of staff who placed the hold. Method of replicating this bug. 1. Set Staff Location to Library B 2. Place a item level hold item for a user to pick material at Library A 3. After hold has been placed review pick up location. Results: Library Pick up location will be Library B, not Library A. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 29937] New: class close, close the full windows
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29937 Bug ID: 29937 Summary: class close, close the full windows Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org Good morning we have found something it could be an issue or not.. ;) https://github.com/Koha-Community/Koha/blob/master/koha-tmpl/opac-tmpl/boot… $(document).ready(function(){ $(".close").click(function(){ window.close(); }); the issue is basically that we assign a class $('.close') to do window.close() We do have that handler bound to the class close, which can be considered a bit loose in scope and lead to clashes. We have added a js on mainuserblock with .close, and when it clicks, close the full browser tab ;), of course we can change the class, but I think it is something to consider if change that code ;) cheers -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 29902] New: While upgrading all empty deleteditems.datelastborrowed turned deleteditems.timestamp to date of upgrade
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29902 Bug ID: 29902 Summary: While upgrading all empty deleteditems.datelastborrowed turned deleteditems.timestamp to date of upgrade Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: edv(a)hoernergruppe.de QA Contact: testopia(a)bugs.koha-community.org After upgrading from 19.06 to latest we recognized in our deleted items report a wrong amount of deleted items for 2021. Digging onto the problem we found, that every dataset in deleteditems with an empty deleteditems.datelastborrowed field, caused a deleteditems.timestamp set to the actual date by overwriting the former content of the field. We got the former content back by importing additionally the old database so called "koha_library_old" and the follwing SQL request (2021-12-01 was the date of our upgrade) UPDATE koha_library.deleteditems, koha_library_old.deleteditems SET koha_library.deleteditems.timestamp = koha_library_old.deleteditems.timestamp WHERE koha_library.deleteditems.barcode = koha_library_old.deleteditems.barcode AND koha_library.deleteditems.timestamp LIKE '2021-12-01%'; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 22833] New: Don't let users cancel holds connected with ILLs
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22833 Bug ID: 22833 Summary: Don't let users cancel holds connected with ILLs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Target Milestone: --- In the Swedish (Libris) ILL module, when a new ILL request is created, a record and an item (with a specific ILL itemtype) are also created. And a hold is created between the local patron that is waiting for the ILL and the local ILL item. This means that the ILL shows up as a regular hold when the patron logs into the OPAC. That in it self is OK, but the problematic thing is that patrons can cancel the holds connected with the ILL (maybe thinking that they are then also canceling the ILL request). Libraries would like to stop patrons from doing this. A couple of options come to mind: 1. Add a syspref that can take a list of itemtypes that should not be cancel'able by the patron in the OPAC 2. Add a boolean field like itetypes.let_patrons_cancel_holds_in_opac which defaults to 1 for existing itemtypes, but can be set to 0 to achieve the desired effect. 1 is more unobtrusive, 2 is probably cleaner in the long run? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 29851] New: Prevent cancellation by patron of certain holds
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29851 Bug ID: 29851 Summary: Prevent cancellation by patron of certain holds 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We have partner libraries using the ILL module with a backend that generates holds. If the patron cancels the hold via the OPAC, it fouls up the ILL workflow. It'd be great to have a method to prevent these holds from being cancelled by the patron (without preventing patron-instigated cancellation of *all* holds). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3