Thursday, December 4, 2025
17 changes · saas-18.3
Enhancements to existing features
This update enhances the ability to retrieve information related to signed documents (o2m relationships) within the Odoo Enterprise system. Previously, limitations prevented accessing additional data from these relationships, now customization is enabled. This allows for more comprehensive tracking and reporting of signed transactions.
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
This update prevents the import process from changing existing journal names. Previously, importing journal data would overwrite the names of existing journals, causing confusion and potential data discrepancies. The fix ensures journal names remain consistent during import, 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 confusing error message related to Acerta codes in the Belgian payroll system. The original message was unclear, leading to potential user confusion. The fix replaces the message with a clear and concise instruction: 'The following work entry types have an Acerta code that is not between 3 and 6 characters'.
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 ensures that calendar invitation emails are sent using the email address defined in the meeting template, rather than defaulting to the organizer's email. Previously, if the template's 'email_from' field was blank, the invitation would use the organizer's email. This change improves email personalization and accuracy.
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
This update corrects a previous issue where users could select time off types without allocation requirements within group allocation settings. The change ensures that only time off types requiring allocation are displayed, aligning with the standard allocation process and preventing incorrect time off requests. This improves data accuracy and simplifies the allocation workflow.
Original PR description
To reproduce: ============= - Create time off tyoe that does not require allocation - Go to timeoff > Allocation > Group allocation -> you can select the created time off type Problem: ======== we didn't have a domain on `holiday_status_id` field, so all time off types were available for selection. Solution: ========= Add a domain on `holiday_status_id` field to only show time off types that require allocations the same way as when creating a single allocation. opw-5113959 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228617
This update fixes an issue where vehicles marked for change (but with a 'no change' flag set) were incorrectly shown as available. The change ensures that vehicles slated for a change are accurately identified as unavailable, improving the reliability of vehicle availability reporting. This impacts how vehicles are tracked for 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 problem where the tax upgrade script incorrectly translated strings based on the local Odoo environment's language. This caused errors when the script attempted to access translated values in the wrong language. The fix ensures consistent translation across all Odoo environments.
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#238368This update fixes an issue where zero margin and spacing overrides in report design were being ignored. Now, users can accurately set all margins and spacing to zero, providing greater control over report output. This ensures reports are generated as intended, regardless of specified margin values.
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 update resolves an issue where the ChatGPT plugin button was disabled when no text selection was made in the HTML editor. Now, the button correctly opens the chat window with either the standard AI buttons or a simplified version without AI buttons, depending on whether a text selection is present. This ensures consistent and reliable access to the ChatGPT plugin.
Original PR description
This PR fixes an issue with the toolbar button. Before when no selection were applied in the HTML Editor, the button would be disabled.
This PR introduce a fix that makes the button enabled in two scenarios:
- Either the user has no selection, clicking the button will then open the chat window without any AI button, as it does with the powerbox buttons,
- Or the user has a selection, then clicking the button will result in opening the chat window with the AI buttons as it was already the case.
If the user has a selection that is empty, then the button remains visible but is disabled.This update fixes a technical issue in the product configurator that caused errors when multiple product attributes were linked together. The change ensures that all product attributes are correctly mapped, regardless of whether they share the same underlying attribute, leading to a more reliable and accurate product configuration experience.
Original PR description
Description of the issue/feature this PR addresses: When multiple `product.template.attribute.line` records reference the same `product.attribute`, the product configurator raises a `KeyError` at…
Description of the issue/feature this PR addresses:
When multiple `product.template.attribute.line` records reference the same `product.attribute`, the product configurator raises a `KeyError` at line 321.
Root cause: `ptals.attribute_id` returns a unique recordset (Odoo deduplicates), so `zip(ptals.ids, ptals.attribute_id.read(...))` produces fewer entries than expected when attributes are shared across lines.
```python
# Before: zip stops at shorter list, missing entries in attrs_map
attrs_map = dict(zip(ptals.ids, ptals.attribute_id.read(['id', 'name', 'display_type'])))
# After: preserve 1:1 mapping by iterating each ptal
attrs_map = {ptal.id: ptal.attribute_id.read(['id', 'name', 'display_type'])[0] for ptal in ptals}
```
Current behavior before PR:
`KeyError` raised when accessing `attrs_map[ptal.id]` for attribute lines whose ID was truncated by the `zip`.
Desired behavior after PR is merged:
Product configurator correctly maps all attribute lines regardless of whether they share the same underlying attribute.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238292A test within the Odoo Enterprise payroll module was failing due to a missing default account configuration when no demo data was present. This update adds a default account to the test environment and adjusts the accounting rules to ensure the test runs successfully, maintaining the stability of the payroll system.
Original PR description
Steps to reproduce: Install hr_payroll_account on a fresh db without demo data. Run the test test_payment_hr_payslip. The test fails. Cause: With demo data, the us payroll was installed and with it, the payroll accounts were configured. Without demo data, default account is missing. Fix: Add a default account in the test and fix the amount balance with a new debit rule to balance the credit one. Task: 5386528 Runbot Error: 161615
This update corrects a visual issue where the activity badge within the bank reconciliation widget was misaligned. The change removes a styling class that was causing the misalignment, ensuring the badge now appears correctly positioned on the icon. This improves the user experience and visual consistency of the bank reconciliation feature.
Original PR description
Current behavior before PR: The activity badge inside the bank reconciliation widget was misaligned, <img width="55" height="60" alt="image" src="https://github.com/user-attachments/assets/0f99ea55-fedd-401a-a65e-226296070e32" /> Desired behavior after PR is merged: The activity badge now sits in the correct position on the icon. <img width="62" height="55" alt="image" src="https://github.com/user-attachments/assets/abf96aed-73d4-4153-8e0a-56937d4ff08a" /> Changes implemented: - Removed `fa-fw` class. - Removed the unnecessary 'fa-fw' class from comment and paperclip icon. task-5354994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where users could modify approval requests, which could lead to unpredictable behavior within the system. The change prevents edits to approval requests, ensuring data integrity and a stable approval process. This improves system reliability.
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#101132 Forward-Port-Of: odoo/enterprise#100273
This update ensures the NIF (tax identification number) is correctly included in the BOE export for model 347 reports, as required by Spanish tax regulations. Previously, the system only included VAT if it started with 'ES'. Now, the system reads the VAT regardless, but relies on the user to provide a valid VAT number for the company.
Original PR description
[FIX] l10n_es_reports: include NIF in boe export for model 347 The NIF must be included in the BOE export for modelo 347 https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos/347.pdf pages 3 & 12. Before this commit, we read the vat but if it doesn't start with 'ES' we return an empty string because we based on TIN. Now we'll read the vat (without 'ES' if it starts with it). The user is responsible to fill a correct number in the vat field of the company. opw-5207241 Forward-Port-Of: odoo/enterprise#100489
This update prevents a critical error during field creation when users enter invalid domain values. The fix wraps the domain evaluation process in a try-except block, gracefully handling errors and displaying a helpful message to the user. This ensures a smoother user experience and prevents data creation failures.
Original PR description
Currently an error is generated when the user tries to create or write fields with wrong domain. Steps to produce an error - Install sale_management and create a new field with the below detail -…
Currently an error is generated when the user tries to create or write fields
with wrong domain.
Steps to produce an error
- Install sale_management and create a new field with the below detail
- Model: `Sales order`
- Field Type: `one2many`
- Related Model: `sale.order`
- Relation Field `partner_id`
- Domain: `[('sale_order_id', 'in', sale_order_ids)]`
- Click on save
This error occurs because we have a constraint in the domain, and it is triggered
when the user modifies the domain at code line [1]. Inside this constraint, we use
`safe_eval` to evaluate the domain. During this evaluation, an error is raised because
the user entered an incorrect domain.
This commit fixes the above issue by wrapping `safe_eval` inside a `try–except`
block and raising a `ValidationError` with an appropriate message when an error occurs during domain evaluation.
[1]- https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/odoo/addons/base/models/ir_model.py#L651-L654
sentry-6964956583
Forward-Port-Of: odoo/odoo#237937
Forward-Port-Of: odoo/odoo#236891This update fixes an issue where form fields without labels were not being submitted correctly. Now, all form fields, even those without labels, are properly captured and sent when the form is submitted. This ensures data is consistently collected from website forms.
Original PR description
Before this commit, a form input without a label would not send its data when clicking send. Steps to reproduce - go to the website editor - add a form - choose any field - delete the field label - save and exit the editor - now in the website, fill the form and click send => the fields without a name label are not sent After this commit fields without a label get sent with a placeholder "unknown_field" task-5062575 Forward-Port-Of: odoo/odoo#237805 Forward-Port-Of: odoo/odoo#225545
This update ensures Odoo automatically updates remaining modules in the database, regardless of how Odoo is started. Previously, this only worked when Odoo was launched with specific command-line arguments. This change adds a configuration setting to trigger the automatic update process, improving database consistency and stability.
Original PR description
In https://github.com/odoo/odoo/pull/216025, we force auto upgrade of modules remaining in the database when `preload_registries` is called. However, this strategy doesn't work if Odoo is not started with the `-d` argument, because `preload_registries` is only called for databases specified in the `-d` argument. This commit fixes the issue by adding a special record in `ir_config_parameter` with key `base.partially_updated_database` to indicate that the next time `Registry.new` is called, it should force auto upgrade of modules remaining in the database. 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#238320