commit b3cfd2798e24e0322e416e83d30c3ff4c35e187b Author: Pedro Amorim Date: Tue Nov 10 12:25:42 2026 -0100 Bug 33260: DBRev 26.06.00.050 Signed-off-by: Pedro Amorim Co-Authored-By: Claude Opus 5.5 Signed-off-by: Pedro Amorim commit e183d6c22cfdff8919b9b088569791011b6a6694 Author: Martin Renvoize Date: Fri Oct 30 17:45:09 2026 +0000 Bug 33260: (follow-up) Add Cypress tests for the notices pages Cover the notices management page, the Notices tab of a patron and the print page: * The access to the page: the preference, the permission. * The filters: status, notice type, patron category, patron library and the dates, which are inclusive, alone and together, and with the search form. * What staff members who cannot see all the patrons see and can do, with IndependentBranches: only the notices of their library, which they cannot print or convert for another one, and no filter for the library. * Printing: each notice is shown in a frame that cannot run scripts, with a script and an event handler in the content that do not run, and that is shown in full; the notices that contain a secret, the pending notices that are not print notices and the converted notices are not printed; showing a notice does not change it, printing it does. * Converting to print: the print notice that is queued, the link between the two notices, the notices that can be converted, what is shown when the CONVERTED_TO_PRINT notice does not exist and when it has an error, and that the original is then not changed. The preferences and the CONVERTED_TO_PRINT notice that are changed are restored afterwards, and the patrons and staff members created are removed. To test: 1. Apply the patches 2. Run $ ktd --shell k$ yarn cypress run --spec t/cypress/integration/Tools/NoticesManagement_spec.ts => SUCCESS: Tests pass! 3. Sign off :-D Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 604c93f1ce3b6f52830ce0030d03311558f1a98b Author: Martin Renvoize Date: Fri Oct 30 16:27:58 2026 +0000 Bug 33260: (QA follow-up) Make converting to print clearer when it cannot work * Do not offer to convert notices when there is no CONVERTED_TO_PRINT notice, and when asked to anyway say that the notice does not exist and where to create it, instead of the notice could not be converted. * When the CONVERTED_TO_PRINT notice has an error, such as a missing [% END %] or an unknown variable, say so, and put the error in the error log. The notice that was to be converted is not changed. * Link the two notices, in the delivery note of each, which show 'Converted to print notice 123' and 'Converted from notice 122' on the notices management page and the Notices tab of the patron. To test: 1. Apply the patches, enable NoticesManagement 2. Queue a sent email notice for a patron, and convert it to print on the patron's Notices tab => The delivery note of the original says it was converted to the print notice, and that of the print notice says it was converted from the original 3. In Tools > Notices and slips, edit the CONVERTED_TO_PRINT notice (Patrons module, print) and add [% IF 1 %] without closing it. Try to convert another notice => It says the notice has an error, which is in the plack-intranet-error.log 4. Delete the CONVERTED_TO_PRINT notice => There are no Convert to print buttons. Going to the Notices tab with ?conversion=no_template says what is missing 5. prove t/db_dependent/Koha/Notice/Message.t Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 7c8f30bb6a32b1cb3b7edc015cf1028a85d35309 Author: Martin Renvoize Date: Fri Oct 30 16:22:49 2026 +0000 Bug 33260: (QA follow-up) Do not log printing and converting notices Printing and converting notices were logged under the Notices module, which is otherwise only used for the changes to the notice templates, as its preference says: 'Log changes to notice templates'. The log did not record the changes made to the notice either, and the action was displayed in capitals by the log viewer. Changes to the notices of the message queue need a log of their own, which is a piece of work of its own, so do not log them here. To test: 1. Apply the patches, enable NoticesManagement and NoticesLog 2. Print a notice and convert another one to print => Nothing is added to the Notices log, in Tools > Log viewer 3. prove t/db_dependent/Koha/Notice/Message.t Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 09267fbbc3e6a1080e552fc7b2183f58a8e014b6 Author: Martin Renvoize Date: Fri Oct 30 16:22:06 2026 +0000 Bug 33260: (QA follow-up) Print notices in sandboxed frames The content of a notice was printed as part of the page of the staff interface, so a script in a notice (the content of notices is not always under the control of the library, it can contain what a patron entered) would run in the session of the staff member printing it. Show each notice in a frame, as the notices management page and the Notices tab of a patron do for the preview: its sandbox does not allow scripts, forms or navigating the page, it is only the same origin so the frame can be sized to its content, which is needed to print it whole. * The notice is shown by html_content, which has the stylesheets, so the scoping of the styles of the notices to the page, which a regular expression got wrong more than once, is no longer needed and is removed. The style of the template of the notice is part of html_content. * The content of a plain text notice is escaped by html_content, as what looks like markup in it was interpreted. To test: 1. Apply the patches, enable NoticesManagement 2. Create an HTML notice for a patron, with a script in its content, for example

Hello

