Daily updates from Odoo
Thursday, July 23, 2026
18 changes · saas-18.3
Enhancements to existing features
After this advisory: https://services.gst.gov.in/services/advisoryandreleases/read/661 It has become mandatory to pass `shipToGSTIN`, i.e. GST number of the ship-to partner during the generation of the e-waybill for `Bill-to-Ship-to` (type-2) and `Combination` (type-4) transaction types. task-6236778
Original PR description
After this advisory: https://services.gst.gov.in/services/advisoryandreleases/read/661 It has become mandatory to pass `shipToGSTIN`, i.e. GST number of the ship-to partner during the generation of the e-waybill for `Bill-to-Ship-to` (type-2) and `Combination` (type-4) transaction types. task-6236778
Resolved issues and error corrections
Account Reports now correctly recognizes when no report section has been opened yet. This prevents incorrect behavior caused by treating an empty tracking record as if it contained data, improving reliability when navigating financial reports.
Original PR description
**Root Cause:**
At [1], the condition `this.lastOpenedSectionByReport === {}` always
return `false` because JavaScript compares objects by reference
rather than by value. As a result, the code never detects when
`lastOpenedSectionByReport` is empty.
**Fix:**
This commit ensures the code correctly detects an empty
`lastOpenedSectionByReport` object.
[1]:
https://github.com/odoo/enterprise/blob/ae4b461edb1d6b49c25d4e264380e7ae4b67f10c/account_reports/static/src/components/account_report/controller.js#L50
**No task ID**
Forward-Port-Of: odoo/enterprise#124223The Peppol settings now apply the right rule for when a purchase journal is required, especially when French PDP features are also installed. This prevents non-French companies using Documents for Peppol from being forced to configure an unnecessary invoicing journal, and ensures imports go only to the selected destination.
Original PR description
Fixes the settings view for the account_peppol_purchase_journal_id. account_peppol, documents_account_peppol and l10n_fr_pdp all wants to use a specific condition for the required attribute of the view. With PDP especially, once l10n_fr_pdp is installed, the view forces the base condition, even if documents_account_peppol is installed, and even if the company is not even French. On a non-French company registered/registering on Peppol, the journal shouldn't be mandatory if documents_account_peppol_folder_id is set up. To ease things up, it is now using a computed field. task-6304479 Forward-Port-Of: odoo/enterprise#120718
The Knowledge and Documents cards on the customer portal now align visually with the other portal cards. This fixes a small layout inconsistency, making the account portal page look more polished and consistent for users.
Original PR description
The knowledge and documents portal card was injected directly into "o_portal_docs", causing it to render wider than other cards. This happened because other cards sit inside "o_portal_category" (row g-2 mt-3) divs, while, knowledge was a direct child of o_portal_docs, giving it a different grid context despite both using col-md-6. To fix the issue, we wrapped the portal_docs_entry in an "o_portal_category row g-2 mt-3" div to match the structure of all other portal cards. Steps to reproduce: 1.Go to the website. 2.Click on name drop down menu on the navbar like "Mitchell Admin" 3.Click on "My Accont" from the drop down menu 4.Once the page loads properly, you can see the knowledge card width is a little bit larger than other cards. opw-6251483 Forward-Port-Of: odoo/enterprise#119939
The barcode app now correctly keeps only one delivery line selected when users switch between packaged and unpackaged products. This prevents confusion during warehouse picking and helps operators process mixed deliveries more reliably.
Original PR description
**Steps to reproduce:** - Enable "Move Entire Packages" setting on deliveries - Make a product A, that has a package P1, on hand qty of 1 - Make product B that don't have a package, but on hand qty…
**Steps to reproduce:** - Enable "Move Entire Packages" setting on deliveries - Make a product A, that has a package P1, on hand qty of 1 - Make product B that don't have a package, but on hand qty of 1 - Make a delivery that has both of those products, requested qty of 1 for both - Mark it as todo - Go to the barcode app, select the delivery - Select the line with product B - Select the line with product A --> The line with product B is not unselected **Why the fix:** When we have a mix of packaged products and products without a package on the same operation, they are handled separately. The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**. As we do not touch this variable, the selected package line stays selected. The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 This function does not care for the **selectedLineVirtualId** which represents the selected line without a package. To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation. This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 to unselect every line regardless of packages. opw-6266203 Forward-Port-Of: odoo/enterprise#124717 Forward-Port-Of: odoo/enterprise#122038
Fixed a rounding issue that could make a trial balance ending balance appear as a tiny scientific-notation number instead of zero in XLSX exports. This improves report accuracy and reduces confusion when accounts are fully balanced.
Original PR description
Steps to reproduce -------------------- - Install account_reports module; - Create a new account; - Create a miscellanous operation for the previous month using thenew account with a credit amount of $8.28; - Create a second MISC for the current month with two lines using the account : debit = 262.67 and credit = 254.39; - Open the trial balance report and filter the new account (end balance should be 0); - Export the report as XLSX; The end balance value is 2.84e-14 due to float rounding issues. opw-6369016
## Steps to Reproduce: _(cryptography version > 43.0.0)_ 1. Install the `l10n_sa_edi` module. 2. Switch to SA Company. 3. Set the company name to an Arabic string between 32 and 64 characters. (e.g; `مجموعة النخبة العالمية للاستشارات الفنية`) 5. Accounting > Configuration > Journals. 6. Open a Sales type journal. 7. Click "Re-onboard" in the ZATCA tab. 8. Enter an OTP and click "Request". ## Error: `ValueError: Attribute's length must be >= 1 and <= 64, but it was 98` ## Caus
Original PR description
## Steps to Reproduce: _(cryptography version > 43.0.0)_ 1. Install the `l10n_sa_edi` module. 2. Switch to SA Company. 3. Set the company name to an Arabic string between 32 and 64 characters. (e.g;…
## Steps to Reproduce: _(cryptography version > 43.0.0)_
1. Install the `l10n_sa_edi` module.
2. Switch to SA Company.
3. Set the company name to an Arabic string between 32 and 64 characters.
(e.g; `مجموعة النخبة العالمية للاستشارات الفنية`)
5. Accounting > Configuration > Journals.
6. Open a Sales type journal.
7. Click "Re-onboard" in the ZATCA tab.
8. Enter an OTP and click "Request".
## Error:
`ValueError: Attribute's length must be >= 1 and <= 64, but it was 98`
## Cause:
The CSR validation checks the length of characters, if combined common_name (or other fields) are less than 64 characters, it passes the condition. - [1] But the cryptography library validates UTF-8 byte length for string values. Arabic characters take 2 bytes in UTF-8, causing the byte length to exceed the 64-byte limit enforced by the cryptography.
**Note:**
Starting with cryptography version 43.0.0, the library enforces the UTF-8 byte length limit for CSR string values during certificate creation. (Ref: https://github.com/pyca/cryptography/pull/11201)
## Fix:
Validate the UTF-8 encoded byte length instead of the character length.
[1] - https://github.com/odoo/odoo/blob/a66fedcaf555660e484a2becc49a9b7e602f5924/addons/l10n_sa_edi/models/certificate.py#L92
sentry-7608376856
Forward-Port-Of: odoo/odoo#276861Stripe recommends connecting to a reader returned by the most recent discovery call. However, the POS Stripe interface discovered readers as soon as the Stripe Terminal object was created, during POS loading. This means a POS reload performed long before the first payment could populate `pos.discoveredReaders` with stale reader objects. If the first Stripe Terminal payment happens much later, the SDK may try to connect using outdated reader/credential state and fail with an expired Connection
Original PR description
Stripe recommends connecting to a reader returned by the most recent discovery call. However, the POS Stripe interface discovered readers as soon as the Stripe Terminal object was created, during POS loading. This means a POS reload performed long before the first payment could populate `pos.discoveredReaders` with stale reader objects. If the first Stripe Terminal payment happens much later, the SDK may try to connect using outdated reader/credential state and fail with an expired ConnectionToken. Move reader discovery to `connectReader()` so Odoo connects using fresh discovery results, and stop discovering readers eagerly when creating the Stripe Terminal instance. opw-6311626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276875
e39bf6c6ab31e57d472a552cb9b902496e6323ae introduced a blacklist to email sending, to filter out "alias emails" (catchall...) & the root partner email (odoobot) from being sent certain emails, such as mailings. By default, odoobot email is odoobot@example.com. However, there are cases where users will have a legitimate partner that matches the odoobot email; an example of this is saas config, which automatically changes the odoobot email to the admin email set on database spin-up. This
Original PR description
e39bf6c6ab31e57d472a552cb9b902496e6323ae introduced a blacklist to email sending, to filter out "alias emails" (catchall...) & the root partner email (odoobot) from being sent certain emails, such as mailings. By default, odoobot email is odoobot@example.com. However, there are cases where users will have a legitimate partner that matches the odoobot email; an example of this is saas config, which automatically changes the odoobot email to the admin email set on database spin-up. This prevents the database admin from receiving their own mailings. To fix this, the root partner email is now only added to the blacklist if no active partner has the same email. Steps to reproduce: - Add a mailing contact with the same email as the root partner - Send a mailing to that mailing contact task-4893615
Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move unit and the line unit converted a value to its own unit, hence did nothing. Steps to reproduce: - create a product in Units with available stock - create a delivery for 2 Dozen of it and mark it as todo - in the detailed operations, change the unit of the move line to Units (24) - lower the
Original PR description
Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move…
Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move unit and the line unit converted a value to its own unit, hence did nothing. Steps to reproduce: - create a product in Units with available stock - create a delivery for 2 Dozen of it and mark it as todo - in the detailed operations, change the unit of the move line to Units (24) - lower the move quantity from 2 to 1 Dozen The move line ends up with 23 Units instead of 12: the decrease of 1 Dozen is applied as 1 Unit on the line and considered fully processed. The remaining 11 units stay reserved and counted on the transfer. Convert the remaining decrease from the move unit to the line unit when taking it from a line, and the taken quantity back to the move unit when updating the remaining decrease. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276774
iOS devices currently display the first letter of the website name instead of a favicon when creating a shortcut. This commit adds the `apple-touch-icon` link tag referencing the favicon to ensure the icon displays correctly. This commit is a backport of [1], which was merged in master(saas-19.2). task-5427275 [1]: https://github.com/odoo/odoo/commit/2506fdfc49f1515aea7e715e9f6d66418a093401 Forward-Port-Of: odoo/odoo#277723
Original PR description
iOS devices currently display the first letter of the website name instead of a favicon when creating a shortcut. This commit adds the `apple-touch-icon` link tag referencing the favicon to ensure the icon displays correctly. This commit is a backport of [1], which was merged in master(saas-19.2). task-5427275 [1]: https://github.com/odoo/odoo/commit/2506fdfc49f1515aea7e715e9f6d66418a093401 Forward-Port-Of: odoo/odoo#277723
When installing the module document_account_peppol, the user has the choice to import his Peppol invoices into the Documents app directly, but also to block the import in Accounting, by removing the Peppol import journal. In that last case, the Peppol application response flow is broken, the document model does not contain the necessary information to handle responses as the imported invoices do. (In stable) We took the decision to remove the ApplicationResponse service from users that bl
Original PR description
When installing the module document_account_peppol, the user has the choice to import his Peppol invoices into the Documents app directly, but also to block the import in Accounting, by removing the Peppol import journal. In that last case, the Peppol application response flow is broken, the document model does not contain the necessary information to handle responses as the imported invoices do. (In stable) We took the decision to remove the ApplicationResponse service from users that block the invoice import flow by removing the import journal. For PDP, the responses are required, but as the block is completely replaced in the view, and reuses the basic account_peppol condition for the required attribute, the account peppol purchase journal will always be required if the company is registered on Peppol/PDP. Nothing to do in 18.0. task-6191644 Forward-Port-Of: odoo/odoo#270091
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e80e0276b4 [REL] 18.3.57 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/42c54d08fe [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589) https://github.com/odoo/o-spreadsheet/commit/a53aebf21e [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e80e0276b4 [REL] 18.3.57 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e80e0276b4 [REL] 18.3.57 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/42c54d08fe [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589) https://github.com/odoo/o-spreadsheet/commit/a53aebf21e [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Seven entries of the Mexican chart of accounts template carry a name belonging to a **different** group, copied from a neighbouring entry. Each record's XML ID still states the intended name, which is what this restores. | Code | Field | Before | After | |---|---|---|---| | `6` | `name@es` | Gastos generales | Gastos | | `252.07` | `name@es` | `account_subgroup_hipotecas_por_pagar_a_largo_plazo_nacional` | Hipotecas por pagar a largo plazo nacional | | `602` | `name`, `name@es` | Cost of sales
Original PR description
Seven entries of the Mexican chart of accounts template carry a name belonging to a **different** group, copied from a neighbouring entry. Each record's XML ID still states the intended name, which…
Seven entries of the Mexican chart of accounts template carry a name belonging
to a **different** group, copied from a neighbouring entry. Each record's XML ID
still states the intended name, which is what this restores.
| Code | Field | Before | After |
|---|---|---|---|
| `6` | `name@es` | Gastos generales | Gastos |
| `252.07` | `name@es` | `account_subgroup_hipotecas_por_pagar_a_largo_plazo_nacional` | Hipotecas por pagar a largo plazo nacional |
| `602` | `name`, `name@es` | Cost of sales / Costo de venta | Selling expenses / Gastos de venta |
| `613` | `name@es` | Amortización contable | Depreciación contable |
| `614` | `name` | Accounting depreciation | Accounting amortisation |
| `701.06` | `name`, `name@es` | Interest on foreign bank charges / Intereses a cargo bancario extranjero | Interest payable by national natural persons / Intereses a cargo de personas físicas nacional |
| `702` | `name@es` | Utilidad cambiaria | Productos financieros |
### Why it is not cosmetic
The electronic accounting Chart of Accounts XML takes the `Desc` attribute of
every `<Ctas>` element from the *account group name* — `cfdicoa.xml`
(`t-att-Desc="account.get('name')"`), fed by `trial_balance.py`
`_l10n_mx_get_coa_values()`. Any `es_*` database therefore declares:
```xml
<catalogocuentas:Ctas CodAgrup="702" NumCta="702" Desc="Utilidad cambiaria" Nivel="1" Natur="A"/>
```
whereas the SAT catalogue (Anexo 24) publishes `702` as *Productos financieros*,
with `702.01 Utilidad cambiaria` … `702.10 Otros productos financieros` beneath
it. `CodAgrup` comes from `code_prefix_start` and stays correct, so the file
still validates against the XSD, but the declared description does not match the
official nomenclature. Trial Balance and Pólizas are unaffected — neither
exports group names.
### Evidence
- `252.07` contains its own XML ID as the Spanish name.
- `602` duplicates `501.01`, yet its children are `Sueldos y Salarios`,
`Compensaciones`, `Tiempos extras`.
- `613` and `614` are swapped in one language each: `613`'s children are
depreciations, `614`'s are amortisations.
- `701.06` duplicates `701.05` in both languages; the correct name is symmetric
to `701.07` and to `702.06`.
- `6` is the only single-digit root group whose Spanish name does not match its
XML ID (`account_group_gastos`).
### Notes
Introduced in d782b8b92557; correct in 15.0, where the names lived in
`account.account.tag.csv`. Still present in 18.0, 19.0 and master, hence
targeting 17.0. Template data only — existing databases are unaffected until the
chart is (re)installed, and renaming a group moves no balance.
Forward-Port-Of: odoo/odoo#277426The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification. See upstream changes: - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization) - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization) This commit fixes
Original PR description
The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification. See upstream changes: - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization) - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization) This commit fixes this by refactoring the assertions to treat the output HTML structure as a "black box", verifying data integrity and expected content conversions rather than brittle structural layout. runbot-938228 Forward-Port-Of: odoo/odoo#277747 Forward-Port-Of: odoo/odoo#275959
Firefox has a strict limit of ~640,000 characters for history state serialization and throws NS_ERROR_ILLEGAL_VALUE past it. Chrome and Safari throw DataCloneError past their own undocumented limits (~500MB and ~64MB respectively). When a debounced push() exceeded these limits, the error was unhandled and broke navigation. Catch these two specific errors and log them instead of crashing, while still resetting the push state and re-throwing any other unexpected error. opw-6182687 Forward-P
Original PR description
Firefox has a strict limit of ~640,000 characters for history state serialization and throws NS_ERROR_ILLEGAL_VALUE past it. Chrome and Safari throw DataCloneError past their own undocumented limits (~500MB and ~64MB respectively). When a debounced push() exceeded these limits, the error was unhandled and broke navigation. Catch these two specific errors and log them instead of crashing, while still resetting the push state and re-throwing any other unexpected error. opw-6182687 Forward-Port-Of: odoo/odoo#277724
When preparing procurement values from a stock move, the project is retrieved from the sale order through: self.group_id.sale_id.project_id Users with Sales access set to "Own Documents Only" may not have read access to the originating sale order, causing an AccessError when editing manufacturing orders by adding components that use the MTO flow. The fix is to include sudo() for the project lookup, as editing a MO and should not depend on the user's SO visibility. Steps to Reproduce: 1
Original PR description
When preparing procurement values from a stock move, the project is retrieved from the sale order through: self.group_id.sale_id.project_id Users with Sales access set to "Own Documents Only" may not have read access to the originating sale order, causing an AccessError when editing manufacturing orders by adding components that use the MTO flow. The fix is to include sudo() for the project lookup, as editing a MO and should not depend on the user's SO visibility. Steps to Reproduce: 1. Turn on multi-step routes and unarchive the MTO route 2. Create a SO using a product that has a BOM and uses Manufacture/MTO route 3. Logged in as Marc Demo, open the MO and try to add a component. The component must also have the Manufacture/MTO route enabled. 4. You will get an access rights error upon save/confirm. Related Tickets: opw-6366029 Forward-Port-Of: odoo/odoo#277345
Miscellaneous changes
Stable forward-port source patch. Issue - The turnstile template uses a misspelled variable name in data-appearance: appeareance. - JS provides appearance. - Because of this mismatch, data-appearance always falls back to interaction-only and ?cf=show cannot force always mode. Fix - Replace appeareance with appearance in the turnstile template. Why stable-safe - One-line template fix. - No API/model/signature changes. - No behavior change outside the intended appearance selection. This is int
Original PR description
Stable forward-port source patch. Issue - The turnstile template uses a misspelled variable name in data-appearance: appeareance. - JS provides appearance. - Because of this mismatch, data-appearance always falls back to interaction-only and ?cf=show cannot force always mode. Fix - Replace appeareance with appearance in the turnstile template. Why stable-safe - One-line template fix. - No API/model/signature changes. - No behavior change outside the intended appearance selection. This is intended as the 17.0 source fix so forward-porting can propagate to upper versions. Related: odoo/odoo#273306 and odoo/odoo#273652 Forward-Port-Of: odoo/odoo#273706