Wednesday, December 3, 2025
14 changes · 18.0
Resolved issues and error corrections
A minor typo in the SEPA Direct Debit payment provider configuration has been fixed. The message displayed to users now uses the correct grammatical form ('a unique' instead of 'an unique'), ensuring consistent and professional communication. This change improves the overall user experience.
Original PR description
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate…
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit. - Open the `Messages` tab and observe the `Pending Message`. **Observation:** The message uses "an unique" instead of the grammatically correct "a unique". **Fix:** This commit corrects the message by replacing "an" with "a" at [1]. Before: <img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" /> After: <img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" /> [1]: https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13 opw-5373274 Forward-Port-Of: odoo/enterprise#100983
This change adjusts Odoo's VAT processing to accommodate a wider range of testing VAT codes provided by our EDI partner. Previously, we only supported specific VATs, but now our partner offers a more comprehensive testing range. This update ensures seamless integration with the EDI system, improving data accuracy for VAT calculations.
Original PR description
When we merged EDI for Guatemala we allowed two specific testing VATs [1]. Because our EDI is proving popular our EDI provider has now created a specific range of testing VATs just for Odoo. We allow them explicitly because they're not valid VATs. [1] 6ef9c1085cd648ad2bbd78caf4a83fe30c969d59 opw-5381791
This update fixes an issue where buttons within the image field were not vertically centered. The change uses SCSS flexbox to reliably center the buttons, ensuring a consistent and professional appearance. This was implemented in SCSS for easier maintenance and to accommodate potential variations in the component's design.
Original PR description
The buttons in image_field are not centered vertically. Since it's a custom sized button, using flex is reliable (it's now centered on both flex axis). Note: Done in SCSS instead of utilities because the flex is there to compensate the custom size set in SCSS (easier to maintain) + there could be injected buttons in the component. task-5258887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235964
This update resolves an issue where users were unable to set invalid data types (like numbers) as default values for fields within customer records. The fix ensures that users cannot enter incorrect data, maintaining data integrity and preventing potential errors in reporting and business processes. This improves data reliability.
Original PR description
Steps:
- Create a user defined defaults value
- Model: res.partner
- Field: date
- Value: 1
- Create a new contact
Actual result:
- invalid field type
- 'int' object is not subscriptable (depends of field type)
Expected result:
- No error
- User is not able to put an invalid value as a default
task-3729963
Forward-Port-Of: odoo/odoo#225991This update resolves an issue where the Odoo application remained listed as installed after uninstalling on Windows. The fix ensures the uninstaller correctly removes the necessary registry keys, preventing persistent entries in the installed software list. This improves the user experience and simplifies application management.
Original PR description
Since d0d0fa2b8e the Windows installer only supports 64 bit version of the OS. It was recently noticed that when uninstalling the app with the provided uninstaller that the app remains listed in the installed software. Although the directories and third party apps were correctly cleaned and removed. The reason is that the Odoo app registry key is still present after the uninstall process. When a 32 bit process tries to write a registry key in `HKLM\SOFTWARE` it's redirected by the OS to `HKLM\SOFTWARE\WOW6432Node`. By using the `SetRegView 64` NSIS directive, the installer writes the registry key at the right place ... but the uninstaller is lacking that directive and thus tries to remove a non existing key in `HKLM\SOFTWARE\WOW6432Node`. With this commit, the uninstaller is fixed by using the directive too. Forward-Port-Of: odoo/odoo#238476
This update adds a test helper function to the Odoo spreadsheet module. This enhancement simplifies the process of adding new rows during testing, ensuring more robust and reliable test coverage. This change improves the overall quality and stability of the spreadsheet 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
This update resolves an issue where field syncs in the Quote calculator spreadsheet would disappear after inserting a new row. The fix ensures that field syncs are correctly maintained when rows are added, preventing data inconsistencies and improving spreadsheet functionality. This ensures accurate data transfer between the spreadsheet and Odoo.
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
This update ensures that calendar invitation emails are sent using the specified email address from 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 clarity and consistency.
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
This update prevents the import process from unintentionally changing the names of existing journal codes. Previously, importing data would overwrite journal names with the values from the import file, causing confusion and potential data inconsistencies. This fix ensures journal names remain accurate and stable during the import process.
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
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 message has been updated to clearly state the required code length (3-6 characters), improving accuracy and ease of use for payroll administrators.
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
This update resolves an issue where users were unexpectedly redirected back into the sign flow after completing a document signature. The fix ensures users are correctly returned to the original record (like an Offer or Invoice) without lingering 'Sign' breadcrumbs, improving navigation and user experience.
Original PR description
Issue:
- After signing a document, the user is redirected to the correct
record form (e.g., Offer, Invoice) but an extra "Sign" breadcrumb
remained in the navigation.
- Clicking that breadcrumb sent the user back into the sign flow,
creating confusion and breaking the expected navigation behavior.
Fix:
- Updated the close flow in the thank you dialog to use
`stackPosition: "replacePreviousAction"` when a reference document
exists, ensuring the sign dialog controller is removed cleanly.
- Fallbacks use `clearBreadcrumbs` when no reference document is
linked (standalone sign documents).
- This restores correct breadcrumb generation across all sign flows.
Impact:
- Users return to the proper parent record without leftover sign
breadcrumbs.
- Prevents unexpected navigation back into the sign request.
Task: 5175992This update resolves a test failure related to shop floor record updates after user changes. The fix introduces a two-step process, ensuring the system has fully updated records before verifying their presence. This enhances the reliability of the test and, consequently, the overall stability of the work order filtering functionality.
Original PR description
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps:…
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps: https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L177-L190 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L196-L206 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L212-L221 This happends since changing the user requires some time to display the related shopfloor records, but the steps check the number of visible records as soon as it has switched rather than when it is sure that the records are displayed. #### Fix: Since switching employees will first empty the recordset and later display the related records, we can split the steps in two. We first check that we switched users, then we check the existence of a record that is not present for the previous user, and only then perform the related checks. #### runbot-226734 Forward-Port-Of: odoo/enterprise#100746
This update resolves a build error related to the demo company setup in the Odoo Marathi localization (l10n_mr) module. A recent change in Odoo required explicitly defining `install_demo` as True to avoid a warning about incorrect registry usage. This ensures the module builds correctly and prevents potential issues during installation.
Original PR description
Since https://github.com/odoo/odoo/commit/c8f5e26ac28f0110d4f1c131d3393c0d4bf0a2f2 , try_loading of demo companies requires `install_demo` to be explicitly defined as True. Otherwise, we get the warning `Incorrect usage of try_loading without a fully loaded registry. This could lead to issues.` Fix build error: https://runbot.odoo.com/odoo/runbot.build.error/234524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a minor issue by ensuring that default Incoterms aren't automatically applied to bills. Bills represent invoices from third-party vendors, who may use different trade terms. This change ensures accurate representation of vendor-supplied pricing.
Original PR description
Incoterms are usefull to indicates the rules and terms in sale contracts. It makes sense to add the company default on invoices, but not on bills, as those originate from another vendor than us, who can use different rules. opw-5169146 Forward-Port-Of: odoo/odoo#236709