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

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #144435|0 |1 is obsolete| | Attachment #144436|0 |1 is obsolete| | Attachment #144437|0 |1 is obsolete| | Attachment #144438|0 |1 is obsolete| | Attachment #144439|0 |1 is obsolete| | Attachment #144440|0 |1 is obsolete| | Attachment #144441|0 |1 is obsolete| | --- Comment #130 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Created attachment 175690 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175690&action=e… Bug 7376: Transfer limits should be checked at check-in Test case: * UseBranchTransferLimits must be set * define your branch transfer limit. Refuse transfers from libraryA to libraryB * checkout a book owned by libraryB, from libraryB, with a librarian located at libraryB * move the librarian to libraryA ("Set Library" link top/right) * check-in the book => it's possible whatever your setup After the patch, the behaviour respect the branch transfer limit parameter: you can check-in if you accept transfers, you can't if you refuse them. (Note: IndependantBranches must be OFF, otherwise it's not possible to do the checkin whatever the branch transfer limits) Sponsored-by: National Library of Finland Signed-off-by: Arthur Suzuki <arthur.suzuki(a)biblibre.com> Signed-off-by: Julian Maurice <julian.maurice(a)biblibre.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 --- Comment #133 from Mathieu Saby <mathsabypro(a)gmail.com> --- Hi We would be interested by testing too. Thibauld do you plan to provide a fixed patch in next months ? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38618] New: Remove implicit template translations (in .tt and .inc), use only explicit macro invocations
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38618 Bug ID: 38618 Summary: Remove implicit template translations (in .tt and .inc), use only explicit macro invocations Change sponsored?: --- Product: Koha Version: Main Hardware: All URL: https://wiki.koha-community.org/wiki/Translation_in_te mplates_fix_RFC OS: All Status: NEW Severity: enhancement Priority: P4 Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com, julian.maurice(a)biblibre.com See this: https://wiki.koha-community.org/wiki/Translation_in_templates_fix_RFC Also important thread on mattermost: https://chat.koha-community.org/koha-community/channels/translators/m5yxaxz… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 38383] New: say_info messages in web installer have bad contrast/font color
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38383 Bug ID: 38383 Summary: say_info messages in web installer have bad contrast/font color Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: oleonard(a)myacpl.org Reporter: ewa.gozd(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This might be another effect of the Bootstrap 5 upgrade. The font color of the say_info messages in the web installer are not well readable/lack contrast. -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 7003] Canned report to show patrons and permissions
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7003 Katie Bliss <kebliss(a)dmpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kebliss(a)dmpl.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37913] New: Remove more unreachable code in aqcontract.tt
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37913 Bug ID: 37913 Summary: Remove more unreachable code in aqcontract.tt Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Acquisitions Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 37728 Bug 37823 removes one set of unreachable code from aqcontract.tt, a block that tried to tell you that you had created a new contract rather than just showing you the new contract, but there is another: When you delete a contract, what actually happens is that you are shown the details page for the vendor, which lists the contracts for that vendor at the bottom, thus showing you that the contract has been deleted, but the template has a block which thinks it is going to tell you "<h1>Contract deleted</h1>" and then have you click an OK button to POST a form with no op param starting with cud-, which now fails the CSRF protection. Luckily, it's unreachable (and has been since aqcontract.pl first landed, it has always redirected after deleting, and has never shown that block), but having it there still fails a test once bug 37728 lands and lets the test see it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 38200] New: Remove dead code to delete authorities in authorities/authorities.pl
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38200 Bug ID: 38200 Summary: Remove dead code to delete authorities in authorities/authorities.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org authorities/authorities.pl (the authority editor) has an op cud-delete. Hypothetically, it might have been run at some point before the template transition 13 years ago: somewhere between the initial commit of authorities support 20 years ago and then, the editor might have had a delete button that called it. Since then, it hasn't had one. You can see that it hasn't been run in the past 8 years by looking at the use block: before 8 years ago we had use C4::AuthoritiesMarc; but since then we've used specific exported things from it, never including DelAuthority. You might think it was used by deleting authorities in auth_finder.pl, a rather odd thing to have, but no: from the start, when it was auth_linker.pl, it has not had UI to delete. It did have the param nonav which it used to send people back to auth_linker after they created an authority, but since it was also passing myindex, the index of the bib field where auth_linker was supposed to put the results of its lookup, now the existence of that says it's an authority created from auth_finder and nonav is dead, too. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 38325] New: Cannot delete invoice while viewing it
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38325 Bug ID: 38325 Summary: Cannot delete invoice while viewing it Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 36192 In the list of invoices in invoices.pl, an invoice that can be deleted (because nothing has ever been received into it) has a Delete action that uses submit-form-link and works with CSRF protection. In invoice.pl where you are viewing an individual invoice, the Delete link still thinks that invoice.pl?op=delete will work, which it won't. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 38734] New: Default notice templates should use preferred_name
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38734 Bug ID: 38734 Summary: Default notice templates should use preferred_name Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 28633 Default notice templates should be updated to use the preferred_name field, since that field was designed to override the first name (or stay identical to the first name if the field is hidden everywhere). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633 [Bug 28633] Add a preferred name field to patrons -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3