Wednesday, September 3, 2025
14 changes · saas-18.3
Enhancements to existing features
Payment memos are now shorter and focus on the transaction reference, with the payment provider transaction ID added when relevant. This removes extra customer details from the memo, making bank reconciliation easier and more reliable.
Original PR description
WIP no-task
Resolved issues and error corrections
The leave management app now calculates mandatory leave days correctly when one or more employees have one or more leave requests. This helps ensure employee time off balances and mandatory day impacts are accurate for HR teams.
Original PR description
- Fixed the calculation of leave mandatory leaves to account for one or multiple leaves for one or multiple employees Task-4804618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223349
Point of Sale now sends validated invoiced orders to the preparation display even when automatic receipt printing skips the receipt screen. This prevents kitchen or preparation teams from missing orders in that specific checkout flow.
Original PR description
Steps to reproduce: ------------------- - Enable "Automatic Receipt Printing" - Make a PoS order, with "Invoiced" checked, and validate it -> Observe that the command is not sent to the preparation display. Reason: ------- When skipping the receipt screen, we don't call `checkPreparationStateAndSentOrderInPreparation`, which then doesn't send the new command to the preparation display. The fix: -------- Backporting 26425ab712a3269beec98722 but without any refactoring. opw-5000406 Forward-Port-Of: odoo/odoo#225241 Forward-Port-Of: odoo/odoo#224641
Analytic plans are now processed in parent-first order when installing related apps, preventing setup failures when plans have parent-child relationships. This helps ensure the Project app can be installed smoothly for databases that already use hierarchical analytic plans.
Original PR description
When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can…
When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can be processed before its parent. In such a case, the code tries to create a related field pointing to a parent-level column that does not yet exist, leading to errors like: `Field name "x_plan26_id" unknown for related field "x_plan26_id.plan_id"` This happened because `self` was iterated without guaranteeing that parents are processed first. As a result, the related field chain (`.plan_id.parent_id...`) could reference missing intermediate fields. The fix is ordering the recordset by `parent_path`. Steps to reproduce: 1. In Odoo Inspector, search for model `account.analytic.plan`. and go to records. 2. Create a first plan. 3. Create a second plan and set the first plan as its parent. 4. Install the `project` app (triggers `_sync_plan_column`). 5. Observe the crash due to an unknown related field. OPW-5006494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224509
Reducing a subcontracted receipt quantity no longer cancels the last related manufacturing order while the receipt is still in progress. This prevents purchasing and warehouse teams from getting stuck when they need to adjust quantities later.
Original PR description
Steps to reproduce:
- Unarchive subcontracting operation type
- Create a storable product P1 with a BoM:
- BoM type: Subcontracting
- Subcontractor: Azure Interior
- Component C1 (route: Resupply Subcontractor on Order)
- Create a purchase order:
- Vendor: Azure Interior
- 10 units of P1
- Confirm the PO → 2 pickings are created:
- Resupply of 10 units of C1
- Receipt of 10 units of P1
- Confirm and validate the resupply of C1
- Components are reserved in the subcontracting MO
- Validate the consumption of 10 units in the receipt
- The MO is updated to 10
- Update the quantity of P1 to 0 in the receipt
Issue:
The manufacturing order is cancelled. As a result, subsequent updates on the receipt cannot recreate MOs.
Fix:
When reducing the receipt quantity, cancel only the extra MOs, but always keep at least one open MO if a subcontracting move is still ongoing.
opw-4792379
Forward-Port-Of: odoo/odoo#223858Invoices sent by email to a purchase journal alias are no longer rejected when the sender is an existing user without access to the target company. This ensures valid supplier invoice emails are processed consistently, reducing manual follow-up and missed documents.
Original PR description
To reproduce the bug: 1- Create a DB with two companies and accounting app 2- Create a user and allow it to access company 2 3- Send a email using the user email to alias from purchase journal alias of company 2 4- The email will be rejected 5- Send a email using a random email address to alias. 6- The email will be accepted and an account.move is created. In a normal flow, when a user associated to the email not exists, the user_id is set to odoobot, otherwise, the user accosiated to the email. In the buggy flow the bug happens because `_compute_company_id` in account_move model, will set `company_id` to empty when user has no access to the company, as a result the `account_move` will fail. opw-4853027 Forward-Port-Of: odoo/odoo#225021 Forward-Port-Of: odoo/odoo#217322
This update fixes several issues when editing icons in the HTML editor. Users can now undo icon spin effects, see the toolbar state correctly, and apply colors consistently to selected icons and text.
Original PR description
**Current behavior before PR:** - Applying a spin effect to an icon doesn't not create a history step, which causes the undo functionality to fail. - The spin icon in the toolbar was not highlighted…
**Current behavior before PR:** - Applying a spin effect to an icon doesn't not create a history step, which causes the undo functionality to fail. - The spin icon in the toolbar was not highlighted after applying the effect. - When some text is selected along with icon, trying to apply color only affects the icon, the text remains uncolored. **Desired behavior after PR:** Now, - History step is created after adding spin effect to an icon, allowing undo to work properly. - The spin icon in the toolbar is properly highlighted to reflect the applied effect. - This PR removes `color_apply_overrides` from icon_plugin to let color_plugin handle coloring the icons ensuring that the selected text is also colored along with icon. - This PR also makes sure that default 60% opacity is applied when applying solid background color on icons or table cells. task-4794673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224702 Forward-Port-Of: odoo/odoo#210341
This change prevents missing website links from being turned into empty links when a CDN is active. It helps avoid a checkout address form issue where the Submit button could trigger an unexpected page refresh and interrupt form submission.
Original PR description
In QWeb, when using `t-att-href='None'`, the attribute is omitted from the DOM. However, when a CDN is used, `None` is converted to an empty string (`''`) by `get_cdn_url`. This is a follow-up to commit 3e9c953. This fix addresses an issue on the `/shop/address` page where the "Submit" button had `href=''`, causing JavaScript event handling to break due to a race condition triggered by a page refresh during form submission (POST). Forward-Port-Of: odoo/odoo#223252 Forward-Port-Of: odoo/odoo#220166
This fix restores custom website editing permission behavior that some Odoo.com pages rely on. It avoids blocking editors who should only have rights to modify specific website pages, while keeping a related test in place but disabled until a fuller solution is found.
Original PR description
*: test_website This reverts commit [1]. Indeed, while it fixed the bug as intended while keeping the `_check_user_can_modify` feature, it apparently did not keep that one working in all cases: having partial view edition rights for some website.page (see uses in our Odoo.com customizations). While searching for a solution allowing to keep the fix of [1] and the whole purpose of `_check_user_can_modify`, the logic part of [1] is reverted, keeping the test but disabled. [1]: https://github.com/odoo/odoo/commit/8c41c147a4c6a415e7c5bfdde9297edbf40b4239 Forward-Port-Of: odoo/odoo#225160
Corrects Italian electronic invoice XML exports so self-invoices omit payment data and supplier invoice references are placed in the required section. This helps companies using Italian localization stay aligned with tax authority formatting rules and reduces rejected or inaccurate filings.
Original PR description
1- `<DatiPagamento>` shouldn't be included in autofatture. 2- The supplier's original invoice number and date must be placed in the `<DatiFattureCollegate>`, using `<IdDocumento>` and `<DataDocumento>` fields respectively. Currently `<IdDocumento>` is added to the `<DatiOrdineAcquisto>`. A fix is made to add `<IdDocumento>` and `<DataDocumento>` to `<DatiFattureCollegate>`. references: https://www.agenziaentrate.gov.it/portale/documents/d/guest/guida_compilazione-fe-esterometro-v1-10_aprile_2025 opw-4810326 Forward-Port-Of: odoo/odoo#212989
Imported vendor bills created from consolidated inter-company invoices now correctly link to all related purchase orders. This helps teams keep purchasing and accounting records connected when multiple sales orders are billed together.
Original PR description
## Issue: In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other, then generate a Consolidated…
## Issue: In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other, then generate a Consolidated Invoice for both SO, and import it as Vendor Bill in the client Company, the bill isn't linked to the matching Purchase Order ## Cause: The `invoice_origin` is used to get the references, but it doesn't split causing the purchase's name to search in `_match_purchase_orders()` to be ["P00001, P00002"] instead of ["P00001", "P00002"] https://github.com/odoo/odoo/blob/2718aaa7397e38be0fcd64fe6b5ef5c0be66cfe2/addons/purchase/models/account_invoice.py#L373-L374 ## Steps to reproduce: - Enable Inter-Company Transactions for Sales Orders and Purchase Orders in two Companies - Create and Confirm two Sales Orders from one company to the other one - Create a Consolidated Bill for both S0 - Send the Invoice (Download) - Switch to the second Company - In Purchase, Confirm both RFQ - In Accounting > Vendor > Bills, Upload the downloaded bill - The Smart Button isn't linked to the PO Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4690707) opw-4690707 Forward-Port-Of: odoo/odoo#223398
The PLM dashboard now shows a more accurate count of Engineering Change Orders waiting for the current user's validation. This helps approvers focus on items that actually need their action, avoiding misleading totals caused by approvals assigned to others or already completed.
Original PR description
The dashboard of PLM displays for each ECO type the number of validations pending in general, and the validations waiting for me specifically. The latter has been incorrectly computed for quite some time, as it computes how many ECOs exists where I am an approver and an approval is waiting - but there is no guarantee that the waiting approval is one of mine; it might be that I am a past approver of the ECO and that another approval (waiting for somebody else than me) exists, or that two approval are required on the same stage (one by me, one by somebody else) and I already approved. This commit switches the computation around by looking for pending approvals waiting for me, and then get the number of (non-archived) ECOs bound to them. Forward-Port-Of: odoo/enterprise#93411 Forward-Port-Of: odoo/enterprise#92348
This fixes an error that blocked users from posting more than one invoice at a time when using Avalara Brazil automatic tax mapping. Businesses can now process batches of affected invoices without interruption, improving reliability for Brazilian tax workflows.
Original PR description
Issue:
When posting multiple invoices with Avalara Brazil tax mapping, a traceback is raised:
ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move
Only occurs when fiscal position is set to:
Automatic Tax Mapping (Avalara Brazil)
Affected versions:
- 17.0 and later
Steps to reproduce:
1. Set Avalara connection
2. Create an invoice with fiscal position: Automatic Tax Mapping (Avalara Brazil)
3. Duplicate that invoice
4. Select two or more invoices in draft
5. Try to post those entries
https://drive.google.com/file/d/1_CjX9vGhr-ZyUegP9QhOdQ--bfA8ylsH/view?usp=sharing
Current behavior:
- Error is raised: ValueError: Expected singleton
Expected behavior:
- Invoices should post correctly without errors
Forward-Port-Of: odoo/enterprise#93689
Forward-Port-Of: odoo/enterprise#93272The Malaysia Statement of Account report now applies the correct currency conversion when invoices are issued in a currency different from the company's main currency. This prevents balances from being shown with the right currency symbol but the wrong amount, improving accuracy for customer reporting and collections.
Original PR description
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for…
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for each line is displayed as the main currency, but the conversion isn't done. For instance, if we create an invoice line of 3.5$ but our main currency is the Euro, in the report, it will show 3.5€ instead of 2.99€ ## Reproduction Steps 1. In a db without demo data, Download the app l10n_my. 2. In the general settings, click on Currencies. Activate a second currency and set its currency rate (relative to the main currency of the company) different of 1. 3. In accounting > settings, click on -> Currencies. Activate this second currency. 4. Click on configuration > journals and activate the debug mode. In the Journal Entries tab, as Currency, select a different currency than your main one (set in the general settings). 5. Create an invoice. Set a customer and select the journal for which you set an additional currency. Select this additional currency. Finally, add a product and click confirm. 6. Click on Reporting > Aged Receivable. Then, click on the line corresponding to your partner on Statement of Account. A PDF should download. ### Expected behavior The lines under Balance should be displayed as the main currency of the company, with the correct currency rates applying. ### Unexpected behavior The lines under Balance are displayed as the main currency of the company but the currency rates are not applying. ## Origin of the issue In the code, the currency rate isn't used to generate this line of the report: https://github.com/odoo/enterprise/blob/79c1ba68d48e7e068104d867e186610dd5110cc4/l10n_my_reports/report/statement_account_templates.xml#L52 __ opw-4975540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#93096