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

[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

[Bug 5601] SIP Due dates miscalculated via DateTime
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5601 Jonathan Druart <jonathan.druart+koha(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |29410 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29410 [Bug 29410] Dates compared arithmetically in MsgType.pm (warns: Argument isn't numeric in numeric ne) -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 29502] New: Possibility of changing the database engine to avoid errors in autoincremental fields
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29502 Bug ID: 29502 Summary: Possibility of changing the database engine to avoid errors in autoincremental fields Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: jcautomatizacion(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hi, A few days ago a reboot of the DB server was carried out due to a failure, this caused Koha to present a failure in incremental fields and they began to duplicate record id, specifically in reservations. Is there a possibility to change the database engine to avoid errors of autoincremental fields when failures happen in the DB server? Thanks for the help. Jonathan Cúellar -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 29508] GET /patrons/:patron_id should use Koha::Patrons->search_limited
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29508 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #5 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Great work going through all this Tomas! Works as expected, tests are thorough and passing. Signing off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 29508] GET /patrons/:patron_id should use Koha::Patrons->search_limited
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29508 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #127758|0 |1 is obsolete| | --- Comment #4 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Created attachment 127771 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=127771&action=e… Bug 29508: Make GET /patrons/:patron_id use Koha::Patrons->search_limited This patch makes the route return 404 if the user is not allowed to see the requested patron information. To test: 1. Apply the regression tests 2. Run: $ kshell k$ prove t/db_dependent/api/v1/patrons.t => FAIL: The code doesn't respect limits 3. Apply this patch 4. Repeat 2 => SUCCESS: Tests pass! 5. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> Signed-off-by: Martin Renvoize <martin.renvoize(a)ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 29508] GET /patrons/:patron_id should use Koha::Patrons->search_limited
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29508 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #127757|0 |1 is obsolete| | --- Comment #3 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Created attachment 127770 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=127770&action=e… Bug 29508: Regression tests Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> Signed-off-by: Martin Renvoize <martin.renvoize(a)ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 16885] New: koha-stop-zebra should be more sure of stopping zebrasrv
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16885 Bug ID: 16885 Summary: koha-stop-zebra should be more sure of stopping zebrasrv Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net The koha-stop-zebra command can finish without ensuring that zebrasrv is actually stopped. In particular, if there is an active query running when daemon --stop is run, the following state of affairs will occur until the query finishes or times out: - the child zebrasrv processing the query continues to run - the parent zebrasrv process becomes a zombie - the daemon(1) process continues to run -- and doesn't delete the lock file until the children go away. This is particularly problematic when a koha-stop-zebra is followed by a koha-start-zebra in quick succession, as happens during a logrotate. This is because while zebrasrv is in the half-stopped, half-started stop, the lock file still exists... and koha-start-zebra will see it and believe that zebrasrv is still running. When the query holding the child zebrasrv process finishes, the instance is left with no running Zebra. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25