Wednesday, September 10, 2025
14 changes · saas-18.2
Enhancements to existing features
The Peppol registration wizard now includes clearer help text explaining what the requested registration details are used for. This helps businesses complete the setup with more confidence and fewer support questions.
Original PR description
…ion wizard. Give move information on what the registration information are used for. task-none Forward-Port-Of: odoo/odoo#225730
Resolved issues and error corrections
Imported French FEC accounting entries will now show up when users open a sales journal from the accounting dashboard. This prevents missing imported records in journal views and helps accounting teams review migrated or imported data more reliably.
Original PR description
**PROBLEM** When importing a FEC files, moves are created with the `move_type` `entry`. They don't appear in the action of the journal of type `sale` when clicking on the dashboard. **STEP TO REPRODUCE** 1. on a local database install `l10n_fr_fec_import` (you need to import a FEC file given by our client, dont do it on the runbot please !) 2. select the french demo company 3. import the FEC file (accounting/settings/import a file) (for file, see [ticket](https://www.odoo.com/odoo/project/49/tasks/4848763) ) 4. goes in the dashboard, and click on the `Ventes Marchandises` journal. 5. notice the entries does not appear in the action. **CAUSE** When importing a FEC file, all moves are created with the `entry`. The domain for `sale` journal doesn't include the move of type `entry`. **FIX** Adding `entry` in the `sale` journal domain. opw-4848763 Forward-Port-Of: odoo/odoo#222208
Code cleanup and technical improvements
This update adds extension points that let businesses tailor which overdue and upcoming payment lines appear on customer follow-up reports. It helps companies adapt payment reminders to their communication needs without changing the core report behavior.
Original PR description
The goal with these hooks is to allow customization of overdue and due lines that are going to be printed on the followup report to be communicated to the customer. Forward-Port-Of: odoo/enterprise#93438
This fixes a messaging issue where an error warning could remain visible after messages successfully loaded on retry. Users will now see the correct thread status after reconnecting or retrying, reducing confusion in conversations.
Original PR description
**Description of the issue this PR addresses:** When a thread fails to fetch its messages (e.g., due to a network error), the `hasLoadingFailed` flag is set to `true`. However, even if the next fetch…
**Description of the issue this PR addresses:** When a thread fails to fetch its messages (e.g., due to a network error), the `hasLoadingFailed` flag is set to `true`. However, even if the next fetch attempt succeeds, the flag is not reset. As a result, the UI may continue to show an error state even though the data has successfully loaded. **Steps to Reproduce:** - Open a thread with many messages. - Go offline. - Scroll up to load older messages → failure message appears. - <img width="311" height="68" alt="image" src="https://github.com/user-attachments/assets/e18832cb-5d37-4add-a126-fdc301131721" /> - Go back online and click Retry → messages load successfully. - Scroll again → failure message still appears, even though you’re online. - <img width="311" height="68" alt="image" src="https://github.com/user-attachments/assets/e18832cb-5d37-4add-a126-fdc301131721" /> **Current behavior before PR:** After a failed attempt to fetch messages in a thread, the `hasLoadingFailed` flag remains set to `true`. Even if the user goes back online and the subsequent fetch succeeds, the UI continues to show a failure state. **Desired behavior after PR is merged:** After a successful fetch of a thread’s messages, the `hasLoadingFailed` flag is reset to `false`, ensuring the UI no longer shows a failure state once the data has been correctly loaded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222001
When a payment memo is edited, the related accounting entry reference is now updated to match. This keeps payment and accounting records consistent and avoids confusion during reconciliation or review.
Original PR description
Issue: In previous versions, the memo field of account payments and ref field of account move were related Now that payments do not required to have generated account move's when the memo is updated the ref remains unchanged. Purpose of this PR: To update the account move ref when the payment memo is updated. Steps to Reproduce on Runbot: install accounting go to bank account and assign outstanding accounts for manual payment methods create a payment -- a related account move should be created update the memo on the payment -- the ref on the related account move is unchanged. opw-4989260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223459
The Spanish Modelo 130 report now uses a single end-date selection instead of a date range. This prevents users from expecting a custom range while the report actually calculates from the start of the fiscal year, reducing confusion in tax reporting.
Original PR description
Currently mod130 report is configured to compute from the beginning of the fiscal period, however the date filter widget is in range mode. This means that when a user open the report and select a date range, the entries will not be just in the selected range but span from the beginning of the fiscal year to the end of the range, creating confusion. We should disable filter date range, so the date widget allow to set an end date to the current period Enterprise PR: https://github.com/odoo/enterprise/pull/90044 opw-4933241 Forward-Port-Of: odoo/odoo#218544
Fixed an issue that could prevent Indian electronic invoices from being sent correctly. This helps businesses using India localization avoid failed invoice submissions caused by an internal data handling error.
Original PR description
In this commit- --- Fixed a typeError in l10n_in_edi_send_invoice method Replaced - incorrect syntax `data.get['SignedInvoice']` with `data['SignedInvoice']`. opw-5071703
Vendor price lists created from blanket orders now use the unit of measure from the blanket order line instead of defaulting to the product's base unit. This helps purchasing teams avoid pricing mismatches when ordering in different units.
Original PR description
This commit fixes setting the UoM of the vendor pricelist generated by a blanket order. Previously, the created pricelist had the base unit of the product. Now, it has the unit of the blanket order line. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds or adjusts automated checks for Spain's Modelo 130 tax report to help ensure the report continues to work correctly. It reduces the risk of regressions in Spanish tax reporting without changing day-to-day user workflows.
Original PR description
opw-4933241 Forward-Port-Of: odoo/enterprise#93755 Forward-Port-Of: odoo/enterprise#90044
In the Belgian salary configurator, choosing a private bike with a reimbursement amount now automatically clears and disables fuel card fields. This prevents employees from selecting incompatible mobility benefits and helps keep salary package calculations accurate.
Original PR description
The Belgian salary configurator allows employees to declare a private bike cost. When the "Private Bike" option is checked and its reimbursement value is greater than zero, the fuel card inputs must be reset to 0 and disabled. task-5062963 Forward-Port-Of: odoo/enterprise#94063 Forward-Port-Of: odoo/enterprise#93884
Belgian payroll work entry UCM codes now preserve spaces so the code remains the required three characters long. This prevents valid codes such as "PR " from being shortened when users leave and return to the field, helping payroll exports match UCM specifications.
Original PR description
#### Issue: - UCM work entry code should be 3 characters long and allow spaces to get this length #### Step to reproduce: - In a Belgian company - Go to Payroll > Settings > Work Entry Types > New - Add a name - Add a Payroll Code - In the `Country` field fill Belgium - In the field `UCM Code` enter "PR " - Select another field - Select `UCM Code` again #### Current behavior: - The field `UCM Code` was updated to "PR" #### Expected behavior: - The field should stay to "PR " #### Solution: - Don't trim the field and add a spaces if needed opw-5014372 Forward-Port-Of: odoo/enterprise#92838
This fix prevents Uruguayan electronic invoices from failing when an invoice line has no product and no line description. In those cases, the system now safely sends a default placeholder instead of blocking CFE document creation.
Original PR description
This pull request makes a minor adjustment to the logic for extracting item names and descriptions in the `_l10n_uy_edi_get_line_nom_and_desc` method. The change ensures that the presence of `aml.name` (the line description) is checked directly, rather than relying on the truthiness of the entire `aml` object. Before this PR, if the aml of an invoice only have the `account_id` field filled and no `product_id`, the `_l10n_uy_edi_get_line_nom_and_desc` will raise an error message like `TypeError: 'bool' object is not subscriptable` when trying to create de CFE document. <img width="1254" height="828" alt="image" src="https://github.com/user-attachments/assets/eaadad4c-46c3-4e3b-be52-9fcd146f2c22" /> <img width="1526" height="795" alt="image" src="https://github.com/user-attachments/assets/1b831f41-9774-4ed5-9a9d-9777ee0633e9" /> With this fix, we ensure there is a name to grab or the '-' will be send instead. Forward-Port-Of: odoo/enterprise#93838
The Documents kanban view no longer shows an unnecessary second scroll bar. This makes navigating document boards smoother and avoids visual clutter for users.
Original PR description
This commit fix the useless double scroll bar in kanban view. Task-4844661 Forward-Port-Of: odoo/enterprise#90548
Fixed an issue where clicking outside the Publish toggle in a dashboard header could accidentally reverse the publish setting. This makes publishing behavior more predictable for users editing dashboards.
Original PR description
**Steps to reproduce:** - Open a dashboard in edit mode. - Click the “Publish” toggle to change its state. - Click elsewhere on the header (outside the toggle). → The publish state flips back unexpectedly. **Before this PR:** The wrapper container (.o_sp_publish_dashboard) had a click handler, causing clicks on the header to re-toggle the publish state. The CheckBox was rendered with a no-op onChange, so both elements competed for control. **After this PR:** Interaction is handled exclusively by the CheckBox component. toggleDashboardPublished is bound directly to its onChange. Clicking the label text now correctly toggles the checkbox and publish state. Container clicks outside the checkbox no longer affect the state. Task: [5062368](https://www.odoo.com/odoo/project/2328/tasks/5062368) Forward-Port-Of: odoo/enterprise#94061