Odoo Changelog — 2025-05-21

Wednesday, May 21, 2025

49 changes · 18.0

Improvements(3)

Enhancements to existing features

[IMP] certificate, l10n_es_edi_*: Factor patched HTTPAdapter for certificates models

Core18.0certificatel10n_es_edi_siil10n_es_edi_tbai

The certificate connection logic used for Spanish electronic invoicing integrations has been centralized so it can be reused more consistently. This reduces duplication and makes certificate-based communication with external services easier to maintain for future updates.

Original PR description

We generalize the CertificateAdapter that is needed to make zeep read our own Certificate model for the session.

Necessary for: odoo/odoo#196054

Task [link](https://www.odoo.com/odoo/project/967/tasks/4477745)
task-4477745

#certificates#electronic-invoicing#spain#maintenance

[IMP] account: change payment state tag colors for better UX clarity

PR #210071

Core18.0account

Payment status tags in Accounting now use more intuitive colors. In Progress appears orange to show that work is still needed, while Paid appears green to clearly indicate completion.

Original PR description

Before this commit:
- 'In Progress' payment states were shown with a green tag, which could misleadingly suggest that the payment process was complete.
- 'Paid' payment states were shown with a grey tag, implying that some action might still be pending.

After this commit:
- 'In Progress' tags are now orange, signaling that further actions (such as batching or reconciliation) are still required.
- 'Paid' tags are now green, indicating that the process is fully complete and no further user action is needed.

Task Id: 4797098


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#payments#status#user experience

[IMP] payment_razorpay: Restrict multiple pending tokenized transactions for same document

PR #209488

Core18.0payment_razorpayMedium

This update stops multiple pending recurring payment transactions from being created for the same document when using Razorpay payment tokens. It helps ensure RBI pre-debit notification timing is respected and reduces the risk of duplicate customer charges or payment confusion.

Original PR description

As per RBI Notification RBI/2019-20/47, ensure a pre-debit notification is sent at least 24 hours before the actual debit for recurring payments. Prevent creation of duplicate pending transactions with token for the same document because every transactions confirm after 24 hours.

task - 4678509

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#razorpay#recurring payments#compliance#duplicate prevention

Bug Fixes(17)

Resolved issues and error corrections

[FIX] mail: keep composer template dropdown in viewport

PR #208383

Core18.0mail

The mail composer template dropdown now remains within the screen on mobile devices, even when template names are very long. This prevents users from losing access to dropdown options and makes saving or selecting message templates more reliable on smaller screens.

Original PR description

Steps to reproduce
==================

- Use a mobile device/viewport
- Go to any record with a chatter
- Click on Log note
- Expand the composer
- Click on the template dropdown
- Save the current content as a template with a long name
- Open the dropdown again

=> The dropdown is almost entirely off screen

Cause of the issue
==================

The Dropdown component uses the usePosition hook.
It works by doing the following:
- It tries the fit the content using the position props (or it's default value)
- If it doesn't fit, it tries the four other corners
- If it's still doesn't fit, it gives up and uses the first one again

Solution
========

Since we cannot show too much content inside a dropdown, we set a max-width on the dropdown content, and truncate the template names.

Another possibility would be to allow an horizontal overflow.

opw-4675320
opw-4674341
opw-4656725

Other(29)

Miscellaneous changes

[FW][FIX] analytic: runbot build error industry_fsm single app tests

PR #210175

Core18.0analytic

Original PR description

### Steps to reproduce:

- install fsm_industry
- run any of these tests:
    - test_change_parent_plan
    - test_change_parent_plan_conflict
    - test_change_parent_plan_with_intermediate
    - test_change_plan
    - test_change_plan_conflict
    - test_change_plan_no_conflict
#### > create access right error for the `account.analytic.line` model

### Cause of the issue:

The following three record rules provide the creation of `account.analytic.line` for users related to project or timesheet access rights unless the analytic line it self is linked to a project: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L52-L64 https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L78-L83 Since the analytic module is unrelated to the project module, these tests will inevitably fail.

### Note:

These record rules do not stop the record creation once the account module is installed since the following record rules override the creation access rights for `account.group_account_invoice` users: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/account/security/account_security.xml#L102-L107

Similar issue treated in commit 9d164c1d2cd8e532109b9859ab776fcf2f71d115

### Note 2:

A priori, the same problem would occur if we were to write post install analytic tests for portal users:
https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L50

### Forward port additional fix (18.0):

Since Commit 0e997470b7174a187c876d734e38f633223f65ec the test  of the `TestAnalyticAccount` class are launched in sudo mode since the environment is set using OdooBot and never associated with an other user:
https://github.com/odoo/odoo/blob/ed38752e55d6bafbc71fac3df249f226a4eba332/odoo/tests/common.py#L979
https://github.com/odoo/odoo/blob/4baf55a5d108063b0b60beddf332b6ae367f1871/odoo/api.py#L568-L571
In 17.0 the environment was reset to a non sudo mode by the user  reassignement:
https://github.com/odoo/odoo/blob/d2ea23f252f0f8f329e2b0ff96de6ee2a14b922f/addons/analytic/tests/test_analytic_account.py#L28-L31
In order for the tests to also check access rights we have added our own `setup_independent_user` in the `AnalyticCommon` class.

runbot-160013
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#210001
Forward-Port-Of: odoo/odoo#208978

We generalize the CertificateAdapter that is needed to make zeep read our own Certificate model for the session. Necessary for: odoo/odoo#196054 Task [link](https://www.odoo.com/odoo/project/967/tasks/4477745) task-4477745

Before this commit: - 'In Progress' payment states were shown with a green tag, which could misleadingly suggest that the payment process was complete. - 'Paid' payment states were shown with a grey tag, implying that some action might still be pending. After this commit: - 'In Progress' tags are now orange, signaling that further actions (such as batching or reconciliation) are still required. - 'Paid' tags are now green, indicating that the process is fully complete and no further user action is needed. Task Id: 4797098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

As per RBI Notification RBI/2019-20/47, ensure a pre-debit notification is sent at least 24 hours before the actual debit for recurring payments. Prevent creation of duplicate pending transactions with token for the same document because every transactions confirm after 24 hours. task - 4678509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce ================== - Use a mobile device/viewport - Go to any record with a chatter - Click on Log note - Expand the composer - Click on the template dropdown - Save the current content as a template with a long name - Open the dropdown again => The dropdown is almost entirely off screen Cause of the issue ================== The Dropdown component uses the usePosition hook. It works by doing the following: - It tries the fit the content using the position props (or it's default value) - If it doesn't fit, it tries the four other corners - If it's still doesn't fit, it gives up and uses the first one again Solution ======== Since we cannot show too much content inside a dropdown, we set a max-width on the dropdown content, and truncate the template names. Another possibility would be to allow an horizontal overflow. opw-4675320 opw-4674341 opw-4656725

### Steps to reproduce: - install fsm_industry - run any of these tests: - test_change_parent_plan - test_change_parent_plan_conflict - test_change_parent_plan_with_intermediate - test_change_plan - test_change_plan_conflict - test_change_plan_no_conflict #### > create access right error for the `account.analytic.line` model ### Cause of the issue: The following three record rules provide the creation of `account.analytic.line` for users related to project or timesheet access rights unless the analytic line it self is linked to a project: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L52-L64 https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L78-L83 Since the analytic module is unrelated to the project module, these tests will inevitably fail. ### Note: These record rules do not stop the record creation once the account module is installed since the following record rules override the creation access rights for `account.group_account_invoice` users: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/account/security/account_security.xml#L102-L107 Similar issue treated in commit 9d164c1d2cd8e532109b9859ab776fcf2f71d115 ### Note 2: A priori, the same problem would occur if we were to write post install analytic tests for portal users: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L50 ### Forward port additional fix (18.0): Since Commit 0e997470b7174a187c876d734e38f633223f65ec the test of the `TestAnalyticAccount` class are launched in sudo mode since the environment is set using OdooBot and never associated with an other user: https://github.com/odoo/odoo/blob/ed38752e55d6bafbc71fac3df249f226a4eba332/odoo/tests/common.py#L979 https://github.com/odoo/odoo/blob/4baf55a5d108063b0b60beddf332b6ae367f1871/odoo/api.py#L568-L571 In 17.0 the environment was reset to a non sudo mode by the user reassignement: https://github.com/odoo/odoo/blob/d2ea23f252f0f8f329e2b0ff96de6ee2a14b922f/addons/analytic/tests/test_analytic_account.py#L28-L31 In order for the tests to also check access rights we have added our own `setup_independent_user` in the `AnalyticCommon` class. runbot-160013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210001 Forward-Port-Of: odoo/odoo#208978

**Issue:** When selling a product with a tax-inclusive price to a customer who is tax-exempt (e.g., under a "Rest of the World" fiscal position with a 0% tax mapping), the Point of Sale displayed the tax-inclusive price instead of the correct tax-exclusive price. **Steps to Reproduce:** 1. Install the Sales, Point of Sale, and Accounting applications. 2. Create a product with a price configured to include taxes (e.g., a 20% VAT included in the sale price). 3. Create a customer and assign them a fiscal position that maps the product's default inclusive tax to a 0% tax (e.g., a "Rest of the World" fiscal position). 4. Create a fiscal position tax rule for the "Rest of the World" position, mapping the inclusive tax on the created product to a 0% tax. 5. Open the Point of Sale interface. 6. Select the customer created in step 3. 7. Add the product created in step 2 to the order. 8. Observe the total price displayed for the product. Expected Behavior: The Point of Sale should display the price of the product excluding the previously included tax, reflecting the 0% tax rate for the selected customer. Actual Behavior: The Point of Sale incorrectly displayed the original tax-inclusive price, even though the applied tax amount was shown as $0. **Root Cause:** The `get_tax_details` method calculates the base price (tax-exclusive) after the product's taxes have already been potentially remapped to 0% based on the customer's fiscal position. Consequently, when a product with an inclusive price is sold to a tax-exempt customer, the `total_tax_amount` becomes zero. The logic in `get_tax_details`,at line 368, that intends to adjust the base price when taxes are included doesn't trigger correctly because `total_tax_amount` is already zero, leaving the `raw_base` (which is derived from the tax-inclusive `price_unit`) unchanged. **Fix:** To resolve this, when preparing the base lines for tax computation, the code now detects if a product originally had a tax-inclusive price and if the effective tax rate has become 0%. In such cases, the `price_unit` of the order line is explicitly adjusted to its tax-exclusive value by reversing the original tax inclusion. This ensures that subsequent tax calculations and the final displayed price correctly reflect the tax-exempt status of the customer. Opw-4592602 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Steps to reproduce: 1. Create a portal user. 2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view 3. Now, add the portal user as a follower on a task. 4. Change the state of a task to execute an automation rule. 5. Email will be received by a portal user but it will not be visible on the messaging history on the portal. ### Cause: This is happening because when running an automation rule that will send an email we set the 'mail.message' state as System notification by default which leads that this mail will be sent normally to every follower of the record but will be only shown in the chat history for internal users not portal as we are just showing 'comment', 'incoming_email' and 'outgoing_email' messages. ### Fix: Checking if the server action that is being run is sending an email we will set the state of the 'mail.message' as 'auto_comment' -introduced in https://github.com/odoo/odoo/pull/94018/commits/d1dd307555ac78841384d1158de5a0a7787370db - and add 'auto_comment' to the domain of the field website_message_id which is for the messages shown to the portal user in his view P.S. LNA confirmed that we need to show it to the portal user. opw-4459754 Forward-Port-Of: odoo/odoo#210807 Forward-Port-Of: odoo/odoo#194401

**Problem:** when doing a refund from pos of an avco (or fifo) product, with the option "ship later" the cost of the product does not appear on the pos order line **Steps to reproduce:** - Enable Settings "Allow Ship Later", "Automatic Accounting" - Navigate to Sales/Configuration/Product Categories - Create a new category with Inventory Valuation field as "Automated" and the Costing Method field as "Average Cost (AVCO)" - Open Point of Sale/Product - Create a new storable product - In the general information tab set a cost and select your new category for the product category field - In the Sales tab, make sure that "Available in POS" is checked and select a category - Set an on Hand quantity - Open a point of sale from the Point of Sale Dashboard - Select your product and click on Payment - On the top right of the screen select a customer with an adress, click on Invoice and on Ship later - Select a payment method and validate - Navigate to Point of Sale/Orders - click on the last order created, and click on the "Pickings" smart button - validate the picking - come back to the store in point of sale - select the three horizontal lines on the top right and click on Orders - filter by paid orders - select the last order created and click on refund and then on payment - check Invoice and Ship Later on the top right, select a payment method and validate - Navigate back to Point of Sale/orders and select the last order created **Current behavior:** The total cost is zero on the pos order line Even if the delivery is validated via the Picking smart button the total cost is still zero **Expected behavior:** It should reflect the cost of the product (depending on the costing method) **Cause of the issue:** When the pos order is created from Point of Sale, the process_saved_order method is called this method calls (1)create_order_picking and then (2)compute_total_cost. https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/point_of_sale/models/pos_order.py#L183-L184 **Scenario A** Inside (1) create_order_picking, if the PosOrder doesn't have a shipping_date the if statement is False https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/point_of_sale/models/pos_order.py#L1017 and the method _create_picking_from_pos_order_lines is called. This method then calls _action_done. https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/point_of_sale/models/stock_picking.py#L70 Inside the stock_account override of _action_done, _create_in_svl is called. https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/stock_account/models/stock_move.py#L289 This method sets the value of the stock_valuation_layer_ids attribute of the stock move to a new stock valuation layer. **Scenario B** Inside (1) create_order_picking, if the PosOrder has a shipping_date (in the case where we selected "Ship Later") the method _launch_stock_rule_from_pos_order_lines is called. https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/point_of_sale/models/pos_order.py#L1017-L1018 and nowhere inside this method is _action_done called. This makes sense because the stock move hasn't been validated. When (2) compute_total_cost is then called by process_saved_oder, if the product category is avco, _compute_average_price will be called. If we are in Scenario B there is no stock valuation layer for this stock move. Consequently there will be no candidates and the price will not be computed. https://github.com/odoo/odoo/blob/504ef7cdeb1600b86feefbe8668144da9cd5a70b/addons/stock_account/models/product.py#L795-L798 opw-4614503 Forward-Port-Of: odoo/odoo#210459 Forward-Port-Of: odoo/odoo#207482

**Description of the issue/feature this PR addresses:** Sets aggregator=None on ir.cron's priority field since aggregating this by summing it up (sum is the default aggregator on Integer fields) gives us no useful information. Removing it has a very minimal performance improvement and would partly address the issue where this field's aggregated value clips over the grouped by field Prior to https://github.com/odoo/odoo/commit/3d9a6ac the width of the first column would be increased in case of grouping list views. This would make the label of the grouped field visible by expanding the first column. However after the mentioned commit, we restrict the min and max widths of the columns which leads to the value of this grouped by field getting clipped by the aggregated column's value. Although the issue primarily exists in 17.4, prior stable versions (16.0 and up) could also benefit from this. **Current behavior before PR:** In 17.4 onwards, the grouped field's table row is clipped by the priority field that gets aggregated ![image](https://github.com/user-attachments/assets/014208c5-74ad-4fb1-af9e-fc0f9ef007a1) ![image](https://github.com/user-attachments/assets/06d90eeb-7961-4e60-b4e8-ca823d2e23a7) **Desired behavior after PR is merged:** The priority field in `ir.cron` is no longer aggregated thus it does not clip the grouped field. ![image](https://github.com/user-attachments/assets/cd763f22-3e29-4bc6-9ae7-319b114dc7c1) opw-4536133 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209786 Forward-Port-Of: odoo/odoo#200943

Steps to Reproduce: --- 1. Create a tax with the following settings: > - Rate: 12% > - Price Included: True > - Affect Base of Subsequent Taxes: False. 2. Create another tax with the following settings: > - Type: Python Code > - Code: result = 22.503 > - Price Included: True > - Affect Base of Subsequent Taxes: False. > - Ensure the sequence of this tax is greater than the 12% tax (this tax is after the 12% tax in order). 3. Create a product with a sales price of 516.00 and assign both taxes to it. 4. Create a new invoice and add the product to the invoice. The total will show an extra 0.01 due to rounding. Cause: --- When applying price-included taxes with multiple taxes, the rounding difference is carried to the last tax to ensure the total matches the product's tax-included price. However, cached values for Python code taxes were used even for the last tax, preventing the rounding correction from being applied. Fix: --- An additional condition was added to ensure cached values are only used when there is no price total checkpoint, allowing the rounding correction to be applied to the last tax. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210413 Forward-Port-Of: odoo/odoo#207665

## Issue: When converting a lead to an opportunity, a wizard (`crm.lead2opportunity.partner`) is shown. This allows merging duplicated leads. However, if the most recently created lead is selected as the primary, the wizard record may be deleted unexpectedly. This usually goes unnoticed in the UI, as the wizard disappears after the operation. The issue becomes critical when overriding the conversion flow via a custom module or in future changes to the core logic. In those cases, the deletion of the wizard can lead to empty recordsets and errors. #### Affected versions: 16.0 and later. ## Explanation The `crm.lead2opportunity.partner` model has a `Many2one` field `lead_id` that is being deleting on cascade which is the default for m2o fields on transient models. During lead conversion, action_apply() calls _action_merge() or _action_convert(). In _action_merge(), non-primary leads are unlinked. If the primary lead is the last created one, it differs from the one referenced by the wizard. This causes lead_id to be unset, triggering the cascade and deleting the wizard. ## Impact: If a custom module overrides action_apply() or _action_merge() and calls super() first, it may operate on an empty recordset, leading to failures when trying to access data or call methods. ## To reproduce: With debugger: - Set a breakpoint on the unlink call inside _action_merge - After unlink, calling self.exists() on the wizard will return an empty recordset With a custom module: - Override action_apply() or _action_merge() - Call super() first - Try to merge leads and select the most recent one as primary - The wizard record will be deleted before your custom logic executes, and will raise a "Record does not exist or has been deleted." OPW-4773172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209795

Improvements(3)

[IMP] certificate, l10n_es_edi_*: Factor patched HTTPAdapter for certificates models

[IMP] account: change payment state tag colors for better UX clarity

[IMP] payment_razorpay: Restrict multiple pending tokenized transactions for same document

Bug Fixes(17)

[FIX] mail: keep composer template dropdown in viewport

Other(29)

[FW][FIX] analytic: runbot build error industry_fsm single app tests

Improvements(3)

[IMP] certificate, l10n_es_edi_*: Factor patched HTTPAdapter for certificates models

[IMP] account: change payment state tag colors for better UX clarity

[IMP] payment_razorpay: Restrict multiple pending tokenized transactions for same document

Bug Fixes(17)

[FIX] mail: keep composer template dropdown in viewport

Other(29)

[FW][FIX] analytic: runbot build error industry_fsm single app tests

[FIX] mail: prevent badly generated message_id in tests

[FIX] point_of_sale: correctly display the price for tax-exempt customers on products with tax-inclusive pricing

[FIX] l10n_in: remove onchange for gst treatment field

[FIX] mail: prevent iframe removal in email templates by disabling video

[FIX] l10n_it_edi: branches share the Proxy User settings with their root company

[FIX] account : Change memo prefix in group payment

[FIX] purchase: can't delete sections and notes even editable

[FIX] website_slides: avoid horizontal scroll on small screen

[FIX] project: prevent error when no suggested partners are returned

[IMP] l10n_de: add check if audit_trail feature is activated

[FIX] l10n_my_edi: add safeguard on dictionary read

[FIX] account: move report name should match report

[DRAFT][FIX] appointment_account_payment: fixed ValueError when click on Paid Seat

[FIX] l10n_mx_edi: ignore bin_size when uploading edi xml to read it correctly

[FIX] account_iso20022: support pain.001.001.09 for ISO20022

[FIX] l10n_cl_edi: fix error when clicking Send now to SII button

[FW][FIX] website: add_page_dialog component may be destroyed while loading

[FW][FIX] mail : Show mails from automation rules in portal view

[FW][FIX] l10n_es_edi_sii, l10n_es_edi_tbai: allow resequencing vendor bills

[FW][FIX] website_sale: inherit website salesperson domain in settings

[FW][FIX] point_of_sale: compute cost of delayed shipped refund avco/fifo

[FW][I18N] l10n_cz: update translations

[FW][IMP] base: do not aggregate interval, priority in ir.cron

[FW][FIX] account: resolve rounding issue with price-included tax cache

[FW][FIX] l10n_fr: fix rounding and sum issues

[FW][FIX] l10n_it_edi: export non-EU VAT number

[FW][FIX] web: list: recompute column widths when width changes

[FW][FIX] web_editor: fix caret navigation with mixed nodes

[FW][FIX] partner_autocomplete: Prevent unnecessary input field display for Mobile

[FW][FIX] sale_loyalty: preserve custom discount line description on SO Confirmation

[FW][FIX] account: correct expression syntax for field invisibility

[FW][FIX] crm: avoid cascading crm.lead2opportunity.partner wizard

[FW][PERF] product_product: avoid injecting ids in product name_search

[FW][FIX] account_reports: negative analytic in deferred revenue

[FW][FIX] delivery_{ups_rest, sendcloud}: let Amazon get the expected carrier's type

[FW][PERF] helpdesk_timesheet: Prevent OOM on module install

[FW][IMP] l10n_lu_reports: Added translations for annual VAT report

[FW][FIX] hr_payroll: use local times for payslip attendance

[FW][I18N] l10n_cz_reports{_2025}: update translations

[FW][FIX] helpdesk : Show mails from automation rules in portal view

[FW][FIX] sign: fix missing linked record in sign request from activity

[FW][WIP][IMP] l10n_ke_hr_payroll: show NSSF report computed amount

[FW][FIX] l10n_mx_edi: includes note/section in invoice copy

[FW][FIX] hr_referral: Reset referral state when reprocessing applicant.