and set its status to sent 3. In Tools > Notices management, or the Notices tab of the patron, print it => The notice is printed with no alert, and the browser console says that the script was blocked. Before there was an alert 4. Print a few notices together and confirm the print preview shows all of them in full, separated by page breaks 5. prove t/db_dependent/Koha/Notice/Message.t Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit fff1140b6596a1291eb8eda26b7c43a611fed2cb Author: Martin Renvoize Date: Fri Oct 30 10:06:59 2026 +0000 Bug 33260: (QA follow-up) Fix ambiguous column when searching limited notices Converting a notice to print from the patron's Notices tab died with 'Column borrowernumber in WHERE is ambiguous' for a staff member whose notices are restricted to some libraries (for example with IndependentBranches, also with view_borrower_infos_from_any_libraries): search_limited joins the patron to restrict the notices to the libraries, and borrowernumber is a column of both tables. It only worked without a restriction because the unused join is then dropped. * search_limited now adds the name of the table to the columns of the notices that are passed without it, so callers cannot trip over the join. * The conversion on the patron's Notices tab says me.borrowernumber, which is clearer anyway. To test: 1. Apply the patches, enable NoticesManagement and IndependentBranches 2. Queue a sent email notice for a patron of your library 3. As a staff member with only the view_generated_notices and edit_borrowers permissions, go to the patron's Notices tab and click 'Convert to print' on the notice => The notice is converted. Before, the page died with the error above 4. prove t/db_dependent/Koha/Notice/Message.t Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit be4fb6be5f06f4abbaa7e473a34523413c4bf6bb Author: Martin Renvoize Date: Thu Oct 29 11:53:47 2026 +0000 Bug 33260: (QA follow-up) Convert notices to print notices Printing a notice that was sent or failed to be sent by email or sms is not very useful by itself: it has no address, and nothing says why it is being printed. A notice can now be converted to a print notice, to be sent by post: * A new notice, CONVERTED_TO_PRINT, is a wrapper for the original notice: it adds the address of the patron and of the library, and says that the original notice was sent, or could not be sent, by email or sms, before the content of the original notice. Libraries can edit it in Notices and slips. (The content of the original is all that is kept of a notice, the variables it was created from are not, so we cannot generate the print notice from them.) * "Convert to print", in the actions column and the modal of the Notices management page and of the patron's Notices tab, queues a pending print notice with it, and sets the original notice to the new status 'converted'. The print notice then goes through the usual printing, by the cronjob or by hand. It is logged when NoticesLog is enabled. * It is available for the notices that can be printed from the pages and that are not print notices, and that are not pending: those that have been sent, have failed or have been deleted. Notices that carry a secret cannot be converted, nor those of a patron that has been deleted. The existing "Print" action is kept, for example to hand a notice to a patron who is at the library. To test: 1. Run the unit tests inside KTD: ktd --shell --run 'prove t/db_dependent/Koha/Notice/Message.t' 2. Apply the database updates and enable NoticesManagement and NoticesLog. Check that the notice CONVERTED_TO_PRINT is in Tools > Notices and slips (module Patrons). 3. Queue an email notice and an sms notice for a patron with an address, and set the status of one to 'failed' and the other to 'sent'. 4. In Tools > Notices management click "Convert to print" on the failed email. A message says it was converted, a pending print notice is listed, with the address of the patron, a note saying the email could not be sent and the original content, and the original is now 'converted' (filter on "Converted to print"). 5. Open the sms notice and click "Convert to print" in the modal. 6. Do the same from the Notices tab of the patron. 7. Confirm a pending email, a printed or converted notice, a print notice and a password reset notice have no "Convert to print". 8. Print the pending print notice from the list. 9. Sign off Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 6204a99c102313f3f19d73583a8e4ca56714d75d Author: Martin Renvoize Date: Thu Oct 29 11:35:56 2026 +0000 Bug 33260: Automated Schema Update Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 6c9e96000118e23b2c5376b41e0a2c2f50f28051 Author: Martin Renvoize Date: Thu Oct 29 11:35:55 2026 +0000 Bug 33260: (QA follow-up) Add a 'converted' status to the message queue A notice that has been converted to a print notice, to be sent by post, is neither sent nor failed any more. Add a 'converted' status to message_queue.status, for the notice that was converted. To test: 1. Apply the patch and run the database update 2. Confirm in the database that message_queue.status accepts 'converted': UPDATE message_queue SET status = 'converted' WHERE message_id = X; 3. Sign off Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 86ca7810e9e61ac72dcfb894fea76eab827aedb1 Author: Martin Renvoize Date: Thu Oct 29 10:31:36 2026 +0000 Bug 33260: (QA follow-up) Do not display or print notices that contain secrets tools.view_generated_notices is a lower permission than the one that was needed to read the content of notices of a patron, and the notices include those that carry a secret: a password reset link (even a staff member's) or a security code. Anyone who could use the notices pages could read them. Notices that can carry a secret, those with the letter codes PASSWORD_RESET, STAFF_PASSWORD_RESET, OPAC_REG_VERIFY and 2FA_OTP_TOKEN, are still listed, with their status and the other details, so there is a record that they were sent, but: * their content is replaced by a message saying why in the lists, the preview and everywhere Koha::Notice::Message->html_content is used, * they cannot be printed (Koha::Notice::Message->can_be_printed), also from print_notice.pl. To test: 1. Run the unit tests inside KTD: ktd --shell --run 'prove t/db_dependent/Koha/Notice/Message.t' 2. Enable NoticesManagement and send a password reset to a patron, from the patron's page "More > Send password reset", or from the OPAC. 3. In Tools > Notices management and on the patron's Notices tab, open the password reset notice: its status is shown but not its content, and it cannot be selected or printed. 4. Other notices are still displayed and can be printed. 5. Sign off Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 1aec7b2cea61125f205adbe7a6f2df8ab16a46dd Author: Martin Renvoize Date: Thu Oct 29 10:30:44 2026 +0000 Bug 33260: (QA follow-up) Use the 'printed' status, print consistently Following the feedback on the bug: * Printing a notice is not sending it. Notices that are printed from the notices pages are now set to 'printed', not 'sent', and so are those printed by gather_print_notices.pl. The delivery note no longer shows the from/to/cc addresses of an email that was only printed. Marking a notice as printed is logged when NoticesLog is enabled. * The patron Notices tab and Notices management now follow the same rule, Koha::Notice::Message->can_be_printed, also enforced by print_notice.pl: notices that are not pending can be printed, and so can pending print notices (to replace the cronjob), but not pending email or sms, which would stop them from being sent. * The "Library" filter of Notices management filters on the library of the patron, not the one the notice comes from: say so, and hide the filter when the notices of the patrons of a single library can be seen. To test: 1. Run the unit tests inside KTD: ktd --shell --run 'prove t/db_dependent/Koha/Notice/Message.t' 2. Enable NoticesManagement and NoticesLog and queue notices of different types: an email and an sms that have been sent or have failed, and pending email and print notices. 3. In Tools > Notices management and on the patron's Notices tab confirm that the same notices can be printed, but not the pending email. 4. Print a sent email notice. Its status is now 'printed', no from/to is shown in its delivery note, and the printing is in the log viewer (module Notices, action PRINT). 5. Run misc/cronjobs/gather_print_notices.pl on pending print notices and confirm they are set to 'printed'. 6. As a staff member whose patron data is limited to one library, confirm the "Patron library" filter is not displayed. 7. Sign off Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 6b987497763f5d68be90245d43ff7203c57f4f11 Author: Martin Renvoize Date: Thu Oct 29 10:07:36 2026 +0000 Bug 33260: Automated Schema Update Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 0ce9b038e959a6cf78212457e718e3a4ebe4d2f8 Author: Martin Renvoize Date: Thu Oct 29 10:07:35 2026 +0000 Bug 33260: (QA follow-up) Add a 'printed' status to the message queue Printing a notice is not sending it, and "sent" for a notice that was only printed, especially an email or SMS one, is misleading. Add a 'printed' status to message_queue.status, for notices that have been printed, whatever their transport type. To test: 1. Apply the patch and run the database update 2. Confirm in the database that message_queue.status accepts 'printed': UPDATE message_queue SET status = 'printed' WHERE message_id = X; 3. Sign off Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 049fc4d16bafa17a3400d4f1a4a7359d81b40756 Author: Martin Renvoize Date: Tue Oct 27 22:08:34 2026 +0000 Bug 33260: (QA follow-up) Secure and fix the notices management pages Printing: * members/print_notice.pl looked messages up by id without any check, so a staff member who can only see the patrons of some libraries could print the notice of any patron by guessing an id, and an unknown id gave a 500. Look the messages up with search_limited, ignore ids that are not numeric, unknown or not allowed, and honour the NoticesManagement preference. * Displaying notices no longer changes them. Marking them as sent now needs a POST with a CSRF token and the 'cud-print' operation: the per-row and modal "Print" buttons submit a form like the bulk "Print selected notices" already did. This also makes the modal Print consistent with the banner, which says printing marks the notice as sent. * The notice content in the list pages and the modal preview is shown in sandboxed frames instead of being injected into the staff page, so nothing in a notice can run in the staff session. * print_notice.tt outputs AllNoticeStylesheet, says when there is nothing to print and does not start printing then, and the styles of the notice template are scoped with Koha::Notice::Message->scoped_template_style instead of a regular expression that dropped @media blocks. tools/notices.pl: * Stop after redirecting when NoticesManagement is off. * The 'To' date is inclusive, dates are parsed with dt_from_string and invalid ones are ignored. * Only list the most recent 1000 notices that match, as every notice is rendered in the page, and say so when there are more. * Use the modules it uses, drop unused code, https licence URL. Templates: * The status filter always selected 'sent' whatever the search. * The patron page sorted on the wrong column since a column was added, showed the notice frames and applied 'NoSort', which kohaTable does not know ('no-sort'). The tools table now uses kohaTable. * Show the print controls of the patron page only to staff who can use print_notice.pl, and the resend control of the tools page only to staff who can use members/notices.pl. * tools/notices.tt did not load the Koha plugin but used Koha.CSPNonce, so with a content security policy in force the style that hides the notice frames was blocked and every notice was displayed in the table. * Give the notice frames a title, translate the messages of the print page. * Use the patron of the notice in delivery notes, _() in JavaScript. members/notices.pl: resending compared the message's patron with an assignment (=), so any message id could be resent from any patron's page. To test: 1. Enable NoticesManagement and queue notices for patrons of at least two libraries (for example by placing holds, or from the staff interface with Notices and slips). 2. Tools > Notices management lists the notices. Search with a status and confirm the status stays selected, and with the same date in From and To confirm notices queued that day are listed. 3. Click Print on a notice. A new tab shows the notice, and it is now 'sent'. Open the notice and click Print in the window, same result. 4. Select several notices and click "Print selected notices", the same. 5. Open the URL /cgi-bin/koha/members/print_notice.pl?message_ids=ID of a pending notice directly. The notice is shown but stays pending, and unknown ids (...message_ids=99999) do not give an error. 6. Create a staff member with only the Tools > view_generated_notices permission, in a library group that hides patron information from other libraries. Log in as them: only the notices of patrons of their libraries are listed, and print_notice.pl does not show the notice of a patron of another library when you use its id. 7. Disable NoticesManagement: tools/notices.pl and print_notice.pl go back to Tools home. 8. On a patron's Notices tab confirm the default sort is by 'Time created', and that no notice content is displayed in the table. 9. Sign off Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 46ffbbef713135cd4b25b577acc3f0127ae95d5f Author: Martin Renvoize Date: Tue Oct 27 22:05:53 2026 +0000 Bug 33260: (QA follow-up) Repair the tests and notice classes after rebase Bring the patchset up to date with main and fix what QA found: * Koha::Notice::Messages->search_limited no longer modifies the passed conditions, ANDs its library restriction with any condition on the patron's library instead of replacing it, keeps a join passed by the caller, and returns nothing when the logged in patron cannot be found instead of everything. POD documents the behaviour, including that notices without a patron are only returned when there is no restriction. * Koha::Notice::Message->scoped_style produced broken CSS: the scope was inserted in the middle of declarations as soon as there was more than one rule, and rules inside @media and similar at-rules were lost. Replace the regular expressions by a small CSS scoper that handles comments, selector lists (split on their top level commas only) and nested @media, @supports, @document, @layer and @container rules, maps html, body and :root to the notice container, and does not warn when no styles are defined for the transport type. The same scoper is available for the styles of a notice template with Koha::Notice::Message->scoped_template_style. * Add the missing 'use' lines, and POD for _type and object_class. * Tests: search_limited now needs the library groups to hide patron information (Bug 20133), cover the other restriction cases and no longer leaks its transaction; add scoped_style and scoped_template_style tests; correct the test plans of Message.t and Letters.t. * Remove the 'notice_mgmt' branch from printslip.tt (nothing sets it any more since printing moved to members/print_notice.pl) and the unused link_to 'notices' in patron_autocomplete. * Make the permission atomicupdate executable, end patrons.pref and userpermissions.sql with a newline. To test: 1. Run the unit tests inside KTD: ktd --shell --run 'prove t/db_dependent/Koha/Notice/Message.t t/db_dependent/Letters.t t/Koha/Auth/Permissions.t' 2. Run the QA script and confirm there are no failures 3. Sign off Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit 603bba439948cb058f040dfa199f6c4056798ba0 Author: Martin Renvoize Date: Thu Mar 26 13:27:02 2026 +0100 Bug 33260: Add missing CSP nonces to inline style and script tags Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 133f1aa796a354de700c3d3cf27759a67b959390 Author: Martin Renvoize Date: Mon Oct 7 12:13:31 2024 +0100 Bug 33260: Migrate notice printing to members/print_notice This migrates the bulk notice printing from tools/print_notice.pl using circ/printslip.tt to members/print_notice.pl using members/print_notice.tt This clarified that we are working on pre-existing notices in the message queue and as such should be applying relevant print/email notice styling and not slip styling. Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 5b96ca495e285f996d650d2f07db9eedcfd812e3 Author: Martin Renvoize Date: Mon Dec 16 17:07:57 2024 +0000 Bug 33260: (follow-up) Also add 'print' option to modal on tools Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 8e07559df4b1a76768fbd31232bb86b128d8060f Author: Martin Renvoize Date: Mon Dec 16 16:28:12 2024 +0000 Bug 33260: Add hint to disabled select checkbox Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit a903ef425c815562d099345756052315007f7d6b Author: Martin Renvoize Date: Mon Dec 16 16:22:32 2024 +0000 Bug 33260: Replace nosort with NoSort Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 527a10e7ec80c5b758d3a75266c3cacc43cd907d Author: Martin Renvoize Date: Mon Dec 16 15:14:48 2024 +0000 Bug 33260: Fix TT syntax failure Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 9051c16828462b5576beb453c3d329ce79bcaec8 Author: Martin Renvoize Date: Mon Dec 16 15:12:04 2024 +0000 Bug 33260: Fix typo noice -> notice Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 5dd7209364bd05588be0e706b4f9b08934df4196 Author: Martin Renvoize Date: Mon Dec 16 15:08:55 2024 +0000 Bug 33260: (follow-up) More comprehensively test template accessor Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 89fd6bb270b589a13fb5c0ba1051ffbf049af325 Author: Martin Renvoize Date: Mon Dec 16 15:04:23 2024 +0000 Bug 33260: (follow-up) More comprehensively test patron accessor Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit ef0664c946889b92cec4626529e81497e689fc51 Author: Martin Renvoize Date: Fri Oct 4 09:18:40 2024 +0100 Bug 33260: (follow-up) Correct call to 'style' Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit cde4715b4b206f8949efc7059694bf3eeae4cb8d Author: Martin Renvoize Date: Thu Oct 3 15:32:51 2024 +0100 Bug 33260: (follow-up) Alternative print button in modal This adds a simple print option to the modal preview display on the members page. It simply prints the content of the display modal and doesn't set the status change. This might be useful to allow pending notices to still be printed. Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 090b0150eb820dfda30e0d6142e6e43b3762b464 Author: Martin Renvoize Date: Thu Oct 3 13:24:13 2024 +0100 Bug 33260: (follow-up) Limit printing to non-pending on members page This patch prevent printing of notices in the 'pending' state. This ensures that email notices will not be skipped by process message queue at it's next run as we set the 'sent' status on print with this patchset. It still allows for printing of sent and failed messages which I believe is the purpose of the original patchset. Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit efe346b342bdbd377bb5eb98bc24017207d947ab Author: Martin Renvoize Date: Thu Oct 3 13:13:35 2024 +0100 Bug 33260: (follow-up) Add correct page title to print Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit dcf8bfd685339856723026a83fd6fee8e4a71d68 Author: Martin Renvoize Date: Wed Oct 2 14:44:19 2024 +0100 Bug 33260: (follow-up) Sync functionality and ordering of display This patch syncs up the functionality and order of the notice displays. We allow for resending of notices via the modal in the new tools page and we add print in bulk to the members notices page. We also fix the modal on the tools page to work with bootstrap 5 correctly. Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 914e36f9e02f0e9ea1e0f4fb1922963948fa2996 Author: Martin Renvoize Date: Tue Oct 1 09:24:23 2024 +0100 Bug 33260: (follow-up) Remove patron search as primary action This is a 'Notices' display tool, it doesn't make sense to me to replicate the 'Patrons' search interface as the primary action of the tool. Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit cc803d117099b91a220fdd5c81ee887263d6c2e4 Author: Martin Renvoize Date: Tue Oct 1 08:16:33 2024 +0100 Bug 33260: (follow-up) Rebase for bootstrap 5 Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 936f79e940f986563ac346f3ecc1a1d76554628d Author: Martin Renvoize Date: Wed May 8 06:34:39 2024 +0100 Bug 33260: (QA follow-up) Add missing page-section Add the missing page-section div to the new page and include required messages.inc include as is now standard. Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 9b60b485742ad25bb37cde04501028c6790836e6 Author: Martin Renvoize Date: Tue May 7 19:41:46 2024 +0100 Bug 33260: (QA follow-up) Safely continue for non-templated notices The 'letter_id'/'letter_code' field in the message queue table is a NULLable foreign key as is indeed NULL in certain circustances. We need to gracefully degrade when there isn't a template for the notice in question. Tihs patch uses the newly introduced 'template' accessor and when that returns undefined we pass 'style' as an empty string. We also use the 'is_html' method introduced in bug 35285 to set the html flag. Signed-off-by: Martin Renvoize Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 0ebcd4fc37081882052a371b61ddbc366de40419 Author: Martin Renvoize Date: Tue May 7 19:40:27 2024 +0100 Bug 33260: (QA follow-up) Add template relation This patch add the 'template' relation to the Koha::Notice::Message object to fetch the Koha::Notice::Template object that may have been used to generate the notice. Signed-off-by: Martin Renvoize Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 1a1a1177c50362ae8ab12443b605f38b01464291 Author: Aleisha Amohia Date: Mon May 6 03:00:20 2024 +0000 Bug 33260: Use search_limited to protect message privacy, and unit test This patch adds a Koha::Notice::Messages->search_limited sub to allow better control over which patron's notices the user can see. Test added to t/db_dependent/Koha/Notice/Message.t Signed-off-by: Martin Renvoize Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 2e2f1c5f492884d210580dae973ad254970219b3 Author: Martin Renvoize Date: Wed May 1 17:26:03 2024 +0100 Bug 33260: (QA follow-up) Correct relation accessor and add unit test We were missing unit tests for the patron relation accessor added to Koha::Notice::Message and once I looked at adding the test I spotted the accessor was also using a rather outdated form. Signed-off-by: Martin Renvoize Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 9869e344f96a846a9f52cf6c9db93ad20a2d8da6 Author: Aleisha Amohia Date: Mon Apr 29 01:54:43 2024 +0000 Bug 33260: (follow-up) Fix search forms on notices mgmt page Signed-off-by: David Nind Signed-off-by: Martin Renvoize Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit bffdadfd5adc5152e19975d64865f7f244bc756d Author: Aleisha Amohia Date: Wed Apr 12 23:09:53 2023 +0000 Bug 33260: Move patron search into main body of page This patch moves the patron search in the Notices management page to the main body of the page so that the patron search result table displays more nicely. This is a better place for it anyway, as using this search takes the user to a different page. In the sidebar, where it was previously, it implied it would have the same results display as the search filters. Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Martin Renvoize Signed-off-by: Marion Durand Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 7298c4d24b13149287b4e892517c50493b2aa2e7 Author: Aleisha Amohia Date: Tue Mar 21 02:49:45 2023 +0000 Bug 33260: Add Notice management tool This enhancement makes it easy for the library to view sent notices and filter by various search parameters. You can also print sent notices, individually or in a batch. This enhancement uses a new system preference NoticesManagement and a new view_generated_notices user permission. This enhancement has been built on top of Bug 33478 so print format settings are taken into account when printing notices. To test: 1. Apply patches, install database updates, restart services 2. Make sure your logged in user has the view_generated_notices permission checked 3. Enable the NoticesManagement system preference 4. Generate a few notices. There are a few ways to do this including: - place holds, check in items and confirm the holds - place recalls, check in items and confirm the recalls 5. Go to Tools -> Notices management 6. There are two search functions on the left navigation. Confirm the patron search box works by searching for one of the patrons you generated a notice for, you should be redirected to their Notice history. 7. Go back to Notices management. Use the set of search filters to search for notices. Leaving the search filters empty will return all notices generated. Confirm the filters work as expected by using different combinations of filters. 8. Conduct a search so your notices show in a table. Confirm the information fetched about the notices is correct. 9. Click on a notice title. Confirm the contents of the notice show in a pop-up box. 10. Click one of the Print buttons next to a notice. Confirm the notice is opened to be printed. 11. Redo your notices search. Confirm the status of the notice you just printed has now been updated to 'sent'. 12. Use the 'Select all' and 'Clear all' buttons to select or clear the checkboxes. 13. Select a few checkboxes and click the button at the bottom of the table to 'Print selected notices'. Confirm the notices have been collated into one document, separated by horizontal lines, and prints successfully. The statuses for the notices should all be updated to 'sent'. 14. Confirm the Notices management page is not visible without the view_generated_notices permission 15. Confirm the Notices management page is not visible without the NoticesManagement system preference being enabled. 16. Go to a patron's Notices history. If the view_generated_notices user permission is checked for your logged in patron, you should see a Print button for each notice. Confirm this works. Confirm this button doesn't show if your logged in patron does not have the view_generated_notices user permission. It does not require the NoticesManagement system preference. 17. Go to Tools -> Notices & slips 18. Edit the format settings of a few different notices i.e. HOLD and WELCOME 19. Generate these notices by filling a hold for a patron and sending a welcome email 20. Search for all notices under Tools -> Notices management 21. Select all notices and print selected notices 22. Confirm the notices different format settings are taken into account in the printed PDF Sponsored-by: Colorado Library Consortium Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Martin Renvoize Signed-off-by: Marion Durand Signed-off-by: Laura Escamilla Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 26ea37bd7cf0e17004b38c40d7f580a63e93006e Author: Aleisha Amohia Date: Tue Mar 21 02:47:29 2023 +0000 Bug 33260: Add a patron getter method to Koha::Notice::Message Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Martin Renvoize Signed-off-by: Marion Durand Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 7152d0504553950565c9ef5c2006bdb5047e612e Author: Aleisha Amohia Date: Tue Mar 21 01:04:18 2023 +0000 Bug 33260: Add NoticesManagement system preference Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Martin Renvoize Signed-off-by: Marion Durand Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit c50a593ad5530d78d0738b295cf96a5e31b41178 Author: Aleisha Amohia Date: Mon Mar 20 22:51:55 2023 +0000 Bug 33260: Add view_generated_notices user permission Signed-off-by: Laura Escamilla Signed-off-by: Kelly McElligott Signed-off-by: David Nind Signed-off-by: Martin Renvoize Signed-off-by: Marion Durand Signed-off-by: Brendan Lawlor Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 19b63ffaf2f60312f885e028d991dbdd194dec17 Author: Kyle M Hall Date: Tue Oct 27 13:05:55 2026 +0000 Bug 15283: Switch default ISSUEQSLIP notice to TT Convert the default ISSUEQSLIP (issue quick slip) notice from the historical <> / syntax to Template Toolkit. C4::Members::IssueSlip already passes the checkouts of the day to quick slips as the 'issues' loop, which is available to Template Toolkit notices as 'checkouts', and the patron is available as 'borrower', so no code changes are needed. Due dates are displayed with the time, as they were with the historical syntax. A test renders the notice that ships in sample_notices.yml for a patron with a checkout from today, and one from yesterday that must not be shown. To test: 1. Apply this patch 2. Go to Tools > Notices and slips and edit the Issue quick slip notice (ISSUEQSLIP). View the default template, use "Copy to template" and save (a new installation has this notice by default) 3. Check out an item to a patron and print a quick slip 4. Confirm the library, the patron name and card number, today's date and the title, barcode and due date of today's checkouts are all displayed 5. Run $ prove t/db_dependent/Members/IssueSlip.t Rescued-by: Martin Renvoize Signed-off-by: Martin Renvoize Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Barbara Johnson Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 682af40425c718d1217a0e108df9ab8ab4ecdf27 Author: Caroline Cyr La Rose Date: Fri Jan 23 16:33:03 2026 -0500 Bug 41702: Update MARC21 authority frameworks to Update 41 (December 2025) This patch updates the MARC21 default authority frameworks to include changes brought by Update 41 to the MARC21 format. See https://www.loc.gov/marc/authority/adapndxf.html for the list of changes. Changes to field 368 - Added subfield $4 - Relationship (R) - Added subfield $i - Relationship information (R) Changes to field 376 - Added subfield $4 - Relationship (R) - Added subfield $i - Relationship information (R) Changes to field 381 - Added subfield $4 - Relationship (R) - Added subfield $i - Relationship information (R) Changes to field 884 - Subfield $g renamed to Conversion date/time To test: 1. Apply patch and reset_all 2. Go to Administration > Authority types > Default 3. Check that the additions/modifications are correct as per the list above NOTE: This change only applies to NEW installations. For existing installations, you must make the changes yourself in Administration > Authority types. This is to avoid overwriting customizations libraries might have made to their authority frameworks. Signed-off-by: David Nind Signed-off-by: Katrin Fischer Signed-off-by: Pedro Amorim commit a38f0c9cff7813050b19df6221b11d5e367ea8ee Author: Martin Renvoize Date: Tue Nov 3 08:53:05 2026 +0000 Bug 43402: (QA follow-up) Say that a fee was written off, not that a payment was received The notification offered after a payment is taken on the patron account pages said "Payment received" for a write off too, which could make staff worry that they had entered a payment rather than a write off. pay.pl and boraccount.pl now look up the credit by its payment_id, on the patron's account, and give its type to the template, which says "Fee written off" for a write off and keeps "Payment received" otherwise. As a result the notification, and the links to its receipt, are only shown for a credit that is on the account of the patron being looked at, instead of for any payment_id. To test: 1. Set FinePaymentAutoPopup to "Do not show" 2. Write off a fee, individually (Write off) and by selecting charges (Write off selected) => "Fee written off", with Print/Email receipt 3. Pay a fee, individually and by selecting charges => "Payment received", with Print/Email receipt 4. Open members/pay.pl or members/boraccount.pl with the payment_id of another patron's payment => No notification 5. Run the Cypress spec t/cypress/integration/Circulation/PaymentReceiptAlert_spec.ts Sponsored-by: Martin Renvoize Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 06631f467edbfcc57e6c62f935c48659675a2655 Author: Martin Renvoize Date: Wed Sep 2 17:40:13 2026 +0100 Bug 43402: (follow-up) Use change= not change_given= for the new print links printfeercpt.pl only ever reads a 'change' param into its GetPreparedLetter substitute hash (matching the ACCOUNT_CREDIT/ CREDIT_* notice templates, which use [% change | $Price %]) - not change_given. The new alert's Print receipt links were built with change_given=, which would have silently dropped the Change amount from the printed receipt, same as the pre-existing bug fixed for the FinePaymentAutoPopup window.open calls by Bug 43288. Bug 43288 doesn't touch these new lines (they didn't exist yet when it was written), so fix them directly here rather than duplicating that patch. Sponsored-by: Martin Renvoize Signed-off-by: Juliet Heltibridle Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit b41338874fdcc2f2c96c77b986ade7b18ebcee5c Author: Martin Renvoize Date: Wed Sep 2 17:26:53 2026 +0100 Bug 43402: Offer button to print/email receipt when collecting account payments Syncs the "Payment received" notification introduced for the Point of Sale module (bug 41705) to the patron account payment screens. When FinePaymentAutoPopup is off, taking a payment via members/paycollect.pl now lands on either members/pay.tt or members/boraccount.tt (depending on the payment path) with an inline alert offering to print or email the receipt for the transaction that was just taken, instead of requiring a trip to the Transactions tab to find the line and use its row-level receipt actions. Both pages already received payment_id/change_given via the existing PRG-style redirects from paycollect.pl, so no controller changes were required - the email action reuses boraccount.pl's existing cud-send_receipt handler. The print/email buttons on all three payment screens (POS, pay, boraccount) now carry stable ids so they can be targeted with IntranetUserCSS, as requested in the bug. Test plan: 1. Set FinePaymentAutoPopup to "Do not show" (off) 2. Go to a patron's account > Make a payment, pay a charge individually (pay_individual) -> lands on pay.tt with the "Payment received" alert; Print/Email receipt work 3. Select multiple charges and pay together (cud-pay) -> lands on boraccount.tt with the same alert 4. Set FinePaymentAutoPopup back on and confirm the alert is not shown (receipt pops up automatically instead, as before) 5. Confirm Point of sale payments still behave as before Sponsored-by: Martin Renvoize Signed-off-by: Juliet Heltibridle Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit c7c672f6769201eb86870b05cf85ff2114b50555 Author: Caroline Cyr La Rose Date: Thu Oct 29 21:01:57 2026 +0000 Bug 43942: Untranslatable actions on vendor (again) This patch fixes the Basket and Contract strings from the New menu in a Vendor so that they are translatable again. To recreate : 1. Install a new language (sorry if the commands are not the correct ones, I never remember from one time to another) koha-translate --install fr-CA --dev kohadev And activate the language in system preferences 2. Go to Acquisitions > Search for My Vendor http://localhost:8081/cgi-bin/koha/acquisition/vendors/1 3. Click on "Nouveau" --> Basket and Contract are in English, while Vendor is in French 4. Apply patch 5. Update the strings gulp po:update --lang fr-CA 6. Go in fr-CA-messages-js.po and translate Basket and Contract 7. Go in the root shell and update the translations koha-translate --update fr-CA --dev kohadev 8. Redo step 2 and 3 --> Basket and Contract should now be translated Signed-off-by: Owen Leonard Signed-off-by: Jonathan Druart Signed-off-by: Pedro Amorim commit d18c60bcfc56085ea57ebcd872bc16ac2a89de90 Author: Martin Renvoize Date: Mon Nov 9 12:22:01 2026 +0000 Bug 38291: (QA follow-up) Filter library groups with q only The endpoint declared a query parameter for every attribute of a library group, which only repeat what the q parameter does. For the boolean attributes they were also wrong: they were declared as integers although the API returns booleans, so filtering with a value read back from the API, for example ?is_local_hold_group=true, was refused. Declaring them as booleans would not have been enough. Plain query parameters are matched with like, and any value that is not empty counts as true, so ?is_local_hold_group=false (and =0) would list the groups that have the flag set. Other routes behave the same way, for instance /patrons?protected=false lists the protected patrons. /libraries, which this route follows, filters its boolean attributes with q, and nothing needs the plain parameters here: each one that is published is a promise to keep supporting it. Remove them, and test that every attribute that is a flag can be filtered with q, with true and false. To test: 1. Apply the patches, then run yarn api:bundle and restart_all 2. Administration > Library groups: create a group "Hold group" with "Is local hold group" checked, and a group "Other" without it 3. Log in to the staff interface as a superlibrarian and visit /api/v1/library_groups?q={"is_local_hold_group":true} => SUCCESS: "Hold group" is listed, and "Other" is not 4. Visit /api/v1/library_groups?q={"is_local_hold_group":false} => SUCCESS: "Other" is listed, and "Hold group" is not 5. Visit /api/v1/library_groups?q={"title":"Other"} => SUCCESS: only "Other" is listed 6. Run: prove t/db_dependent/api/v1/library_groups.t xt/api.t => SUCCESS: Tests pass Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim commit a2579b7fa8f00392b08b01c7d5a32c7ad83ed15a Author: Martin Renvoize Date: Mon Nov 9 11:56:29 2026 +0000 Bug 38291: (QA follow-up) Tidy up the library group definition and test - hide_patron_info is required, like the other flags: all the flag columns are NOT NULL, and the API always returns them - created_on and updated_on are date-times, and read only. updated_on cannot be null, as library_groups.updated_on is NOT NULL - remove the List::Util import that the test does not use To test: 1. Apply the patches, then run yarn api:bundle and restart_all 2. Log in to the staff interface as a superlibrarian and visit /api/v1/library_groups => SUCCESS: created_on and updated_on are dates, for example 2026-11-09T11:14:34+00:00, and every group has hide_patron_info 3. Run: prove t/db_dependent/api/v1/library_groups.t xt/api.t => SUCCESS: Tests pass Co-Authored-By: Claude Sonnet 5.5 Signed-off-by: Pedro Amorim