Thursday, December 4, 2025
11 changes · saas-18.2
Enhancements to existing features
This update enhances the system's ability to retrieve information related to signed documents. Previously, limitations prevented accessing additional data from the 'sign.send.request.signer' model when working with many-to-many signers. Now, customization is enabled, allowing for more comprehensive data retrieval, improving sign management workflows.
Original PR description
The class `SignerX2Many` is inheritable, but if we need another value from the o2m, we can't use it because the `signerX2Many` is not exportable. Enable `signerX2Many` customization, allowing more fields to be read from the `sign.send.request.signer` model. Forward-Port-Of: odoo/enterprise#99977
Resolved issues and error corrections
Calendar invitation emails now respect the sender configured on the meeting invitation email template. This ensures recipients see the intended sender, while still falling back to the organizer or current user when no template sender is set.
Original PR description
Problem: The `email_from` field of the mail template is not considered while sending calendar invites. Steps to reproduce: - Log in as admin and install `calendar`. - Open the email template named `Calendar: Meeting Invitation`. - Change the `email_from` to `"ABC" <abc@example.com>`. - Create an event with the admin as the organizer. - Add Marc demo as an attendee. - Check the invitation email: the email to Marc demo is sent by the admin instead of ABC Solution: The `email_from` field of the mail template is rendered and passed to `message_notify`. If the rendered value is empty, `None` is passed so that `_message_compute_author` computes a fallback using the `author_id`’s email (i.e. calendar event organizer or current user), ensuring the email is always sent with a valid sender. Task-5082075 Forward-Port-Of: odoo/odoo#228018
The Indonesian localization upgrade now uses English consistently when recalculating tax information. This prevents upgrade failures caused by mixed-language tax labels, improving reliability for companies upgrading databases with Indonesian accounting settings.
Original PR description
The script triggers a recompute of tax.repartition_lines_str, a tracked field that contains translated strings[^2]. If the local script is running in a different language as the rest of the upgrade,…
The script triggers a recompute of tax.repartition_lines_str, a tracked field that contains translated strings[^2]. If the local script is running in a different language as the rest of the upgrade, those strings will be translated in different languages and will trigger an error[^1] when they cannot be accessed in the dict. This can also fail during a local upgrade, not necesarily during an upgrade in the platform.
```
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Akun'
```
[^1]:https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/account/models/account_tax.py#L423
[^2]:https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/account/models/account_tax.py#L393-L397
Forward-Port-Of: odoo/odoo#238368Reports generated as PDFs now correctly respect settings that intentionally set margins or header spacing to zero. This prevents unwanted default spacing from being added, giving businesses more accurate control over report layouts.
Original PR description
When constructing the wkhtmltopdf command arguments, the system retrieves values from the `specific_paperformat_args` dictionary using get and checks whether the returned value is falsy. Because 0 is a falsy value in Python, margin and header spacing values explicitly set to 0 are mistakenly ignored. As a result, the system incorrectly falls back to the default paperformat values instead of honoring the overrides provided in `specific_paperformat_args`. This commit updates the conditional checks so that values from `specific_paperformat_args` correctly override the paperformat defaults even when the override is 0. This allows users to intentionally remove all margins and spacing defined on the report. Task-5079740 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237284
This change adds an internal helper used by automated tests to add spreadsheet rows more easily. It supports better test coverage for spreadsheet behavior, reducing the risk of issues reaching users, but does not change day-to-day product functionality.
Original PR description
This commit adds a test helper to add a row. See enterprise PR Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238293
This update prevents the system from accidentally changing the names of existing journals during the import process. Previously, importing journal data would overwrite existing journal names with values from the import file. This fix ensures that existing journal names are preserved, maintaining data integrity.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Go to **Accounting > Configuration > Settings**. * Download the **Import Journal Items** template. * Keep the default journal codes in…
**Steps to reproduce:** * Install the **Accounting** module. * Go to **Accounting > Configuration > Settings**. * Download the **Import Journal Items** template. * Keep the default journal codes in the template (e.g. *MISC*, *SAL*, *BNK*). * Import the file containing these existing journal codes into it by **Accounting > Configuration > Settings > Initial Setup > Import > Import Journal Items > Upload data file**. **Observed behavior:** * Existing journals have their names overwritten by the values provided in the import file. * For example, a journal with code **MISC** and name *Miscellaneous Operations* is updated to name **MISC** after import. **Cause:** * Journals are looked up by their `code`, but `_load_records()` passes both `name` and `id` for all rows. * As a result, existing journals are updated instead of preserved. **Fix:** * Pass only `id` for journals already found by code. * Pass `name` only when creating new journals. * This prevents unintended updates to existing journal names. opw-5345876 Forward-Port-Of: odoo/enterprise#100143
This update fixes a minor issue in the Belgian payroll module (l10n_be_hr_payroll_acerta) related to the error message displayed when an Acerta code is invalid. The message has been clarified to be more user-friendly and accurate, ensuring users receive clear guidance on code length requirements. This improves the overall user experience and reduces potential confusion.
Original PR description
Steps to reproduce: 1. Install l10n_be_hr_payroll_acerta 2. Switch to a Belgian company 3. Go to Payroll → Configuration → Work Entry Types 4. Edit a record and enter an Acerta code with only 2 characters Issue: - The validation message is missing a space between `that` and `is` - The message wording is ambiguous (PO request - fdav) Fix: - Updated the validation message to: `The following work entry types have an Acerta code that is not between 3 and 6 characters` opw-5347488 Forward-Port-Of: odoo/enterprise#100432
This update prevents users from modifying existing approval requests. Allowing edits would have caused unpredictable behavior and potential errors within the system. This change ensures the integrity and reliability of the approval process.
Original PR description
There is no legitimate use case that should modify the approval request. This would result in unexpected behaviour. task-5269982 Forward-Port-Of: odoo/enterprise#101051 Forward-Port-Of: odoo/enterprise#100273
This update corrects a minor issue in how vehicle availability is determined, specifically for vehicles undergoing a change. It now correctly excludes vehicles with a 'plan_to_change' flag set to 'False', ensuring accurate availability reporting. This ensures the system accurately reflects vehicle status for payroll and fleet management.
Original PR description
Refine _get_available_vehicles_domain to consider only vehicles with plan_to_change_car or plan_to_change_bike set to True as available. This ensures vehicles planned for change but marked False are treated as unavailable. Related task: 4963484. Forward-Port-Of: odoo/enterprise#101014 Forward-Port-Of: odoo/enterprise#90812
This update resolves a bug where field syncs would disappear after inserting a new row in the Quote calculator spreadsheet. The fix ensures that field syncs are correctly maintained when expanding the spreadsheet, preventing data inconsistencies. This improves the reliability of quote calculations.
Original PR description
Steps to reproduce: - create a Quote calculator spreadsheet - add a field sync on A1 - autofill it down on a few cells - select row B - right click and "Insert row above" => some field syncs disapeared Forward-Port-Of: odoo/enterprise#101066
This update simplifies the appointment calendar by showing only one period (day, week, month, quarter, or year) at a time, instead of three. This change reduces visual clutter and provides users with a clearer view of their appointments. It addresses an issue of overwhelming users with excessive information.
Original PR description
This PR displays one period of the requested scale (day, week, month, quarter and year) in the calendar instead of three. It avoids displaying unwanted periods and overwhelming users with information. Task-5022091