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

[Bug 5229] OPACItemsResultsDisplay preference must be removed
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '21

19 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5229 --- Comment #15 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Created attachment 127822 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=127822&action=e… Bug 5229: Remove from searching.pref Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5229] OPACItemsResultsDisplay preference must be removed
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '21

19 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5229 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #127689|0 |1 is obsolete| | Attachment #127690|0 |1 is obsolete| | --- Comment #14 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Created attachment 127821 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=127821&action=e… Bug 5229: Remove system preference 'OPACItemsResultsDisplay' We dropped it on bug 12561 when removing the non-XSLT view. This feature has never been implemented for XSLT views and the pref must then be removed. Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5229] OPACItemsResultsDisplay preference must be removed
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '21

19 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5229 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|BLOCKED |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5229] OPACItemsResultsDisplay preference must be removed
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '21

19 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5229 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy(a)rijksmuseum.nl QA Contact|koha-bugs(a)lists.koha-commun |m.de.rooy(a)rijksmuseum.nl |ity.org | Status|Signed Off |BLOCKED --- Comment #13 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- QAing -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 24627] New: Selecting Club for which to place the hold is missing Box to Select
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24627 Bug ID: 24627 Summary: Selecting Club for which to place the hold is missing Box to Select Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 98686 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=98686&action=ed… select In almost all places in Koha, when a user is given a list of options in the Hold Menu, the option to choose is indicated with either a button to pick or a circle to check. This is indicating a choice has been made. When picking which Club to place a book club book for, there is no indication, that a choice can be made. Yes, the club can be chosen (by clicking the words) but it is not the usual way for Koha, and I think users will be confused. See screenshot. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 9097] 'Welcome mail' for new library users
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9097 --- Comment #5 from Owen Leonard <oleonard(a)myacpl.org> --- It seems odd to me that the AutoEmailOpacUser preference ONLY works if you're adding someone from the staff interface. A more comprehensive solution might add a flag to the patron account so that a cron job could send the notice to any new (unflagged) accounts periodically, whether they were created by self-registration, patron import, or manually via the staff interface. If we did it like that it would be relatively easy to trigger the re-sending of a notice by toggling the flag on the patron's acccount, thereby putting them back into the notification queue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 10517] koha-restore fails to create mysqluser@mysql_hostname so zebra update fails
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 --- Comment #38 from Rudolf Byker <rudolfbyker(a)gmail.com> --- > git config --global user.name "firstname lastname" I'll keep this in mind for the future. > we could also fix this as part of QA That would be great, thanks. > but you should tell us what it should read like. Rudolf Byker? Exactly :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10517] koha-restore fails to create mysqluser@mysql_hostname so zebra update fails
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10517 --- Comment #37 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi, it's about the patch file, see: >From 06fd450e1f9749e8fa1d6455e32f597ac0ef85b4 Mon Sep 17 00:00:00 2001 From: dolf <rudolfbyker(a)gmail.com> Date: Wed, 8 Jan 2020 11:20:02 +0200 Subject: [PATCH] Bug 10517: Use `DROP USER IF EXISTS` and remove ` || true`. This means that you will show up as "dolf" in some places. We do have mappings to make things show nicer/full names, but always easier to make sure it has the information you want to display. I think you might want to run: git config --global user.name "firstname lastname" I believe if you don't want to resubmit, we could also fix this as part of QA, but you should tell us what it should read like. Rudolf Byker? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 29396] New: "Search to hold" should not rely on cardnumber
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29396 Bug ID: 29396 Summary: "Search to hold" should not rely on cardnumber Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 The "Search to hold" feature doesn't work for patrons without cardnumbers. To recreate: - create a patron without a cardnumber - from the patron record, click "Search to hold" - perform a search - in your search results, note the option "Place hold for [your patron name]()" - click "Place hold for [your patron name]()", see it takes you to request.pl without a patron selected - on request.pl, search for your patron by name and confirm you're able to place a hold that way, even without a cardnumber This feature shouldn't rely on cardnumber when cardnumber is not assumed to be required in all systems. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29499] New: CheckMandatorySubfields don't work properly with select field in serials-edit.tt
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29499 Bug ID: 29499 Summary: CheckMandatorySubfields don't work properly with select field in serials-edit.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Since one of the patches of Bug 27526 (Bug 27526: Fix mandatory and important checks), CheckMandatorySubfields use the class "input_marceditor" but in the file serials-edit.tt this class is not set for all field (it is present on text input but not on select input). In consequence if a select field is set as mandatory, it is detected as missing even if it is filed and so you can't submit the form and receive the new serial. Test plan: 0- Be sure to be in a version of koha where the patch that introduces the bug is present (it is present in master since Jul 8 2021 (it is present in 21.06.00.046) and will be pushed in 21.11.00) 1- Create (or find) a subscription for a biblio record and select the option "Create an item record when receiving this serial" 2- Be sure to have at least one mandatory subfield that is filed with a select input in the framework used by the biblio record. (ex: 995$b, 995$c or 995$e in unimarc; 952$a, 952$b or 952$c in marc21) 3- From the subscription-detail page click on "Receive" 4- Change the status to "Arrived" and fill the item form that appears. 5- Click on "Save" and check that an error box appear with the message " Form not submitted because of the following problem(s) 1 mandatory fields empty (highlighted)" (the number can be different according to the number of concerned subfields) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3