Daily updates from Odoo
Navigate
Branch
Thursday, October 16, 2025
204 changes
20 changes
Enhancements to existing features
Changes made to POS category names or display order are now sent to UrbanPiper when menus are synced again. This helps restaurants keep their online menus consistent without manual updates in UrbanPiper.
Original PR description
Before this commit: ----------------------------------------- - After syncing the menu, changes in a POS category (e.g., name or sequence) were not reflected in UrbanPiper when the menu was synced again. After this commit: ----------------------------------------- - Category updates (name or sequence) are now synced with UrbanPiper on subsequent menu syncs. Task-5122804 Forward-Port-Of: odoo/enterprise#96270
Resolved issues and error corrections
Portal users opening shared project tasks will no longer see a chat expand option that caused an error. This prevents a crash-like experience and keeps the project sharing chat limited to actions supported in the portal.
Original PR description
Steps to reproduce: === - Create a project. - Share the project with access to edit rights to the portal user. - Log in as the portal user. - Open the shared project and then open a task. - Click on the expand button in the chat. Issue: === A traceback occurs when trying to expand the chatter in a project sharing task. Cause: === `inFrontendPortalChatter` not being set in `useSubEnv` is the reason for button appearance, and we don't have the necessary composer for it to render in the project sharing bundle. Fix: === Define missing `inFrontendPortalChatter` to hide the expand chatter composer action as it was not meant to be available in the portal/front-end. task-5049129 Forward-Port-Of: odoo/odoo#231360
Failed email replies for accounting journal aliases now use the company linked to that alias instead of defaulting to the main company. This prevents customers or senders from seeing the wrong company name or email address in bounce messages when working with multiple companies.
Original PR description
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an…
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an corresponding email template. But as is, the usage of `'company_email': self.env.company.email` and `'company_name': self.env.company.name` will default to the "main" company (id 1 usually), as during the message routing, that will be the default company in `env`. This means, that if you have an journal email alias in company B, the email will still render the information of the main company A. ## Proposed fix: When a journal email alias is created in a standard way, it should have a key:value pair for 'company_id' in the `alias_defaults` field. We change the routing check logic so that it will try to fetch that value, while defaulting to the main company if there is no explicit company `company_id` key. This should ensure that the mail gateway failed email renders preferentially renders the company information of the company the mail alias (and accounting journal) belongs to. OPW-5132806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231436
Point of Sale receipts now keep ship-later dates as calendar dates instead of converting them through time zones. This prevents customers and staff from seeing an incorrect shipping date on receipts, improving order accuracy and reducing confusion.
Original PR description
PURPOSE: ---------------- - Fix incorrect handling of shipping date in POS . It was treated as a datetime, which led to timezone shifts and wrong dates in receipts. STEPS TO REPRODUCE:…
PURPOSE: ---------------- - Fix incorrect handling of shipping date in POS . It was treated as a datetime, which led to timezone shifts and wrong dates in receipts. STEPS TO REPRODUCE: ------------------- 1. Open point of sale 2. In Configuration → Settings, enable Allow Ship Later for a POS shop. 3. Open a POS session, add a product, proceed to payment, and select Ship Later. 4. Validate the order. ISSUE: -------------------- - The receipt shows the wrong shipping date. CAUSE: --------------------- - shipping_date was serialized using serializeDateTime, forcing a UTC conversion. - Related models only supported datetime type, so date fields were mishandled. FIX: -------------------- - Introduced proper date handling (convertRawToDate, convertDateToRaw). - Updated serialization/deserialization to handle both `date` and `datetime`. - Changed ShippingDate to use serializeDate instead of serializeDateTime. Task-5055738 Forward-Port-Of: odoo/odoo#227693
Users now receive a clear validation message when entering a check number that is too large for a Bank Journal. This prevents a confusing technical error and helps accounting users correct the value before saving.
Original PR description
**Issue** When trying to set a very large value as *Next Check Number* in a Bank Journal, Odoo raises a low-level `RPC_ERROR` caused by a PostgreSQL `integer out of range` error. This results in a technical traceback instead of a clear message to the user. **Steps to Reproduce** 1. Go to *Accounting > Configuration > Journals* 2. Open the Bank Journal 3. Go to the *Outgoing Payments* tab 4. Enable *Manual Numbering* 5. Set *Next Check Number* to `2147483648` **Root Cause** The field `ir.sequence.number_next` is stored as an integer in the ORM. Any value greater than `2,147,483,647` (max signed 32-bit integer) causes PostgreSQL to raise an overflow error when saving. Since the error occurs deep in the ORM write call, the user only sees a generic RPC error without explanation. Opw-5042096 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225103
This fixes an issue that prevented users or administrators from creating certain related one-to-many fields when no inverse field was available. The change helps configuration flows work as expected and reduces setup blockers in the base model framework.
Original PR description
…n_field Before this commit, it was not possible to create a related one2many without a relation_field (inverse) However, the relation_field of a relation cannot be the one of the original field (because it doesn't exist on the current model) After this commit, this flow works. opw-5155440 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#231434 Forward-Port-Of: odoo/odoo#231187
This fix prevents an error when users create certain related customer contact fields in Studio, such as linking a sales order to a customer's child contacts. The system now avoids saving an invalid relationship setting, improving reliability during form updates.
Original PR description
On sale order, create a related field to res_partner.child_ids Before this commit, the related field is not stored but has a relation_field to parent_id (res.partner) During an onchange (outside of studio), this will crash. After this commit, we unset relation_field in this case as it doesn't make sense (the relation_field should reference a res.partner field, not a field presetn in the current model) opw-5155440 Forward-Port-Of: odoo/enterprise#97107 Forward-Port-Of: odoo/enterprise#96950
Gift Card and E-Wallet products now remain visible in the Point of Sale screen even when the store is limited to specific product categories. This ensures cashiers can always sell these products without needing extra category setup.
Original PR description
Before this commit: =================== If the PoS configuration is restricted to specific categories, but the Gift Card and E-Wallet products do not have any category assigned, these products will not be visible in the PoS UI. After this commit: ==================== Gift Card and E-Wallet products are now always visible in the PoS UI, regardless of whether a PoS category is assigned or not. Purpose: ============ Gift Card and E-Wallet products should always be available for sale in the PoS. This ensures they can be sold physically from the PoS UI without requiring category assignment. Task-5103770 Forward-Port-Of: odoo/odoo#231626 Forward-Port-Of: odoo/odoo#228395
This fix updates how Odoo checks and marks old device session logs so large databases can be processed in smaller batches. It helps avoid long-running database updates that could slow down or block normal system activity during maintenance.
Original PR description
The commit: https://github.com/odoo/odoo/commit/6fb676a4e3566c781ddd57480a200cddc88d99ae adds the model `res.device.log` which will hold a lot of data. In order to use this data efficiently, we decide to process data with the boolean field `revoked` equal to `True` (via the indexes). This boolean field indicates whether the session that generated the log is still present on the disk. The commit: https://github.com/odoo/odoo/commit/e4c9d1794f2d4873755a8692f4861ba043fac943 adds an automatic verification mechanism to change this value if necessary. Between the time the model was created and the time the verification mechanism was implemented, the table may have become too large. This will result in a very long write within a transaction. The purpose of this commit is to introduce a method for performing the batch writing. Forward-Port-Of: odoo/odoo#225736
The product configurator now uses space better on mobile screens when optional products include custom text fields. This keeps key controls, including the cart button, visible and easier for shoppers to use.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a product attribute with a single custom value; 2. add the attribute to a product A; 3. set product A as an optional product of product B; 4. go to product B's product page in mobile view; 5. click on the cart button. Issue ----- The custom text field takes up way too much real estate. Cause ----- The template isn't fully adapted for mobile view. Solution -------- Change `d-flex` to `d-lg-flex` on the `ptal` element, making the attribute name & input online display in-line on large screens. Additionally, change some bootstrap classes to also have the cart button button displayed within the screen. opw-5114495 Forward-Port-Of: odoo/odoo#231744 Forward-Port-Of: odoo/odoo#230743
This fixes an issue where Mexican electronic invoice XML attachments could be saved with the wrong file type for users with limited access rights. As a result, related accounting documents are generated reliably when document centralization is enabled.
Original PR description
When creating an XML attachment as a user without Write access on the ir.ui.view model, the Mimetype will be set to plain/text. In particular, this causes issues when Accounting centralization is enabled in Documents, as the corresponding Document will only be generated if the Mimetype is application/xml. Creating the XML as Superuser avoids this issue. Similar to https://github.com/odoo/odoo/pull/124507 opw-5057038 Forward-Port-Of: odoo/enterprise#97258 Forward-Port-Of: odoo/enterprise#95197
Fixed an issue where dropdown menus could appear slightly misplaced when their content was wider than the button opening them. This improves the visual consistency and usability of selection menus in the web interface.
Original PR description
This commit fixes the position of the SelectMenu, that was not aligned properly when the content of the menu is larger than the toggler width before applying any maxWidth. Because the 'fit' variant sets the same width to the popper by default, and the code was applying this width after the computation of the position of the popper, the menu was displaced. Now, the width is applied before positioning the menu, which then computes accordingly. A test has been added as well. task-4674144 Forward-Port-Of: odoo/odoo#230983 Forward-Port-Of: odoo/odoo#224568
This update adds validation for Dutch structured payment references and prevents free-text payment notes from being incorrectly treated as structured references in SEPA QR codes. This helps reduce payment processing errors for Dutch customers and improves the reliability of QR-code-based payments.
Original PR description
[SEE THIS PR](https://github.com/odoo/odoo/pull/200922) [IMP] account: Check NL structured reference The aim of this commit is implementing a new function to check the structured reference for the Netherlands. Even if dutch people can use the ISO format, they can still use the NL format. no task id [FIX] account_qr_code_sepa: Don't fill structured communication with unstructured communication This commit ensures that unstructured communication is not mistakenly used as structured communication in the QR code values. To achieve this, we use is_valid_structured_reference, a simple validation approach that checks all available is_valid_structured_reference functions. While this method may lead to occasional false positives, we consider this trade-off acceptable. opw-4575004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231373
Users can now add image attachments to Twitter comments from the Social app without upload errors. Comment text is also preserved when adding files or emojis, preventing accidental loss of typed content.
Original PR description
Issue 1 ======= Steps to reproduce ----------------------- 1. Go to the Social app. 2. Create or Select any twitter post. 3. Add a comment to that post with an image. 4. Press Enter. ---> An error…
Issue 1
=======
Steps to reproduce
-----------------------
1. Go to the Social app.
2. Create or Select any twitter post.
3. Add a comment to that post with an image.
4. Press Enter.
---> An error notification will be shown.
When adding an image in a post comment to Twitter, the image was not uploaded properly because the MIME type was not set, and it defaulted to `application/octet-stream`.
This caused the following error:
```
{"errors": [{"parameters": {"$.media_type": ["'application/octet-stream'"]},
"message": "$.media_type: does not have a value in the enumeration
[video/mp4, video/webm, video/mp2t, video/quicktime, text/srt, text/vtt,
model/gltf-binary, model/vnd.usdz+zip, image/jpeg, image/gif, image/bmp,
image/png, image/webp, image/pjpeg, image/tiff]"}], "title": "Invalid Request",
"detail": "One or more parameters to your request was invalid.",
"type": "https://api.twitter.com/2/problems/invalid-request"}
```
From the above error, it's clear that Twitter only accepts specific MIME types.
This fix ensures the image has the correct MIME type so it can be uploaded without issues.
-------------------------------------------------------------------------------------------------------------------------------
Issue 2
=======
Steps to Reproduce
------------------------------
1. Select any post from social feed.
2. Add text comment or edit existing comment.
3. Upload file or add emoji.
=> The comment text is cleared/reset to its initial value.
Technical
------------------------------
With commit [1] we added `t-att-value` which sets the value of the textarea
on every re-render of the component.
After this commit
------------------------------
The initial value is only set once when component is mounted.
Removed `remove image` button for attachment while posting comments.
[1] https://github.com/odoo/enterprise/commit/ced5e88f433b7b9a8e1429259cd8bb6594b34852
Task-4845385
Forward-Port-Of: odoo/enterprise#91995Spanish electronic invoices now preserve product unit price precision and use the invoice’s existing tax totals when global tax rounding is enabled. This helps prevent mismatches between invoices and generated e-Factura XML files, reducing validation issues and accounting discrepancies.
Original PR description
This PR is the opportunity to fix two mistakes in the XML generation of the e-Factura : 1. It is possible for a product to have more decimals than the currency, but the facturae always rounded…
This PR is the opportunity to fix two mistakes in the XML generation of the e-Factura : 1. It is possible for a product to have more decimals than the currency, but the facturae always rounded according to the currency. This would sometimes lead to both rounding errors and incomplete or incorrect values on the generated XML. This commit rounds product prices according to the unit price decimal while leaving the other computed field untouched as to not disturb the correct computation elsewhere. 2. When the tax rounding was set to round_globally, the TotalTaxOutput in the XML might differ from the actual tax_amount from the invoice because of rounding errors occurring during uncessary re-computation while building the XML. While stable is not the place to change all functions related, we can isolate computed tax output and tax withheld values and transmit them without any intermediary. As this file was changed in 18.0 another PR was needed from 17.0: https://github.com/odoo/odoo/pull/209623 (unit price decimals) and https://github.com/odoo/odoo/pull/229017 (tax rounding issue, detected after 209623 was closed) task-4650439 Forward-Port-Of: odoo/odoo#231424 Forward-Port-Of: odoo/odoo#229236
A correction was made to how financial reports calculate certain values, preventing incorrect internal handling during report generation. This helps ensure accounting reports remain reliable for users without changing how they interact with the system.
Original PR description
Forward-Port-Of: odoo/enterprise#97144
This fixes an issue where adding certain localized financial report variants to Annual Statements could fail. Annual Statements now include the appropriate underlying sections, preventing errors and keeping localized financial reporting setup smooth.
Original PR description
The "Annual Statements" report comes with additional code at create() and write() of account.report, so that any new localized variant of the Balance Sheet, Trial Balance or Profit & Loss will automatically replace its root report in the Annual Statements report's sections. The idea behind that is to "magically" replace those generic reports by the right variant when it's created. The problem with that came when you tried adding a variant to one of those reports that was itself a composite report. In such case, you got a traceback stating a composite report's sections could not have sections themselves. We indeed only support one level of hierarchy for composite reports. We solve the issue by adding all the sections of such composite variant to the Annual Statements instead of adding the variant itself. Bug originally reported by Upgrade, here https://github.com/odoo/upgrade/pull/8571 . Forward-Port-Of: odoo/enterprise#97145
Fixed an issue in the HTML editor where changing text color near an icon could accidentally recolor a larger surrounding section. This helps users format content more precisely and avoids unintended visual changes in edited pages or documents.
Original PR description
After this [commit], we'd have an issue when we tried to change a color and there was an `fa` icon next to our selection. Instead of changing the color of only the selection it would change it for the closest element with `color`, `background-color`, or `background-image` style properties. To reproduce the bug: - Set selection on an element that has a color style property on its parent, and the parent has .fa icon but not directly on our element - Try to change its color => Color of the whole parent changes task-5107147 [commit]: https://github.com/odoo/odoo/commit/927f4b973932d14961c148e13473017651a60dc0 Forward-Port-Of: odoo/odoo#229311
This fix prevents Odoo Discuss calls from crashing when a peer-to-peer connection offer is processed after a delay. It improves call reliability by safely handling cases where the connection participant is no longer available when the event completes.
Original PR description
Before this commit, since https://github.com/odoo/odoo/pull/205198, the handling of an offer can be arbitrarily delayed by the `acceptOffer` callback. This could lead to a traceback when the reference to `peer` is stale by the time the event is handled. Forward-Port-Of: odoo/odoo#231620
Features or functions removed from Odoo
This removes leftover files from a previously deleted HR contract spreadsheet dashboard module. The cleanup prevents an incomplete, unusable module directory from lingering after translation exports.
Original PR description
Module was originally removed by 46052c4bc5ad1bd2549a6125202e0671b56beac8 but was necromantized back into unlife by the translations export 0c1874473050f6e3cb68601737e3b4216aee5cad, being revived as a directory with a data file and a translation file but no manifest.
15 changes
Enhancements to existing features
POS category changes, such as renamed categories or updated display order, are now sent to UrbanPiper when the menu is synced again. This keeps online ordering menus aligned with in-store POS setup and reduces manual corrections.
Original PR description
Before this commit: ----------------------------------------- - After syncing the menu, changes in a POS category (e.g., name or sequence) were not reflected in UrbanPiper when the menu was synced again. After this commit: ----------------------------------------- - Category updates (name or sequence) are now synced with UrbanPiper on subsequent menu syncs. Task-5122804 Forward-Port-Of: odoo/enterprise#96270
Italian electronic invoices are now sent one at a time instead of in large batches. This reduces timeout errors with the SDI/IAP service and helps prevent scheduled processing jobs from getting stuck when many invoices are submitted.
Original PR description
Some clients reported that when they send a full batch size=20 invoices at once, they get a timeout response and the cron job get's stuck. Processing invoices one by one instead of a full batch. IAP-apps PR: https://github.com/odoo/iap-apps/pull/1230 Task [link](https://www.odoo.com/odoo/project.task/5045529) task-5045529 Forward-Port-Of: odoo/odoo#231665 Forward-Port-Of: odoo/odoo#230146
Resolved issues and error corrections
Portal users working on shared projects will no longer see a chat expand option that could not work in that environment. This prevents an error when opening tasks through project sharing and keeps the experience focused on supported chat actions.
Original PR description
Steps to reproduce: === - Create a project. - Share the project with access to edit rights to the portal user. - Log in as the portal user. - Open the shared project and then open a task. - Click on the expand button in the chat. Issue: === A traceback occurs when trying to expand the chatter in a project sharing task. Cause: === `inFrontendPortalChatter` not being set in `useSubEnv` is the reason for button appearance, and we don't have the necessary composer for it to render in the project sharing bundle. Fix: === Define missing `inFrontendPortalChatter` to hide the expand chatter composer action as it was not meant to be available in the portal/front-end. task-5049129 Forward-Port-Of: odoo/odoo#231360
Accounting bounce emails for journal aliases now use the company linked to the alias instead of defaulting to the main company. This prevents customers or senders from receiving failed-email notices with the wrong company name or email address in multi-company setups.
Original PR description
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an…
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an corresponding email template. But as is, the usage of `'company_email': self.env.company.email` and `'company_name': self.env.company.name` will default to the "main" company (id 1 usually), as during the message routing, that will be the default company in `env`. This means, that if you have an journal email alias in company B, the email will still render the information of the main company A. ## Proposed fix: When a journal email alias is created in a standard way, it should have a key:value pair for 'company_id' in the `alias_defaults` field. We change the routing check logic so that it will try to fetch that value, while defaulting to the main company if there is no explicit company `company_id` key. This should ensure that the mail gateway failed email renders preferentially renders the company information of the company the mail alias (and accounting journal) belongs to. OPW-5132806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231436
This fixes an issue that prevented certain related list-style fields from being created when no matching inverse link exists on the current model. It helps administrators and implementers configure data relationships more reliably without hitting an unnecessary technical restriction.
Original PR description
…n_field Before this commit, it was not possible to create a related one2many without a relation_field (inverse) However, the relation_field of a relation cannot be the one of the original field (because it doesn't exist on the current model) After this commit, this flow works. opw-5155440 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#231434 Forward-Port-Of: odoo/odoo#231187
This fix prevents Odoo Studio from saving an invalid link when users create a related field based on partner child contacts from a sales order. It avoids crashes during later field updates, making Studio customizations more reliable.
Original PR description
On sale order, create a related field to res_partner.child_ids Before this commit, the related field is not stored but has a relation_field to parent_id (res.partner) During an onchange (outside of studio), this will crash. After this commit, we unset relation_field in this case as it doesn't make sense (the relation_field should reference a res.partner field, not a field presetn in the current model) opw-5155440 Forward-Port-Of: odoo/enterprise#97107 Forward-Port-Of: odoo/enterprise#96950
This update makes the system check and update old session activity records in smaller batches instead of all at once. This helps avoid long database operations on large installations and keeps session-related maintenance more reliable.
Original PR description
The commit: https://github.com/odoo/odoo/commit/6fb676a4e3566c781ddd57480a200cddc88d99ae adds the model `res.device.log` which will hold a lot of data. In order to use this data efficiently, we decide to process data with the boolean field `revoked` equal to `True` (via the indexes). This boolean field indicates whether the session that generated the log is still present on the disk. The commit: https://github.com/odoo/odoo/commit/e4c9d1794f2d4873755a8692f4861ba043fac943 adds an automatic verification mechanism to change this value if necessary. Between the time the model was created and the time the verification mechanism was implemented, the table may have become too large. This will result in a very long write within a transaction. The purpose of this commit is to introduce a method for performing the batch writing. Forward-Port-Of: odoo/odoo#225736
Odoo now prevents users from saving a Next Check Number that is too large for the system to store. Instead of a technical RPC/database error, users receive a clear validation message, improving usability in bank journal configuration.
Original PR description
**Issue** When trying to set a very large value as *Next Check Number* in a Bank Journal, Odoo raises a low-level `RPC_ERROR` caused by a PostgreSQL `integer out of range` error. This results in a technical traceback instead of a clear message to the user. **Steps to Reproduce** 1. Go to *Accounting > Configuration > Journals* 2. Open the Bank Journal 3. Go to the *Outgoing Payments* tab 4. Enable *Manual Numbering* 5. Set *Next Check Number* to `2147483648` **Root Cause** The field `ir.sequence.number_next` is stored as an integer in the ORM. Any value greater than `2,147,483,647` (max signed 32-bit integer) causes PostgreSQL to raise an overflow error when saving. Since the error occurs deep in the ORM write call, the user only sees a generic RPC error without explanation. Opw-5042096 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225103
The product configurator now uses space better on mobile screens when optional products have custom attribute fields. This keeps input fields and the cart button visible and easier to use, improving the shopping experience on smaller devices.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a product attribute with a single custom value; 2. add the attribute to a product A; 3. set product A as an optional product of product B; 4. go to product B's product page in mobile view; 5. click on the cart button. Issue ----- The custom text field takes up way too much real estate. Cause ----- The template isn't fully adapted for mobile view. Solution -------- Change `d-flex` to `d-lg-flex` on the `ptal` element, making the attribute name & input online display in-line on large screens. Additionally, change some bootstrap classes to also have the cart button button displayed within the screen. opw-5114495 Forward-Port-Of: odoo/odoo#231744 Forward-Port-Of: odoo/odoo#230743
This fix ensures Mexican electronic invoicing XML attachments are created with the correct XML file type even when the user has limited access rights. This prevents related Documents from being missed when accounting centralization is enabled, improving reliability for affected accounting workflows.
Original PR description
When creating an XML attachment as a user without Write access on the ir.ui.view model, the Mimetype will be set to plain/text. In particular, this causes issues when Accounting centralization is enabled in Documents, as the corresponding Document will only be generated if the Mimetype is application/xml. Creating the XML as Superuser avoids this issue. Similar to https://github.com/odoo/odoo/pull/124507 opw-5057038 Forward-Port-Of: odoo/enterprise#97258 Forward-Port-Of: odoo/enterprise#95197
This update adds validation for Dutch structured payment references and prevents unstructured payment notes from being incorrectly placed into SEPA QR code structured reference fields. This helps reduce payment processing mistakes for businesses using QR codes, especially in the Netherlands.
Original PR description
[SEE THIS PR](https://github.com/odoo/odoo/pull/200922) [IMP] account: Check NL structured reference The aim of this commit is implementing a new function to check the structured reference for the Netherlands. Even if dutch people can use the ISO format, they can still use the NL format. no task id [FIX] account_qr_code_sepa: Don't fill structured communication with unstructured communication This commit ensures that unstructured communication is not mistakenly used as structured communication in the QR code values. To achieve this, we use is_valid_structured_reference, a simple validation approach that checks all available is_valid_structured_reference functions. While this method may lead to occasional false positives, we consider this trade-off acceptable. opw-4575004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231373
Users can now add image comments to Twitter posts from the Social app without upload errors. Comment text is also preserved when adding files or emojis, preventing accidental loss of drafted or edited comments.
Original PR description
Issue 1 ======= Steps to reproduce ----------------------- 1. Go to the Social app. 2. Create or Select any twitter post. 3. Add a comment to that post with an image. 4. Press Enter. ---> An error…
Issue 1
=======
Steps to reproduce
-----------------------
1. Go to the Social app.
2. Create or Select any twitter post.
3. Add a comment to that post with an image.
4. Press Enter.
---> An error notification will be shown.
When adding an image in a post comment to Twitter, the image was not uploaded properly because the MIME type was not set, and it defaulted to `application/octet-stream`.
This caused the following error:
```
{"errors": [{"parameters": {"$.media_type": ["'application/octet-stream'"]},
"message": "$.media_type: does not have a value in the enumeration
[video/mp4, video/webm, video/mp2t, video/quicktime, text/srt, text/vtt,
model/gltf-binary, model/vnd.usdz+zip, image/jpeg, image/gif, image/bmp,
image/png, image/webp, image/pjpeg, image/tiff]"}], "title": "Invalid Request",
"detail": "One or more parameters to your request was invalid.",
"type": "https://api.twitter.com/2/problems/invalid-request"}
```
From the above error, it's clear that Twitter only accepts specific MIME types.
This fix ensures the image has the correct MIME type so it can be uploaded without issues.
-------------------------------------------------------------------------------------------------------------------------------
Issue 2
=======
Steps to Reproduce
------------------------------
1. Select any post from social feed.
2. Add text comment or edit existing comment.
3. Upload file or add emoji.
=> The comment text is cleared/reset to its initial value.
Technical
------------------------------
With commit [1] we added `t-att-value` which sets the value of the textarea
on every re-render of the component.
After this commit
------------------------------
The initial value is only set once when component is mounted.
Removed `remove image` button for attachment while posting comments.
[1] https://github.com/odoo/enterprise/commit/ced5e88f433b7b9a8e1429259cd8bb6594b34852
Task-4845385
Forward-Port-Of: odoo/enterprise#91995Fixes an issue where the import screen could crash when a model offered more than one sample import template. Users can now reliably choose from multiple import templates, with cleaner button spacing for a better experience.
Original PR description
Import templates are defined on models to allow developpers to provide
sample import files to users. These templates are fetched by the client
as an array of objects of the form {label: string, template: string},
where label is the label to display and template the URL of the file.
The iteration on `importTemplates` goes through this list, and if more
than one element is present in it, the t-key for both elements will be
the same (`[[object Object]]`), leading to a crash of the client
action's template.
This commit uses the 'template' url as the key, as it should be unique
(the label is less trustworthy, as it is translatable).
It also slightly changes the styling, as having an mb32 between multiple
buttons looked rather bad.
Forward-Port-Of: odoo/odoo#231521
Forward-Port-Of: odoo/odoo#231407Spanish electronic invoices now preserve the correct product price precision and use the invoice’s existing tax totals when global tax rounding is enabled. This reduces rounding mismatches in generated Facturae XML files and helps invoices match official accounting amounts more reliably.
Original PR description
This PR is the opportunity to fix two mistakes in the XML generation of the e-Factura : 1. It is possible for a product to have more decimals than the currency, but the facturae always rounded…
This PR is the opportunity to fix two mistakes in the XML generation of the e-Factura : 1. It is possible for a product to have more decimals than the currency, but the facturae always rounded according to the currency. This would sometimes lead to both rounding errors and incomplete or incorrect values on the generated XML. This commit rounds product prices according to the unit price decimal while leaving the other computed field untouched as to not disturb the correct computation elsewhere. 2. When the tax rounding was set to round_globally, the TotalTaxOutput in the XML might differ from the actual tax_amount from the invoice because of rounding errors occurring during uncessary re-computation while building the XML. While stable is not the place to change all functions related, we can isolate computed tax output and tax withheld values and transmit them without any intermediary. As this file was changed in 18.0 another PR was needed from 17.0: https://github.com/odoo/odoo/pull/209623 (unit price decimals) and https://github.com/odoo/odoo/pull/229017 (tax rounding issue, detected after 209623 was closed) task-4650439 Forward-Port-Of: odoo/odoo#231424 Forward-Port-Of: odoo/odoo#229236
A problem in account reporting calculations was corrected to ensure the right records are used during processing. This helps prevent incorrect or inconsistent report behavior for finance users.
Original PR description
Forward-Port-Of: odoo/enterprise#97144
7 changes
Enhancements to existing features
Changes made to POS category names or ordering now carry over to UrbanPiper when the menu is synced again. This keeps online ordering menus aligned with the latest point-of-sale setup and reduces manual correction work.
Original PR description
Before this commit: ----------------------------------------- - After syncing the menu, changes in a POS category (e.g., name or sequence) were not reflected in UrbanPiper when the menu was synced again. After this commit: ----------------------------------------- - Category updates (name or sequence) are now synced with UrbanPiper on subsequent menu syncs. Task-5122804 Forward-Port-Of: odoo/enterprise#96270
Resolved issues and error corrections
This fix prevents Web Studio from saving an invalid link when users create a related field to a contact’s child records from another model, such as sales orders. It avoids crashes during later form updates, making Studio-created customizations safer and more reliable.
Original PR description
On sale order, create a related field to res_partner.child_ids Before this commit, the related field is not stored but has a relation_field to parent_id (res.partner) During an onchange (outside of studio), this will crash. After this commit, we unset relation_field in this case as it doesn't make sense (the relation_field should reference a res.partner field, not a field presetn in the current model) opw-5155440 Forward-Port-Of: odoo/enterprise#97107 Forward-Port-Of: odoo/enterprise#96950
The Point of Sale customer list now correctly shows deposited amounts for partners after deposits are made through Customer Account. This helps staff see customer balances directly in PoS and avoid confusion when managing deposits.
Original PR description
The partner list in the PoS was never showing the deposited amount for the partners. Steps to reproduce: ------------------- * Open PoS and make a deposit for a partner using the Customer Account * Check the partner list > Observation: No deposited amount is shown Why the fix: ------------ We backport the part of this fix odoo/enterprise@bf4b604 that changes the partner list to show the deposited amount. opw-4954740 Forward-Port-Of: odoo/enterprise#95597
This fixes an issue where Mexican EDI XML attachments could be saved with the wrong file type when created by users with limited permissions. The correct XML format ensures related Documents are generated properly when accounting centralization is enabled.
Original PR description
When creating an XML attachment as a user without Write access on the ir.ui.view model, the Mimetype will be set to plain/text. In particular, this causes issues when Accounting centralization is enabled in Documents, as the corresponding Document will only be generated if the Mimetype is application/xml. Creating the XML as Superuser avoids this issue. Similar to https://github.com/odoo/odoo/pull/124507 opw-5057038 Forward-Port-Of: odoo/enterprise#97258 Forward-Port-Of: odoo/enterprise#95197
This update fixes issues in the Social app when commenting on Twitter posts. Images now upload with the correct file type, and comment text is no longer lost when adding files or emojis.
Original PR description
Issue 1 ======= Steps to reproduce ----------------------- 1. Go to the Social app. 2. Create or Select any twitter post. 3. Add a comment to that post with an image. 4. Press Enter. ---> An error…
Issue 1
=======
Steps to reproduce
-----------------------
1. Go to the Social app.
2. Create or Select any twitter post.
3. Add a comment to that post with an image.
4. Press Enter.
---> An error notification will be shown.
When adding an image in a post comment to Twitter, the image was not uploaded properly because the MIME type was not set, and it defaulted to `application/octet-stream`.
This caused the following error:
```
{"errors": [{"parameters": {"$.media_type": ["'application/octet-stream'"]},
"message": "$.media_type: does not have a value in the enumeration
[video/mp4, video/webm, video/mp2t, video/quicktime, text/srt, text/vtt,
model/gltf-binary, model/vnd.usdz+zip, image/jpeg, image/gif, image/bmp,
image/png, image/webp, image/pjpeg, image/tiff]"}], "title": "Invalid Request",
"detail": "One or more parameters to your request was invalid.",
"type": "https://api.twitter.com/2/problems/invalid-request"}
```
From the above error, it's clear that Twitter only accepts specific MIME types.
This fix ensures the image has the correct MIME type so it can be uploaded without issues.
-------------------------------------------------------------------------------------------------------------------------------
Issue 2
=======
Steps to Reproduce
------------------------------
1. Select any post from social feed.
2. Add text comment or edit existing comment.
3. Upload file or add emoji.
=> The comment text is cleared/reset to its initial value.
Technical
------------------------------
With commit [1] we added `t-att-value` which sets the value of the textarea
on every re-render of the component.
After this commit
------------------------------
The initial value is only set once when component is mounted.
Removed `remove image` button for attachment while posting comments.
[1] https://github.com/odoo/enterprise/commit/ced5e88f433b7b9a8e1429259cd8bb6594b34852
Task-4845385
Forward-Port-Of: odoo/enterprise#91995This update corrects an internal calculation issue in accounting reports that could lead to unreliable report values in some cases. It helps ensure financial reports are generated consistently and accurately for users.
Original PR description
Forward-Port-Of: odoo/enterprise#97144
Barcode package scanning now follows the delivery setting that blocks unplanned products, preventing staff from accidentally adding the wrong package contents to an order. The update also lets users remove package lines in barcode workflows, making mistakes easier to correct during warehouse operations.
Original PR description
## Issue 1: "Allow Extra Products" option ignored for packages ### Steps to reproduce: - In the settings enable "Packages" - Go to Inventory > Configuration > Warehouse Management > Operation Types -…
## Issue 1: "Allow Extra Products" option ignored for packages
### Steps to reproduce:
- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
- 10 x P1 in a package PACK01
- 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.
### Cause of the issue:
The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the `barcode_allow_extra_product` option and creates its new lines via the private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671
### Fix:
Since scanning a package is expected to add all its content to the picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.
## Issue 2: impossibility of package line removal
### State of the art:
There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.
#### Steps to reproduce:
- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
- 10 units in package PACK01
- 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean
opw-4863621
opw-5080637
Forward-Port-Of: odoo/enterprise#9629916 changes
Enhancements to existing features
Two sample invoice documents have been moved from the Taxes subfolder to the main Finance folder. This keeps demo content better organized and makes finance documents easier to find in the expected location.
Original PR description
Move two invoice demo files from the 'Taxes' subfolder to the parent 'Finance' folder. This makes more sense as they are not relevant to taxes. Task-5075610
Asset invoice account searches now show clearer descriptions and better distinguish asset accounts from expense accounts, helping users choose the right account faster. The update also removes less useful details from the extended search view and corrects some Belgian account classifications for fixed assets.
Original PR description
It was hard to quickly find accounts to use on Asset Invoices (invoices where I buy something whose value I should depreciate over time):
- descriptions were lacking some examples
- it was hard to differentiate Expense and Asset accounts
- "Search More" view was displaying useless information
Also, some belgian account types were wrong (non-current assets instead of fixed assets).
task-id: 5123491The uninstall wizard now shows information about affected Studio customizations directly within the list of affected items instead of as a separate warning at the bottom. This makes the impact of uninstalling easier for users to understand before they proceed.
Original PR description
This commit builds upon https://github.com/odoo/odoo/pull/229087 to enhance the uninstall wizard UI related to Studio customizations. The warning alert previously shown at the bottom of the models list has been removed. Instead, information about affected customizations is now displayed as an additional item within the list of affected elements. task-5111398
The Rental Order button in the project topbar has been moved lower in the button order. This creates space for another related action to appear between Sales Orders and Rental Orders, making the topbar organization more flexible.
Original PR description
This commit alters the sequence set on the Rental Order embedded action to be able to put a new embedded action between Sales Order and Rental Orders ones in the project topbar. task-5164352
Point of Sale reporting now includes clearer delivery order insights for UrbanPiper integrations. Businesses can group results by delivery provider, track average preparation time, and see cancelled delivery order counts to better compare platform performance.
Original PR description
In this commit: === - Added support to group delivery order reports by provider (e.g., Zomato, UberEats). - Added field to track average preparation time. - Added field to calculate the number of cancelled delivery orders. task-4904372
Shared project Gantt charts now group tasks by their title instead of by stage. This makes it easier for users to quickly identify and follow individual tasks in shared project views.
Original PR description
Before this PR: --- The Gantt view in project sharing was grouped by stage, which made it difficult to visualize tasks directly by their titles. After this PR: --- The Gantt view in project sharing is now grouped by title, improving clarity for shared projects. task-5138906
Resolved issues and error corrections
Fixes several issues in the document extraction correction screen, including crashes when switching columns, missed line matches, disappearing selection boxes on images, and inaccurate selection while scrolling. This makes manual correction of extracted documents smoother and less disruptive for users.
Original PR description
**[FIX] iap_extract: fix crash when clicking on another column of x2many** When a x2many field is filled using the rectangular selection tool, a crash could occur when the component is busy filling…
**[FIX] iap_extract: fix crash when clicking on another column of x2many** When a x2many field is filled using the rectangular selection tool, a crash could occur when the component is busy filling the values for a field and the user clicks on another column. This happened because the `getNewRecordValues` function was using the current value of `this.activeBoxType` to get the value for the new record. This is incorrect as `this.activeBoxType` can change when the user clicks on another column of the x2many. --- **[FIX] iap_extract: fix line matching in manual correction component** In the logic that handles the matching of selected boxes with existing lines, it was assumed that the existing lines were sorted from top to bottom, but that wasn't guaranteed. When it's not sorted, the out-of-order existing lines couldn't be match to the selected boxes. --- **[FIX] iap_extract: fix loss of focus when clicking on image viewer** When the attachment showed by the viewer is an image and the selected field is a date, a click on the image (to start a rectangular selection or to click a box) would cause a loss of focus on the field which caused the boxes to disappear, making it unusable. This happened because the date fields are displaying a calendar popup which listens on the `pointerdown` event to hide itself when the click occurs outside of it. This causes the loss of focus of the field which hides the boxes. On top of this, we also need to prevent the propagation of the click event when it occurs on the box layers, as it also causes the loss of focus on x2many fields (there is a global click event listener that exits the edit mode when the click occurs on another element). These issues weren't noticed before as they only occur on image attachments. On PDFs, the viewer is embedded in an iframe that prevents the `pointerdown` and `click` events to be visible to the main document. --- **[FIX] iap_extract: fix rectangular selection on scrollable images** The rectangular selection needs to be adjusted when the user scrolls while selecting boxes. This was already properly handled for PDFs, but not for image attachments. Forward-Port-Of: odoo/enterprise#96975
This fixes how Odoo Studio identifies the original view structure when simplifying customized screens. It helps prevent incorrect Studio view processing in cases where an inherited view is also treated as a main view, improving reliability for affected customizations.
Original PR description
Since commit 52f27c457e50a61c3b11c59e3fdd5ddd383f1317, the normalize function applies on `self` (ir.ui.view) and can take a string representing the arch to normalize. The normalization then occurs on the combination of the two, outputing a simplified version of the arch passed as a string in arguments. The base arch (`combined_arch`) is retrieved from self. Before this commit, this was done by controlling on self.inherit_id, which did not cover all bases to retrieve the main view's combined arch without the studio inheritance. After this commit, this is done by controlling on self.mode, because an inherited view can also be a root view. opw-5154217 Forward-Port-Of: odoo/enterprise#96992
Social app users can now post Twitter comments with images without upload errors, because the image type is correctly sent to Twitter. Comment drafts are also preserved when adding emojis or attachments, reducing accidental text loss while replying or editing comments.
Original PR description
Issue 1 ======= Steps to reproduce ----------------------- 1. Go to the Social app. 2. Create or Select any twitter post. 3. Add a comment to that post with an image. 4. Press Enter. ---> An error…
Issue 1
=======
Steps to reproduce
-----------------------
1. Go to the Social app.
2. Create or Select any twitter post.
3. Add a comment to that post with an image.
4. Press Enter.
---> An error notification will be shown.
When adding an image in a post comment to Twitter, the image was not uploaded properly because the MIME type was not set, and it defaulted to `application/octet-stream`.
This caused the following error:
```
{"errors": [{"parameters": {"$.media_type": ["'application/octet-stream'"]},
"message": "$.media_type: does not have a value in the enumeration
[video/mp4, video/webm, video/mp2t, video/quicktime, text/srt, text/vtt,
model/gltf-binary, model/vnd.usdz+zip, image/jpeg, image/gif, image/bmp,
image/png, image/webp, image/pjpeg, image/tiff]"}], "title": "Invalid Request",
"detail": "One or more parameters to your request was invalid.",
"type": "https://api.twitter.com/2/problems/invalid-request"}
```
From the above error, it's clear that Twitter only accepts specific MIME types.
This fix ensures the image has the correct MIME type so it can be uploaded without issues.
-------------------------------------------------------------------------------------------------------------------------------
Issue 2
=======
Steps to Reproduce
------------------------------
1. Select any post from social feed.
2. Add text comment or edit existing comment.
3. Upload file or add emoji.
=> The comment text is cleared/reset to its initial value.
Technical
------------------------------
With commit [1] we added `t-att-value` which sets the value of the textarea
on every re-render of the component.
After this commit
------------------------------
The initial value is only set once when component is mounted.
Removed `remove image` button for attachment while posting comments.
[1] https://github.com/odoo/enterprise/commit/ced5e88f433b7b9a8e1429259cd8bb6594b34852
Task-4845385
Forward-Port-Of: odoo/enterprise#91995This fixes a crash in Odoo Studio when users add a related monetary field on the same model, including its currency field. The change lets the Studio setup flow complete as expected, reducing disruption when customizing business screens.
Original PR description
In studio, add a related field to a monetary on the current model (ie without dotnames) Before this commit, it crashed. This because of c57c247490f0f58c8746af47ce035c28137faf97 After this commit, the flow works as expected opw-5147572 Forward-Port-Of: odoo/enterprise#97214
This fix corrects how the Belgian reporting partner form is linked so the required citizen identification field can be found during module updates. It prevents update failures and server errors when installing or upgrading the Belgian reports functionality.
Original PR description
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view. That led to…
The citizen_identification field was added to the partner view in l10n_be_reports, but the form 281.50 view for this required field was incorrectly inheriting from the base partner view.
That led to a traceback when updating account_reports/l10n_be_reports modules:
```py
Odoo Server Error
Occured on 86642809-master-all.runbot135.odoo.com on model ir.module.module on 2025-08-11 14:04:32 GMT
Traceback (most recent call last):
------- A lot of calls ------
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/data/build/odoo/odoo/tools/convert.py", line 745, in convert_xml_import
obj.parse(doc.getroot())
File "/data/build/odoo/odoo/tools/convert.py", line 616, in parse
self._tag_root(de)
File "/data/build/odoo/odoo/tools/convert.py", line 559, in _tag_root
f(rec)
File "/data/build/odoo/odoo/tools/convert.py", line 570, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /data/build/enterprise/account_followup/views/partner_view.xml:4
Error while parsing or validating view:
Element '<xpath expr="//field[@name='citizen_identification']">' cannot be located in parent view
View error context:
{'file': '/data/build/enterprise/account_followup/views/partner_view.xml',
'line': 1,
'name': 'res.partner.view.form',
'view': ir.ui.view(5824,),
'view.model': 'res.partner',
'view.parent': ir.ui.view(127,),
'xmlid': 'res_partner_view_form'}
```Annual Statements can now include localized report variants even when those variants are made up of multiple sections. This prevents errors during setup or upgrades and keeps the correct local financial reports available automatically.
Original PR description
The "Annual Statements" report comes with additional code at create() and write() of account.report, so that any new localized variant of the Balance Sheet, Trial Balance or Profit & Loss will automatically replace its root report in the Annual Statements report's sections. The idea behind that is to "magically" replace those generic reports by the right variant when it's created. The problem with that came when you tried adding a variant to one of those reports that was itself a composite report. In such case, you got a traceback stating a composite report's sections could not have sections themselves. We indeed only support one level of hierarchy for composite reports. We solve the issue by adding all the sections of such composite variant to the Annual Statements instead of adding the variant itself. Bug originally reported by Upgrade, here https://github.com/odoo/upgrade/pull/8571 . Forward-Port-Of: odoo/enterprise#97145
Fixes an issue where returning a regular product included in a rental order could leave the sale order showing the wrong delivered quantity. This improves accuracy for deliveries, returns, and related invoicing in rental workflows.
Original PR description
**Issue**: Returning a non-rental product in a rental order does not correctly update the delivered quantity. **Steps to reproduce**: - Enable rental transfers via Settings > Rental. - Create a…
**Issue**: Returning a non-rental product in a rental order does not correctly update the delivered quantity. **Steps to reproduce**: - Enable rental transfers via Settings > Rental. - Create a rental order with (in that order!): - A rental product - A non-rental product - Confirm the rental order. - Open the related sale order. - Go to the delivery and validate it. - Return the delivery and validate the return. - Observe that the delivered quantity in the sale order is incorrect. **Cause**: The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return. **Solution**: Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location. opw-4894358 Forward-Port-Of: odoo/enterprise#97067 Forward-Port-Of: odoo/enterprise#91825
This fix updates access settings so Swiss payroll-related employee fields use the correct payroll user permissions. HR officers can now access employee records as expected, preventing related automated workflow failures.
Original PR description
Some fields on the version were still with the hr_user group where they should be payroll_user. This was causing some tour to fail when an HR officer tries to access an employee. Build error: https://runbot.odoo.com/odoo/runbot.build.error/233204 Forward-Port-Of: odoo/enterprise#97175 Forward-Port-Of: odoo/enterprise#97096
Features or functions removed from Odoo
The WhatsApp module no longer includes demo data that conflicted with test data and did not provide useful business value. This helps keep testing and sample setups cleaner and reduces avoidable errors in demo environments.
Original PR description
Conflicts with test data, and according to tde these demo data make no sense as they do nothing useful. Closes #86194 https://runbot.odoo.com/odoo/error/223071 Forward-Port-Of: odoo/enterprise#97138
Code cleanup and technical improvements
Enterprise modules were updated to work with a related platform change where currency rate lookups now also include the rate date. This keeps reports, subscriptions, and localization documents aligned with the latest shared behavior without changing day-to-day workflows.
Original PR description
Now _get_rates() returns also the rate date. Change the enterprise usage. task-5109447 https://github.com/odoo/odoo/pull/228442 https://github.com/odoo/upgrade/pull/8593
13 changes
New functionality added to Odoo
This adds a new Sri Lanka localization package with core accounting setup and statutory reports, including balance sheet, profit and loss, VAT, and withholding tax reporting. Businesses operating in Sri Lanka can use Odoo with more country-specific accounts, taxes, fiscal positions, and report templates out of the box.
Original PR description
Adds basic reporting module for Sri Lanka, including: - Balance sheet - Profit & loss task-4352802 retargetted from master #93586
Resolved issues and error corrections
This fixes an issue where reading linked attachment records could trigger inefficient filtering and miss the proper access-handling path. The change makes these reads more reliable and helps avoid performance problems for records with many linked attachments.
Original PR description
Reading `attachment_ids` on a Many2many field uses `_search` on the comodel, but does not necessarily use the `bypass_search_access` flag because we are reading (not searching). On some models, such as attachments, the `_search` method may start filtering all data in memory. To avoid such cases, if the method is overwritten, generate the query on the comodel with bypassing accesses, then join with the model ids, retrieve the records and filter them. closes #226845 closes #226908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes how Odoo reads linked records so that related lists behave consistently across different relationship types. It helps prevent users from being blocked incorrectly when viewing records they are allowed to access, while also adjusting activity handling to avoid unintended access bypasses.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: Alternative to #226845. Align the behavior of o2m and m2m. Todo: test performance for activities. It seems that having access to a record does not grant access to all linked activities? To check this as well. Closes #226845 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where certain many-to-many field values could fail to load when access bypass rules were configured. The change restores the intended behavior so authorized business workflows can read related records without unnecessary access errors.
Original PR description
Recently, we have changed how Many2many fields are read. Before we used `_apply_ir_rules` to give `read` access to comodels, now we're using `_search` directly. We have `bypass_search_access` to bypass access checks, but it's not handled when we do a `_search` from the `read` method. This commit allows bypassing access checks for the Many2many field, where `bypass_search_access` is True. Ref: https://github.com/odoo/odoo/commit/9a21edd99e7f50a785b8b7720f55654254d5f481 , https://github.com/odoo/odoo/pull/217277 Task-5081728
Failed email notifications for accounting journal aliases now use the company linked to that journal instead of defaulting to the main company. This prevents customers or senders from receiving bounce messages with the wrong company name or contact email in multi-company setups.
Original PR description
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an…
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an corresponding email template. But as is, the usage of `'company_email': self.env.company.email` and `'company_name': self.env.company.name` will default to the "main" company (id 1 usually), as during the message routing, that will be the default company in `env`. This means, that if you have an journal email alias in company B, the email will still render the information of the main company A. ## Proposed fix: When a journal email alias is created in a standard way, it should have a key:value pair for 'company_id' in the `alias_defaults` field. We change the routing check logic so that it will try to fetch that value, while defaulting to the main company if there is no explicit company `company_id` key. This should ensure that the mail gateway failed email renders preferentially renders the company information of the company the mail alias (and accounting journal) belongs to. OPW-5132806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231436
Loyalty points are now recalculated when the point-of-sale receipt screen is refreshed. This prevents customers and staff from seeing outdated or inconsistent loyalty point totals after a refresh.
Original PR description
Before this commit: --------- - Loyalty points are not recalculated when the receipt screen is refreshed. After this commit: ---------- - Ensures that loyalty points are properly recalculated when the receipt screen is refreshed, preventing inconsistencies in displayed points. task-5106892 Forward-Port-Of: odoo/odoo#229516
This fixes an issue in Odoo Studio where creating a related monetary field on the same model could cause a crash. Users can now complete this field setup normally, improving reliability when customizing forms and models.
Original PR description
In studio, add a related field to a monetary on the current model (ie without dotnames) Before this commit, it crashed. This because of c57c247490f0f58c8746af47ce035c28137faf97 After this commit, the flow works as expected opw-5147572 Forward-Port-Of: odoo/enterprise#97214
Restaurant point-of-sale orders now keep combo meals together when staff move items between courses. This prevents part of a combo from being left behind, reducing order mistakes and improving service flow.
Original PR description
Steps to reproduce: ------------------------- - Install POS restaurant & create order with multiple courses - Add a combo product in one of the course - Select a combo child line and try to transfer course Issue: ------- - Only the selected child line is transferred to the new course instead of the entire combo. Cause: --------- - The system currently transfers only the selected order line without checking whether it belongs to a combo. Fix: ---- - Updated the logic to check if the selected order line is part of a combo. If so, the entire combo (parent and child lines) will now be moved to the new course together. task: 5005141 Forward-Port-Of: odoo/odoo#222423
Point of Sale receipts now show the selected ship-later date correctly, without accidental timezone changes. This prevents customers and staff from seeing the wrong delivery date after validating an order.
Original PR description
PURPOSE: ---------------- - Fix incorrect handling of shipping date in POS . It was treated as a datetime, which led to timezone shifts and wrong dates in receipts. STEPS TO REPRODUCE:…
PURPOSE: ---------------- - Fix incorrect handling of shipping date in POS . It was treated as a datetime, which led to timezone shifts and wrong dates in receipts. STEPS TO REPRODUCE: ------------------- 1. Open point of sale 2. In Configuration → Settings, enable Allow Ship Later for a POS shop. 3. Open a POS session, add a product, proceed to payment, and select Ship Later. 4. Validate the order. ISSUE: -------------------- - The receipt shows the wrong shipping date. CAUSE: --------------------- - shipping_date was serialized using serializeDateTime, forcing a UTC conversion. - Related models only supported datetime type, so date fields were mishandled. FIX: -------------------- - Introduced proper date handling (convertRawToDate, convertDateToRaw). - Updated serialization/deserialization to handle both `date` and `datetime`. - Changed ShippingDate to use serializeDate instead of serializeDateTime. Task-5055738 Forward-Port-Of: odoo/odoo#227693
This change prevents the online shop page from breaking after a website language is added. It improves reliability for multilingual websites by ensuring translation text is handled safely in the shop template.
Original PR description
Currently an error occurs when user tries to load translations to website. **Steps to replicate:** * Install `website_sale` * website > Edit > Theme > Add a Language > Add any language * Go to shop >…
Currently an error occurs when user tries to load translations to website.
**Steps to replicate:**
* Install `website_sale`
* website > Edit > Theme > Add a Language > Add any language
* Go to shop > you should get an error in the terminal.
**Error:**
`Qweb Error:
Error while rendering the template:
SyntaxError: invalid syntax (<>, line 1)
Template: website_sale.products
Reference: website_sale.products`
**Root cause:**
* When the placeholder variable is not set, the string 'placeholder' is passed to the template [1].
* This 'placeholder' value is translated, and a `<span>` tag is added as its value [2]. This result is then passed to [3], which in turn is passed as an expression to [4], causing the error.
**Solution:**
* Define the placeholder inside the `<t>` tag instead of passing it as a parameter to avoid mistranslation.
[1]:
https://github.com/odoo/odoo/blob/97294a2798f5fd20748ad1e0f4a9bd2403fd7d1a/addons/website_sale/views/templates.xml#L727
[2]:
https://drive.google.com/file/d/1gpDa8Ua9Zq8XMHKmL3FbVAtetech_twP/view?usp=sharing
[3]:
https://github.com/odoo/odoo/blob/97294a2798f5fd20748ad1e0f4a9bd2403fd7d1a/odoo/addons/base/models/ir_qweb.py#L2558
[4]:
https://github.com/odoo/odoo/blob/97294a2798f5fd20748ad1e0f4a9bd2403fd7d1a/odoo/addons/base/models/ir_qweb.py#L1550
sentry-6917649923This fixes an inventory issue where barcode deliveries for a different lot could create an unassigned negative stock entry instead of linking it to the correct lot. Businesses get more accurate stock records and avoid later receipt mismatches that leave quantities unbalanced.
Original PR description
Uecase to reproduce: - Create a quant with a product and 10 lot A - Create a delivery order - Open barcode - In barcode, deliver the product with lot C Current behavior: You have 2 quants: - 10 lot A - -1 without lot Expected behavior: - 10 lot A - -1 lot C It happens because the code try to balance negative quant for lot/sn in a stack of quants without lot/sn for the product. However in this case the barcode create a quant without quantity and without lot. In this case the system wants to update it due to an incorrect condition. It's an issue since in later receit with the correct lot. The quant will never be balanced and it will result with - -1 without - 1 lot C Moved the test `test_multi_step_update` since it was in the middle of test mixed reservation and push to a mistake of duplicated tests
This update makes web editor testing more reliable by explicitly setting a border color instead of relying on environment defaults. It helps avoid inconsistent automated build failures, improving confidence in release checks without changing user-facing behavior.
Original PR description
Problem: Runbot build fails due to different resulting `border-color` values. Cause: The default `border-color` can change depending on the environment, leading to non-deterministic behavior. Solution: Specify the `border-color` explicitly to ensure consistent results. runbot-233297 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231716 Forward-Port-Of: odoo/odoo#231003
This update prevents the editor from creating invalid page structure when users change the style of text inside certain formatted elements. It helps ensure edited website content remains consistent and displays as expected across browsers.
Original PR description
Before this commit we would insert a block inside of a phrasing content if it's displayed as a block. For example, if we tried to modify text inside of a `<small>` that has `display: block` style, it would insert a new block inside of it. Steps to see the issue: - Have an open editor with `<small>Text</small>` content, that has `display: block` style - Select "Text" and change the font style to paragraph => It will be `<small><p>Text</p></small>` which is not valid HTML, and it will be parsed by a browser as `<small></small><p>Text</p>`, which is not the expected behavior. X-original-commit: 4e6df797f152e473d76e6d60ba31da52123cabd3
27 changes
Enhancements to existing features
The salary configurator sidebar now has better spacing between field labels and their tooltip icons. This small visual improvement makes the interface cleaner and easier to read for HR users.
Original PR description
In the salary configurator sidebar some fields have a tooltip to explain how the value is calculated, the icon for that tooltip had no margin between itself and the label. This commit adds a margin between them to make it more visually pleasing. Task ID: 5138530 Forward-Port-Of: odoo/enterprise#96483
Resolved issues and error corrections
This change restores the previous currency translation behavior for cumulative translation adjustments in accounting reports. It avoids incorrect year-over-year balance sheet revaluations, helping financial statements reflect the intended exchange-rate treatment.
Original PR description
This reverts commit c440bb52d19b8dcec8b708509973c4095a577b34 as it doesn't work as expected in year-over-year re-evaluation in balance sheets. task-5085888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change restores the previous currency translation behavior for financial reports, using the closing exchange rate instead of the current rate. This helps ensure reported balances match expected accounting treatment and avoids unexpected differences in payables, receivables, ledgers, and trial balances.
Original PR description
This reverts commit 0719c63a646c360a4b090745cd8105128332ef38. task-5085888
Users who do not have access to the company’s internal project can now create a timesheet without encountering an error. If the default internal project is not accessible, the system leaves the project field blank instead, allowing normal timesheet entry to continue.
Original PR description
To reproduce: ============= - make the internal project of the company for invited internal users only - with internal user that doesn't have access to the internal project, and no previous timesheet created, try to create a timesheet - you get a traceback Problem: ======== when not having a previous timesheet, in the default value we set project_id based on the internal project of the company. But if the user doesn't have access to this project, it raises an access error. Solution: ========= check if the user has access to the internal project of the company, if not, use `False` as default value. opw-5119839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users assigned to tasks in private projects can now print or export their own timesheets without seeing an access error. This removes an inconsistency that blocked reporting when the selected entries came from a single private project.
Original PR description
****Behavior:**** **Current:** When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as…
****Behavior:**** **Current:** When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as it appears under "My Tasks". The user might then want to print or export the timesheets form the list view. - If the selected timesheets come from only a single private project : an Access Error is raised - If the selected timesheets come from multiple private projects, or a mix of public and private ones : no Error is raised The issue comes from the need to access to the project's name (since the project is private to the user the code raises the error) as well as the company's name. And it only happens when single projects are selected, in the other cases, the exported pdf shows the project's name at another location without error. **Expected:** Since the information is already accessible through multiple other places in odoo (and even in the exported pdf), we should allow the access here aswell. So now when printing or exporting a timesheet from a single private project, no Access Error is raised. **Steps to reproduce:** - Create 2 different projects - Create a task in each - Assign it to another user (Make sure the other user only has user access to timesheets and projects) - Set each project's visibility setting to private - Log in with the other user - Go to Timesheets --> List View Single projects: - Select one or multiple timesheet entries from one of the private projects - Select Print -> Timesheets - You should see an Access Error Multiple projects: - Select one or multiple timesheet entries from a combination of both private projects - Select Print -> Timesheets - You should not have any Errors opw-5127526 Forward-Port-Of: odoo/odoo#231188
This fix prevents access errors when checking transaction dates used for loyalty reward expiration. It ensures the system can read the needed transaction dates reliably, so eligible loyalty benefits are evaluated without interrupting sales workflows.
Original PR description
Versions -------- - 17.0 - 18.0 - saas-18.2 Fixed in saas-18.3+ during forward porting. Issue ----- Checking transaction dates for loyalty expiration can lead to access errors. Cause ----- Transactions aren't checked using `sudo`. Solution -------- Use `sudo` to get the transaction dates. opw-4765873 Forward-Port-Of: odoo/odoo#231024
This fixes an issue where Mexican electronic invoice XML files could be saved with the wrong file type when created by users with limited permissions. The change helps ensure related accounting documents are generated correctly, especially when Documents centralization is enabled.
Original PR description
When creating an XML attachment as a user without Write access on the ir.ui.view model, the Mimetype will be set to plain/text. In particular, this causes issues when Accounting centralization is enabled in Documents, as the corresponding Document will only be generated if the Mimetype is application/xml. Creating the XML as Superuser avoids this issue. Similar to https://github.com/odoo/odoo/pull/124507 opw-5057038 Forward-Port-Of: odoo/enterprise#95197
When users click “View More Themes” during website setup, the page now shows a fullscreen loading indicator. This prevents users from accidentally selecting an existing theme while additional themes are still loading, making the setup flow clearer and safer.
Original PR description
Steps to reproduce: 1. Create a new website and proceed to the theme configuration step. 2. Click on View More Themes. -> You’ll notice a loading effect on the button, but the existing themes remain selectable. Before this commit: Users could still select existing themes while additional themes were being loaded. After this commit: A fullscreen loader is displayed while loading more themes via the View More Themes button, preventing any unintended interactions. task-4661292 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 prevents French POS certification checks from treating orders without a secure sequence number as valid previous orders. It avoids incorrect blocking errors during database upgrades or recalculations, helping affected systems complete processing normally.
Original PR description
## Description of the issue/feature this PR addresses: When obtaining the previous order for pos.order records, all orders with l10n_fr_secure_sequence_number == NULL will be recognised as the…
## Description of the issue/feature this PR addresses:
When obtaining the previous order for pos.order records, all orders with l10n_fr_secure_sequence_number == NULL will be recognised as the previous order for those where l10n_fr_secure_sequence_number == 1, as if their sequence value was zero.
## Current behavior before PR:
Since there can be more than one orders without sequence number, this behaviour will trigger an UserError exception, as the ORM will mistakenly deduce that there are multiple previous orders for a single one, which is not necessarily correct.
### Examples:
upg-3170341
```sql
lare_3170341=> SELECT count(id) FROM pos_order WHERE l10n_fr_secure_sequence_number IS NULL;
count
-------
67281
(1 row)
```
```python
# Debugging standard codebase with a Python debugger
...
match = prev_map.get(order.l10n_fr_secure_sequence_number - 1, []) # len(match) == 67281
if len(match) > 1:
raise UserError(_('An error occurred when computing the inalterability...'))
...
```
upg-3170341
```sql
lare_3167621=> SELECT count(id) FROM pos_order WHERE l10n_fr_secure_sequence_number IS NULL;
count
-------
294
(1 row)
```
```python
# Debugging standard codebase with a Python debugger
...
match = prev_map.get(order.l10n_fr_secure_sequence_number - 1, []) # len(match) == 294
if len(match) > 1:
raise UserError(_('An error occurred when computing the inalterability...'))
...
```
---
Traceback group: https://upgrade.odoo.com/odoo/tbg/1869
```
2025-09-30 07:48:30,945 329 INFO db_3167621 odoo.modules.loading: Loading module l10n_fr_pos_cert (110/131)
2025-09-30 07:48:31,375 329 INFO db_3167621 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables
2025-09-30 07:48:31,432 329 INFO db_3167621 odoo.models: Prepare computation of pos.order.previous_order_id
2025-09-30 07:48:31,597 329 WARNING db_3167621 odoo.modules.loading: Transient module states were reset
2025-09-30 07:48:31,597 329 ERROR db_3167621 odoo.modules.registry: Failed to load registry
2025-09-30 07:48:31,597 329 CRITICAL db_3167621 odoo.service.server: Failed to initialize database `db_3167621`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 485, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 365, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 206, in load_module_graph
registry.init_models(env.cr, model_names, {'module': package.name}, new_install)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 618, in init_models
func()
File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_model.py", line 2007, in _reflect_relation
self.env.invalidate_all()
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 839, in invalidate_all
self.flush_all()
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 857, in flush_all
self._recompute_all()
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 850, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7359, in _recompute_field
field.recompute(records)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1463, in recompute
apply_except_missing(self.compute_value, recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1436, in apply_except_missing
func(records)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 427, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5296, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/l10n_fr_pos_cert/models/pos.py", line 79, in _compute_previous_order
raise UserError(_('An error occurred when computing the inalterability. Impossible to get the unique previous posted point of sale order.'))
odoo.exceptions.UserError: Une erreur s'est produite lors de la vérification de l'inaltérabilité. Impossible de récupérer la dernière commande de caisse unique et comptabilisée.
```
## Desired behavior after PR is merged:
The method `pos.order._compute_previous_order` already only checks orders with a sequence number != NULL, so to address this issue, we will use the same condition to retrieve only orders with a valid sequence. This will result in no more exceptions created by incorrect data.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPayment terminals connected through IoT boxes now record each step of a transaction with clearer identifying details. This makes it easier for support teams to trace payment issues and resolve problems faster.
Original PR description
This PR improves the logging of terminals used with iot box. We will now get a log for every step of a transaction along with some information identifying the transaction
Bills created from IRN can now use a valid purchase journal from any company in the tax unit, instead of only checking the main company. This prevents bill creation failures for multi-company tax units when the main company does not have a purchase journal configured.
Original PR description
Before this PR: - The system searched for a purchase journal only in `company_id`. - In a tax unit with multiple companies, if the main company had no purchase journal configured, record creation failed with a 'NOT NULL constraint violated' error. After this PR: - The journal search now checks all companies in `company_ids` (or falls back to `company_id`), - allowing the system to find a valid purchase journal across the tax unit.
This fixes employee contract calendars so past weekends and bank holidays are shown again when reviewing unusual days before the current contract start date. The change keeps draft contracts excluded while allowing expired contracts to provide accurate historical working schedule information.
Original PR description
Since changes made in https://github.com/odoo/odoo/pull/212959, we don't see anymore the week-end and banck holidays before the start date of your current contract. As the goal of the initial commit was to prevent to use the contracts in state 'new', we add the contracts 'exppired' that are contracts of the past that really give information of the working hours. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Rating images in Live Chat and related rating views now use a transparent background instead of showing an unwanted white box in dark mode. This improves visual consistency and readability for users working with dark mode enabled.
Original PR description
**Current behavior before PR:** The rating images have an unintended white background in dark mode. **Steps to Reproduce:** - Turn on Dark Mode - Go to livechat - Go to Report > Sessions History **Desired behavior after PR is merged:** This PR fixes the issue by applying a transparent background to rating images through the `img_class` option in image widget. The change is applied to: - discuss.channel (kanban, list, form views) - rating.rating (form, kanban views) --- **Before:** <img width="372" height="202" alt="image" src="https://github.com/user-attachments/assets/d573ab3e-62be-4ab2-9c7f-e39bf97cb542" /> **After:** <img width="394" height="141" alt="image" src="https://github.com/user-attachments/assets/6133c231-c634-4afd-a99f-5440ecfe72be" /> task-[4689867](https://www.odoo.com/odoo/project/1519/tasks/4689867) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how delivery information is included in Turkish Nilvera export e-invoices. It prevents Nilvera from rejecting export e-invoices with discounts, helping ensure affected invoices can be processed successfully.
Original PR description
The Delivery node is only required for Export E-Invoices. Additionally, the position of the Delivery node should not follow the AllowanceCharge node. This inconsistency in node positioning causes a blocking issue on Nilvera’s side, preventing the successful processing of export E-Invoices with discounts. task-5155802 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes the spreadsheet engine and fixes several issues affecting pasted values, data validation across sheets, formula error messages, and chart display. Users should see more reliable spreadsheet behavior, clearer chart tooltips for dates, and better performance when recalculating dependencies.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0216b0643 [REL] 18.0.47 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0216b0643 [REL] 18.0.47 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/41a767864 [FIX] clipboard: paste as value with empty format string [Task: 5156459](https://www.odoo.com/odoo/2328/tasks/5156459) https://github.com/odoo/o-spreadsheet/commit/4bf3363b5 [FIX] data_validation: selecting range from another sheet [Task: 4948201](https://www.odoo.com/odoo/2328/tasks/4948201) https://github.com/odoo/o-spreadsheet/commit/af36b2666 [PERF] evaluation: stop the dependencies search early [Task: 4954710](https://www.odoo.com/odoo/2328/tasks/4954710) https://github.com/odoo/o-spreadsheet/commit/b796c32c0 [FIX] functions: fix LINEST error massage [Task: 5059375](https://www.odoo.com/odoo/2328/tasks/5059375) https://github.com/odoo/o-spreadsheet/commit/ff8bba956 [FIX] chart: clip show value text to chart area [Task: 5125970](https://www.odoo.com/odoo/2328/tasks/5125970) https://github.com/odoo/o-spreadsheet/commit/a828d6c76 [FIX] chart: tooltip has wrong format for date chart [Task: 5126261](https://www.odoo.com/odoo/2328/tasks/5126261) 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: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@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>
Payslips now correctly show worked days for employees on fully flexible contracts, even when no fixed working calendar is assigned. This prevents payroll teams from seeing blank worked-day sections when valid attendance or planning entries exist, supporting more accurate payroll preparation.
Original PR description
**Issue:** Payslips show blank worked days for employees with contracts without a `resource_calendar_id` (fully flexible, despite having valid work entries **Cause:** `_get_worked_day_lines()` skips worked day computation if the contract has no calendar https://github.com/odoo/enterprise/blob/1a10e0444fdb71a072262a1f14f0bfc766d109c6/hr_payroll/models/hr_payslip.py#L665-L674 **Steps to Reproduce:** - Assign an employee a fully flexible contract with attendance as work entry source. - Create work entries based on the attendance records of the employee record - Go to employees > contracts > new Payslip Worked Days section is empty, even though attendance shifts are showing up on top. **Fix:** removing the calendar requirement in the main method and adding a fallback calendar in the called utility method **Note:** same issue happens if work entry source of the contract is Planning opw-4931972
This corrects a small typo in an internal test for view filtering rules. It helps keep automated checks reliable and prevents avoidable test failures, with no expected impact on day-to-day users.
Original PR description
A typo was introduced in #163714
Project sharing pages now show tags using the same light styling as the rest of the interface. This fixes a visual inconsistency that could make shared project views look out of place or harder to read.
Original PR description
Before this commit, the project sharing was using the dark style for tags even though the rest of the views are in light mode. Removing the tags_list.dark.scss file from the imported file in the manifest fixes this issue. task-5130176
This change ensures accounting localization tests always install the needed demo data before running. It helps keep automated checks consistent across versions and reduces the risk of false test failures, with no direct impact on everyday users.
Original PR description
In later versions, we improve the testing suite to avoid having to install demo data in order to reduce the testing time. In order to keep the testing configuration simple across versions, we force the installation of demo data instead of only asserting that demo is installed before launching the script. Forward-Port-Of: odoo/odoo#231736 Forward-Port-Of: odoo/odoo#231660
Uploaded images can now be processed before they are saved, allowing them to be resized first. This helps reduce database storage growth and can improve upload efficiency for image-heavy use cases such as Studio customizations.
Original PR description
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#226611
Odoo Studio now automatically resizes app icons to a maximum of 64 by 64 pixels before saving them. This prevents unnecessarily large icon files from increasing database size, cache usage, and request payloads, helping keep the system lighter and more efficient.
Original PR description
Before this commit, the IconCreator images were sent as is in their full size. Downstream it was problematic because apps' icons were bigger than necessary, bloating the different caches, the database, and the request. After this commit, icon are resized to a max of 64x64 pixels. Forward-Port-Of: odoo/enterprise#94480
The Saudi Arabia e-invoicing module now labels the second street/address line as “District” instead of “Street 2.” This helps users enter the correct district or borough information for invoices, reducing confusion and supporting compliance with Saudi e-invoicing requirements.
Original PR description
## Before this commit The `street2` field on `res.company` and `res.partner` was mapped to `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CitySubdivisionName`, but its placeholder displayed `Street 2…`. This caused confusion among users, as they assumed it referred to `cbc:AdditionalStreetName`, leading to incorrect data entry and potential non-compliance. ## After this commit The placeholder of the `street2` field has been changed from `Street 2…` to `District…`, clarifying that this field represents the city subdivision (district or borough) of the Seller/Customer, in line with the Saudi Arabia e-invoicing specification. > Task-4951545 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231160
Users can now post image comments on Twitter from the Social app without upload errors. Comment text is also preserved when adding files or emojis, preventing accidental loss of drafted content.
Original PR description
Issue 1 ======= Steps to reproduce ----------------------- 1. Go to the Social app. 2. Create or Select any twitter post. 3. Add a comment to that post with an image. 4. Press Enter. ---> An error…
Issue 1
=======
Steps to reproduce
-----------------------
1. Go to the Social app.
2. Create or Select any twitter post.
3. Add a comment to that post with an image.
4. Press Enter.
---> An error notification will be shown.
When adding an image in a post comment to Twitter, the image was not uploaded properly because the MIME type was not set, and it defaulted to `application/octet-stream`.
This caused the following error:
```
{"errors": [{"parameters": {"$.media_type": ["'application/octet-stream'"]},
"message": "$.media_type: does not have a value in the enumeration
[video/mp4, video/webm, video/mp2t, video/quicktime, text/srt, text/vtt,
model/gltf-binary, model/vnd.usdz+zip, image/jpeg, image/gif, image/bmp,
image/png, image/webp, image/pjpeg, image/tiff]"}], "title": "Invalid Request",
"detail": "One or more parameters to your request was invalid.",
"type": "https://api.twitter.com/2/problems/invalid-request"}
```
From the above error, it's clear that Twitter only accepts specific MIME types.
This fix ensures the image has the correct MIME type so it can be uploaded without issues.
-------------------------------------------------------------------------------------------------------------------------------
Issue 2
=======
Steps to Reproduce
------------------------------
1. Select any post from social feed.
2. Add text comment or edit existing comment.
3. Upload file or add emoji.
=> The comment text is cleared/reset to its initial value.
Technical
------------------------------
With commit [1] we added `t-att-value` which sets the value of the textarea
on every re-render of the component.
After this commit
------------------------------
The initial value is only set once when component is mounted.
Removed `remove image` button for attachment while posting comments.
[1] https://github.com/odoo/enterprise/commit/ced5e88f433b7b9a8e1429259cd8bb6594b34852
Task-4845385
Forward-Port-Of: odoo/enterprise#91995This fixes an internal calculation problem in accounting reports caused by using the wrong record context. It helps ensure report values are computed reliably, reducing the chance of incorrect or failed report displays.
Original PR description
Forward-Port-Of: odoo/enterprise#97144
This fix ensures French VAT report submissions to ASPOne use the correct character limits for company name and address fields. It helps prevent rejected or invalid filings caused by values that are too long for the required format.
Original PR description
The aim of this commit is making sure that the field Designation, DesignationSuite1, DesignationSuite2, AdresseVoie and AdresseComplement are correctly filled. Indeed, the XSD implied that these fields have to be respectively 35, 35, 35, 30 and 35 characters max. [Documentation 2025](https://www.aspone.fr/files/tutoriaux/xmledi/Documentation_XML-EDI.zip) no task id Forward-Port-Of: odoo/enterprise#97199
Documentation and clarification updates
The corporate contributor agreement record for ForgeFlow was updated. This keeps Odoo's legal contribution documentation current and supports proper tracking of contribution rights.
Miscellaneous changes
opw-5018450 Forward-Port-Of: odoo/odoo#231394
Original PR description
opw-5018450 Forward-Port-Of: odoo/odoo#231394
2 changes
Enhancements to existing features
French Point of Sale sessions are no longer limited to a single calendar day. This gives businesses more flexibility to keep a session open across several days when their operations require it, without being blocked by the previous daily restriction.
Original PR description
Before this commit: -------- - Point of Sale sessions were restricted to a single calendar day, preventing accumulation of data across multiple days in one session. After this commit: -------- - Removed the restriction that blocked sessions from overlapping several days. Task: 4735752
Resolved issues and error corrections
The payroll payslip screen no longer exposes an export option that led users to a missing page. This prevents confusion and avoids a dead-end error when managing payslips.
Original PR description
Steps to reproduce: ------------------------- 1. Install `hr_payroll` module 2. Enable debug mode and click on Become Superuser 3. Go to All Payslips and open any payslip record 4. Click on the…
Steps to reproduce: ------------------------- 1. Install `hr_payroll` module 2. Enable debug mode and click on Become Superuser 3. Go to All Payslips and open any payslip record 4. Click on the Export Payslip button Observation: ------------------------- A 404 (Page Not Found) error appears when clicking the Export Payslip button Issue: ------------------------- The button triggers the route `/debug/payslip/<id>`, which was removed in the following commit https://github.com/odoo/enterprise/commit/57969bcaf876a13c36794adeb47e0da938e297ad#diff-0105b1a6a9e742e7eeaf7cc727745ebd3932177378d46332d4ca854f931b3359 The route was never reintroduced afterward, but the Export Payslip button remained in the view. As a result, clicking it leads to a 404 error Solution: ------------------------- 1. Temporarily bypass the `action_export_payslip` function. 2. Remove the Export Payslip button from the XML in the master forward port branch, as doing so does not impact any existing customizations relying on that button opw-5115946