Daily updates from Odoo
Navigate
Branch
Monday, January 27, 2025
83 changes
1 change
Miscellaneous changes
**Problem:** When editing the "Sign & Pay" modal in customer preview for a sale order, changes are not saved due to multiple issues: 1. Saving the signature component directly results in only the signature UI being saved, missing the logic and props of the original component. 2. If the signature component is saved with other fields, it gets duplicated upon saving due to `<owl-component />` behavior. This re-renders every saved component and mounts those passed as props, c
Original PR description
**Problem:** When editing the "Sign & Pay" modal in customer preview for a sale order, changes are not saved due to multiple issues: 1. Saving the signature component directly results in only the…
**Problem:** When editing the "Sign & Pay" modal in customer preview for a sale order, changes are not saved due to multiple issues: 1. Saving the signature component directly results in only the signature UI being saved, missing the logic and props of the original component. 2. If the signature component is saved with other fields, it gets duplicated upon saving due to `<owl-component />` behavior. This re-renders every saved component and mounts those passed as props, causing duplication and breaking functionality. - Reference: public_component_service.js **Solution:** 1. Hide the signature component during editing to prevent saving its UI-only state, preserving its logic and props. **Steps to Reproduce:** 1. Create a sale order. 2. Click on "Customer Preview." 3. Enable edit mode. 4. Open the "Sign & Pay" modal, modify the content, and save. - The signature UI duplicates **opw-4216372** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187707
17 changes
Resolved issues and error corrections
Updates the spreadsheet component to a newer maintenance version with fixes for formulas, selections, popovers, cell references, and grid display. This should make spreadsheet editing more reliable and reduce visual or interaction errors for users working with Odoo spreadsheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6ea43fb2e [REL] 17.2.33 Task: 0 https://github.com/odoo/o-spreadsheet/commit/3672862dd [FIX] formulas: binary search…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6ea43fb2e [REL] 17.2.33 Task: 0 https://github.com/odoo/o-spreadsheet/commit/3672862dd [FIX] formulas: binary search returning incorrect index for multiple exact matches Task: 4328300 https://github.com/odoo/o-spreadsheet/commit/c051e6373 [FIX] selection: drag and drop resized cols and rows Task: 4454025 https://github.com/odoo/o-spreadsheet/commit/6c26c50b0 [FIX] popover: wrong position on updated popover Task: 3814260 https://github.com/odoo/o-spreadsheet/commit/945563e8a [FIX] Selection: selection follows the moved header Task: 4461901 https://github.com/odoo/o-spreadsheet/commit/03d164a45 [FIX] TextValueProvider: Avoid duplicate key in template Task: 4483494 https://github.com/odoo/o-spreadsheet/commit/2754a7c2c [FIX] GridComposer: Fix CellReference pill display Task: 4501136 https://github.com/odoo/o-spreadsheet/commit/c5970f775 [FIX] renderer: Fix grid rendering Task: 4448426 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: Mehdi Rachico (mera) <mera@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>
Miscellaneous changes
Steps: - Install sale app. - Enable Loyalty settings. - Try to create a card on a loyalty. Issue: - Giving validation error. Casue: - In [PR] forgot to check expiration_date set or not before raise an error. Fix: - Added condition to check if expiration_date set or not on card before raising an error. [PR]: https://github.com/odoo/odoo/pull/171453 opw-4492179 opw-4490587 opw-4504188 opw-4495530 Forward-Port-Of: odoo/odoo#194836 Forward-Port-Of: odoo/odoo#194785
Original PR description
Steps: - Install sale app. - Enable Loyalty settings. - Try to create a card on a loyalty. Issue: - Giving validation error. Casue: - In [PR] forgot to check expiration_date set or not before raise an error. Fix: - Added condition to check if expiration_date set or not on card before raising an error. [PR]: https://github.com/odoo/odoo/pull/171453 opw-4492179 opw-4490587 opw-4504188 opw-4495530 Forward-Port-Of: odoo/odoo#194836 Forward-Port-Of: odoo/odoo#194785
**Problem**: When we have `<b t-field="html">`, it is rendered in the DOM as `<b data-oe-attr="..."><p>content</p></b>`. When this is converted to a string and parsed in the backend, the `html.fromstring` method removes the `p` from the `b` because `b` is an inline element and cannot contain block elements. This results in: `<b data-oe-attr="..."></b><p>content</p>`. Since this structure has two root elements, the parser wraps them in a block element (`div`), generating: `<div><b data
Original PR description
**Problem**: When we have `<b t-field="html">`, it is rendered in the DOM as `<b data-oe-attr="..."><p>content</p></b>`. When this is converted to a string and parsed in the backend, the `html.fromstring` method removes the `p` from the `b` because `b` is an inline element and cannot contain block elements. This results in: `<b data-oe-attr="..."></b><p>content</p>`. Since this structure has two root elements, the parser wraps them in a block element (`div`), generating: `<div><b data-oe-attr="..."></b><p>content</p></div>`. This causes a traceback when trying to access `data-oe` attributes, as they are expected to be in the root element. **Solution**: Convert any `b` elements used as HTML fields to `div` elements before saving. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194872
This commit will update some taxes: - Update the purchase tax accounts - Add new 0% EX tax - Delete EX RS 20% & EX RS -20% In the tax report: - Change the name of the report - Add a new record task: 4244715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185947
Original PR description
This commit will update some taxes: - Update the purchase tax accounts - Add new 0% EX tax - Delete EX RS 20% & EX RS -20% In the tax report: - Change the name of the report - Add a new record task: 4244715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185947
Description of the issue/feature this PR addresses: The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python 3.12, as the requirements.txt specifies werkzeug 3.0.1. This results in a misleading error stating that auth_signup is not installed on the database when authenticating a new user with an OAuth provider. Current behavior before PR: When attempting to authenticate a new user with an OAuth provider i
Original PR description
Description of the issue/feature this PR addresses: The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python…
Description of the issue/feature this PR addresses: The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python 3.12, as the requirements.txt specifies werkzeug 3.0.1. This results in a misleading error stating that auth_signup is not installed on the database when authenticating a new user with an OAuth provider. Current behavior before PR: When attempting to authenticate a new user with an OAuth provider in Odoo using Python 3.12, the method werkzeug.http.parse_www_authenticate_header is called. Since this method is removed in Werkzeug 3.0.1, a misleading error message about auth_signup not being installed on the database is displayed. Desired behavior after PR is merged: The code will use WWWAuthenticate.from_header for parsing the WWW-Authenticate header if available, otherwise, it will fall back to using werkzeug.http.parse_www_authenticate_header for compatibility with older versions of Werkzeug (2.0 and 2.2). The misleading error message will no longer appear, and OAuth authentication will work as expected. Fixes #194002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194484
The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/odoo#157028
Original PR description
The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/odoo#157028
Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback occurs) starting from Odoo version 18.0 and in browsers older than Chrome 112 or Firefox 121. This bug happens because the same selector, used by jQuery, combines both the ":has" pseudo-class and the ":is" pseudo-class (this ":is" pseudo-class was introduced into the same selector by commit [2] st
Original PR description
Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback…
Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback occurs) starting from Odoo version 18.0 and in browsers older than Chrome 112 or Firefox 121. This bug happens because the same selector, used by jQuery, combines both the ":has" pseudo-class and the ":is" pseudo-class (this ":is" pseudo-class was introduced into the same selector by commit [2] starting from Odoo version 18.0). This is not compatible with the older browsers mentioned above. The bug only appears in version 18. However, we already fixed this in 16.0 in case potential customizations had added the ":is" pseudo-class to the same selector. [1]: https://github.com/odoo/odoo/commit/65a85009800dfa45526ebdc41d3a0a808b2e9f6d [2]: https://github.com/odoo/odoo/commit/e0fc83760f991fa2fea39763bb2709d9e0182316 opw-4494945 Forward-Port-Of: odoo/odoo#194908 Forward-Port-Of: odoo/odoo#194676
The `amount_untaxed` field, which is tracked, encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned, the field may become 261,`462.0200000002` due to floating-point imprecision. Although the value is stored correctly in the database (as `261,462.02`), the tracked change is logged in the chatter, causing unnecessary noise. I couldn’t identify a clear or universal solution to this issue due to the inherent nature of floating-point arithmet
Original PR description
The `amount_untaxed` field, which is tracked, encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned, the field may become 261,`462.0200000002`…
The `amount_untaxed` field, which is tracked, encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned, the field may become 261,`462.0200000002` due to floating-point imprecision. Although the value is stored correctly in the database (as `261,462.02`), the tracked change is logged in the chatter, causing unnecessary noise. I couldn’t identify a clear or universal solution to this issue due to the inherent nature of floating-point arithmetic and its limitations. So what I did is checking if the new value is different than the old one then update the field. Steps to reproduce: 1. Create a PO 2. Add a product with price 261,462.02 3. Save 4. Change the expected arrival date 5. Save See the chatter. take a loot at the chatter.  opw-4315116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193368
Scenario: - have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it) - merge these partners => UniqueViolation error because of unicity of (fields_id, company_id, res_id) constraint of ir_property table Why: The query merging property doesn't take NULL into account for company_id when checking if the destination partner already has this property. Also a savepoint was used, without ignoring the error so the import could
Original PR description
Scenario: - have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it) - merge these partners => UniqueViolation error because of…
Scenario: - have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it) - merge these partners => UniqueViolation error because of unicity of (fields_id, company_id, res_id) constraint of ir_property table Why: The query merging property doesn't take NULL into account for company_id when checking if the destination partner already has this property. Also a savepoint was used, without ignoring the error so the import could not be done if an error happened. Fix: Take the case where both records have NULL company_id into account. Also ignore error and log a warning when a legitimate error happens because of duplicate ir.property in source records. Note: This issue should only happen when: - modifying ir.property directly - after a migration with a res.partner field becoming company_dependent field, the partners without company would get an ir.property without company_id Without the fix, the added test would fail because of an error at each _merge call. opw-4300572 opw-4030442 Forward-Port-Of: odoo/odoo#188673
If you pay an invoice with multiple payments some roundings are made for the taxes. On the last payment, the error from those roundings are put on a move to make sure that the exact amount of the invoice is paid. That move was put on the wrong journal. It was put in the 'Exchange Difference' journal instead of the 'Cash Basis Taxes'. opw-4460696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193994
Original PR description
If you pay an invoice with multiple payments some roundings are made for the taxes. On the last payment, the error from those roundings are put on a move to make sure that the exact amount of the invoice is paid. That move was put on the wrong journal. It was put in the 'Exchange Difference' journal instead of the 'Cash Basis Taxes'. opw-4460696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193994
This PR addresses an issue where selecting a video and pressing Ctrl+K would introduce a link(anchor tag) on top of the video. The fix ensures that pressing Ctrl+K while a video is focused will no longer insert a link, resolving the issue of an empty link being added. task-2819776 Forward-Port-Of: odoo/odoo#193447 Forward-Port-Of: odoo/odoo#162615
Original PR description
This PR addresses an issue where selecting a video and pressing Ctrl+K would introduce a link(anchor tag) on top of the video. The fix ensures that pressing Ctrl+K while a video is focused will no longer insert a link, resolving the issue of an empty link being added. task-2819776 Forward-Port-Of: odoo/odoo#193447 Forward-Port-Of: odoo/odoo#162615
Before this commit, loadViews didn't benefit from the "async" protection of services. Indeed, when used in a component (via useService), the promise returned by loadViews could be resolved (when the rpc returned), even if the component had been destroyed meanwhile. This could lead to code in a destroyed component being executed, and eventually doing an rpc, which would lead to the crash `Error: Component is destroyed`. This could be reproduced in a form view with an x2many field, whose form v
Original PR description
Before this commit, loadViews didn't benefit from the "async" protection of services. Indeed, when used in a component (via useService), the promise returned by loadViews could be resolved (when the rpc returned), even if the component had been destroyed meanwhile. This could lead to code in a destroyed component being executed, and eventually doing an rpc, which would lead to the crash `Error: Component is destroyed`. This could be reproduced in a form view with an x2many field, whose form view isn't inline (i.e. needs to be fetched when a record is clicked). In such a form view, click on a record in the x2many, then, during the call to get_views, toggle the home menu (for instance). 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#195143
steps: - create an attendance for one day with less worked hours than the daily hours - create another attendance for the next day with hours to compensate the previous day's missing time - got to the attendance report : you have worked overtime although that overtime was only compensating for the previous day This worked in 16.0, but got broken by the attendance refactor and the introduction of the overtime_hours field in hr.attendance. This commit fixes the computation of the field to in
Original PR description
steps: - create an attendance for one day with less worked hours than the daily hours - create another attendance for the next day with hours to compensate the previous day's missing time - got to the attendance report : you have worked overtime although that overtime was only compensating for the previous day This worked in 16.0, but got broken by the attendance refactor and the introduction of the overtime_hours field in hr.attendance. This commit fixes the computation of the field to include negative overtimes. opw-4337755 Forward-Port-Of: odoo/odoo#192699
### Description of the issue/feature this PR addresses: - The [_get_plan_available_base_domain()](https://github.com/odoo/odoo/blob/18.0/addons/mail/wizard/mail_activity_schedule.py#L330) method is built and `self.ensure_one()` is placed in it but it is called in `_compute_plan_available_ids()` with `self` which can have multiple records ### Current behavior before PR: - The error `ValueError: Expected singleton: mail.activity.schedule(1, 2)` occurred ### Desired behavior after PR is m
Original PR description
### Description of the issue/feature this PR addresses: - The [_get_plan_available_base_domain()](https://github.com/odoo/odoo/blob/18.0/addons/mail/wizard/mail_activity_schedule.py#L330) method is built and `self.ensure_one()` is placed in it but it is called in `_compute_plan_available_ids()` with `self` which can have multiple records ### Current behavior before PR: - The error `ValueError: Expected singleton: mail.activity.schedule(1, 2)` occurred ### Desired behavior after PR is merged: - The problem has been fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194338
There is already a placeholder image displayed when an image fails to load. opw-4419565 Forward-Port-Of: odoo/odoo#194011 Forward-Port-Of: odoo/odoo#193825
Original PR description
There is already a placeholder image displayed when an image fails to load. opw-4419565 Forward-Port-Of: odoo/odoo#194011 Forward-Port-Of: odoo/odoo#193825
Issue: If we have a X2many that allows to have inactive records (with `context={'active_test': False}` on the field definition) and we specify a specific order for this X2many in this view, web_read won't respect the context of the field and will filter out inactive records. This is because to apply a specific order in the web_read, we use search(), which will filter out inactive records from the `corecords` recordset. Fix: We fix this by forcing active_test=False before calling search a
Original PR description
Issue:
If we have a X2many that allows to have inactive records (with `context={'active_test': False}` on the field definition) and we specify a specific order for this X2many in this view, web_read won't respect the context of the field and will filter out inactive records.
This is because to apply a specific order in the web_read, we use search(), which will filter out inactive records from the `corecords` recordset.
Fix:
We fix this by forcing active_test=False before calling search and reapplying the previous context immediately after.
Closes #194311
Forward-Port-Of: odoo/odoo#194379**Problem:** When editing the "Sign & Pay" modal in customer preview for a sale order, changes are not saved due to multiple issues: 1. Saving the signature component directly results in only the signature UI being saved, missing the logic and props of the original component. 2. If the signature component is saved with other fields, it gets duplicated upon saving due to `<owl-component />` behavior. This re-renders every saved component and mounts those passed as props, c
Original PR description
**Problem:** When editing the "Sign & Pay" modal in customer preview for a sale order, changes are not saved due to multiple issues: 1. Saving the signature component directly results in only the…
**Problem:** When editing the "Sign & Pay" modal in customer preview for a sale order, changes are not saved due to multiple issues: 1. Saving the signature component directly results in only the signature UI being saved, missing the logic and props of the original component. 2. If the signature component is saved with other fields, it gets duplicated upon saving due to `<owl-component />` behavior. This re-renders every saved component and mounts those passed as props, causing duplication and breaking functionality. - Reference: public_component_service.js **Solution:** 1. Hide the signature component during editing to prevent saving its UI-only state, preserving its logic and props. **Steps to Reproduce:** 1. Create a sale order. 2. Click on "Customer Preview." 3. Enable edit mode. 4. Open the "Sign & Pay" modal, modify the content, and save. - The signature UI duplicates **opw-4216372** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187707
13 changes
Enhancements to existing features
The Spanish localization reports have been updated to support the 2024 Mod 390 annual VAT declaration requirements. This helps businesses in Spain prepare compliant tax filings using the latest official reporting format.
Original PR description
TODO
This work updates recruitment-related screens and referral campaign setup, including job views connected to Monster integration and employee referrals. It should make recruitment workflows clearer or more consistent for teams managing job postings and referral campaigns.
This update refreshes parts of the recruitment and employee referral experience, especially the referral campaign wizard and job position forms. It should make configuring job postings and referral campaigns clearer and easier for HR teams.
Recruitment-related settings and reporting screens have been updated to provide a cleaner, more consistent interface. This should make it easier for users to configure recruitment features and review hiring reports.
Original PR description
- made the changes for the hr.recruitment views and functionality Task: 4463696
Resolved issues and error corrections
A minor issue in the Knowledge app's automated article command tour was corrected so the test can run successfully again. This helps maintain product quality by ensuring future changes to Knowledge article commands are checked reliably.
Original PR description
Following [this commit], in master, there was another change preventing the disabled test to run without error. This commit fixes the issue in order to be able to re-enable the test. [this commit]: https://github.com/odoo/enterprise/commit/02bf70e1ad8c7d88ce20f74ab4df5a00d59d52e9 runbot-task-111948
WhatsApp now uses the shared phone validation logic when looking up partners by phone number. This reduces duplicate handling and helps match contacts more consistently across the system.
Code cleanup and technical improvements
This draft change removes reliance on the current company identifier in evaluation context handling. This is an internal cleanup intended to make company-related behavior more consistent and reduce future maintenance risk.
Miscellaneous changes
The current auto-clean feature doesn't work properly and it deletes spreadsheet that shouldn't be deleted. 1) copy a spreadsheet and leave it (no update) 2) upload an XLSX file Given that it's been broken several times and the usefulness of the feature is debatable, let's just drop the feature. No feature, no bug 🙃 If users create empty spreadsheet, so be it. They'll clean their mess themselves. Task: 4506185 Forward-Port-Of: odoo/enterprise#77817 Forward-Port-Of: odoo/enterprise#
Original PR description
The current auto-clean feature doesn't work properly and it deletes spreadsheet that shouldn't be deleted. 1) copy a spreadsheet and leave it (no update) 2) upload an XLSX file Given that it's been broken several times and the usefulness of the feature is debatable, let's just drop the feature. No feature, no bug 🙃 If users create empty spreadsheet, so be it. They'll clean their mess themselves. Task: 4506185 Forward-Port-Of: odoo/enterprise#77817 Forward-Port-Of: odoo/enterprise#77573
Add missing index on move_line_id to speedup checking the check_ids of a stock_move_line. See community PR for more info https://github.com/odoo/odoo/pull/190479 Forward-Port-Of: odoo/enterprise#75537
Original PR description
Add missing index on move_line_id to speedup checking the check_ids of a stock_move_line. See community PR for more info https://github.com/odoo/odoo/pull/190479 Forward-Port-Of: odoo/enterprise#75537
### Steps to reproduce: - Select an EU company and provide a SEPA creditor identifier (for example BE55ZZZ0455530509) - Have a contact with a European IBAN - Have a company bank journal with a European IBAN - Create a valid Direct Debit Mandate for your contact - Create an invoice for that contact and register a payment using SEPA - Now delete that Sepa payment from Accounting > Customers > Payments - Open the customer's Direct Debit Mandate > It shows one invoice was paid using that mand
Original PR description
### Steps to reproduce: - Select an EU company and provide a SEPA creditor identifier (for example BE55ZZZ0455530509) - Have a contact with a European IBAN - Have a company bank journal with a…
### Steps to reproduce: - Select an EU company and provide a SEPA creditor identifier (for example BE55ZZZ0455530509) - Have a contact with a European IBAN - Have a company bank journal with a European IBAN - Create a valid Direct Debit Mandate for your contact - Create an invoice for that contact and register a payment using SEPA - Now delete that Sepa payment from Accounting > Customers > Payments - Open the customer's Direct Debit Mandate > It shows one invoice was paid using that mandate although the payment was deleted - Expected: link between invoice and mandate should not be kept if payment was deleted ### Cause: The field `sdd_mandate_id` of the invoice is not reset when the payment is reset to draft. ### Solution: Add an `api.ondelete` method on `account.partial.reconcile` which checks if any of the unreconciled moves is an invoice with `sdd_mandate_id`. In that case, and if the unreconciled payment is the only SEPA payment, set `sdd_mandate_id` to False. opw-4277982 Forward-Port-Of: odoo/enterprise#77589 Forward-Port-Of: odoo/enterprise#75273
### Steps to reproduce: - Go in Accounting > Customers > Direct Debit Mandates - Create a new mandate with a start date in the future - In Scheduled Actions search for "Mandate state updater" - Run manually this action - Return to Accounting > Customers > Direct Debit Mandates - The mandate was closed ### Cause: The code checks if `mandate.start_date <= today <= expiry_date`, if not the mandate is closed. ### Solution: Only check if `today <= expiry_date` opw-4460087 Forward-Po
Original PR description
### Steps to reproduce: - Go in Accounting > Customers > Direct Debit Mandates - Create a new mandate with a start date in the future - In Scheduled Actions search for "Mandate state updater" - Run manually this action - Return to Accounting > Customers > Direct Debit Mandates - The mandate was closed ### Cause: The code checks if `mandate.start_date <= today <= expiry_date`, if not the mandate is closed. ### Solution: Only check if `today <= expiry_date` opw-4460087 Forward-Port-Of: odoo/enterprise#77048
Since whatsapp templates are posted on a specific model, the current parent computation becomes incorrect when it comes to templates, because of incorrect domain, in particular `model` and `res_is` parts of it. task-4210393 Forward-Port-Of: odoo/enterprise#70718
Original PR description
Since whatsapp templates are posted on a specific model, the current parent computation becomes incorrect when it comes to templates, because of incorrect domain, in particular `model` and `res_is` parts of it. task-4210393 Forward-Port-Of: odoo/enterprise#70718
The aim of this commit is passing correctly the debug mode in the URL params to the bank sync iframe. It allows to debug the iframe during the development. no task id Forward-Port-Of: odoo/enterprise#77501
Original PR description
The aim of this commit is passing correctly the debug mode in the URL params to the bank sync iframe. It allows to debug the iframe during the development. no task id Forward-Port-Of: odoo/enterprise#77501
52 changes
New functionality added to Odoo
Products can now store an Amazon ASIN directly in Odoo. This prepares the system for future Amazon Bulk and DF app work by keeping Amazon product identifiers available on product records.
Original PR description
By default, Odoo does not have an Amazon ASIN field on either of the product models. That is something that needs to be custom-added. I will need this for future work on the Bulk and DF apps, so I've created this module with the sole purpose of adding those fields.
This pull request adds packaged theme files for an Odoo 18 demo environment. It appears to support visual or user-interface customization, but the provided description does not include specific business behavior changes.
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
This pull request adds a new Foresta HN SAR submodule to the repository. It appears to introduce a separate component or integration area, but the provided description does not specify the business process or user-facing benefit.
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
Enhancements to existing features
Point of Sale now reduces background server requests by handling preparation updates directly on the server. Device synchronization is more robust by checking local records during each request, helping avoid issues when orders or related data were changed or removed elsewhere.
Original PR description
*: pos_restaurant, pos_event Reduce number of XHR request by handling preparation change notification directly in the backend. The synchronisation is now more robust, each time we receive a request all local ids are checked to ensure that the record wasn't deleted or modified in the meantime.
This update adds database optimizations that help WhatsApp message cleanup and related marketing tracking run more efficiently. It reduces the chance of slowdowns when processing large volumes of marketing automation and WhatsApp data, without changing user-facing features.
Original PR description
Missing indexes: - `whatsapp.message.parent_id` is hit during Fkey lookup during unlinking to set the value to null during `whatsapp.message`'s GC. - `marketing.trace.whatsapp_message_id` is the inverse of the One2many `marketing_trace_ids`, index will be hit when the ORM reads the O2m field. `marketing_trace` is usually a large table, a `Seq.Scan` should be avoided. Would also be hit during whatsapp's GC
Users can now manage document versions from a dedicated dialog, including downloading, deleting, and uploading versions. The Documents list view also gains clearer action ordering plus Export and Insert in Spreadsheet options, improving consistency and day-to-day document workflows.
Original PR description
Purpose ======= Allow managing documents version like it was done in 17.4. We created a new action for it, that will open a dialog in which we can download and delete versions, but also upload new ones. Reorder the actions we can do when selecting documents. Add "Export" and "Insert In Spreadsheet" actions, for consistency with other views, those actions are available only in the list view. Task-4480340
Point of Sale device synchronization has been improved to reduce unnecessary background requests and handle preparation updates directly on the server. This should make order preparation displays and related localizations more reliable when records are changed or removed during use.
Original PR description
*: l10n_cl_edi_pos, l10n_de_pos_res_cert, pos_preparation_display, l10n_it_pos, pos_restaurant_preparation_display, pos_settle_due Reduce number of XHR request by handling preparation change notification directly in the backend. The synchronisation is now more robust, each time we receive a request all local ids are checked to ensure that the record wasn't deleted or modified in the meantime.
Documents uploaded from company-level areas are now accessible to the right users instead of being limited to administrators. The Documents interface also improves upload routing, search panel behavior, and folder visibility so users can find and manage files more easily.
Original PR description
NB: both commits must be updated in FW port for change in company root owner. [FIX] documents: ensure access after upload in Company Otherwise, documents are only accessible by superusers as the document is not shared with anyone and owned by OdooBot. [IMP] documents: improve backend UI Based on users feedback, * partial revert of 78b21e99 regarding the search panel. * Redirect uploads in Recent and All to My Drive. * Increase visibility of record parent folder. Note that this will only occur after the views are updated. Task-4485969
Resolved issues and error corrections
This fix prevents the website editor from crashing for customers whose custom setup loads only the base jQuery file. Odoo now detects the missing legacy jQuery support and loads it automatically, keeping the editor usable without requiring customer-side asset changes.
Original PR description
__Current behavior before commit:__ jQuery has been removed from `web.assets_backend` in [`b8fc93e`][1], now it's dynamically added with the `ensureJQuery` method. A lot of customers put…
__Current behavior before commit:__ jQuery has been removed from `web.assets_backend` in [`b8fc93e`][1], now it's dynamically added with the `ensureJQuery` method. A lot of customers put `web/static/lib/jquery/jquery.js` in `web.assets_backend` (using custom modules) but not `web/static/src/legacy/js/libs/jquery.js`. Therefore `ensureJQuery` doesn't fetch `web._assets_jquery` and therefore `web/static/src/legacy/js/libs/jquery.js` is never included. __Description of the fix:__ If jQuery is present, check if the method `getScrollingElement` is defined in jQuery.fn. If not load `/web/static/src/legacy/js/libs/jquery.js`. __Steps to reproduce the issue in local:__ 1. Add back "web/static/lib/jquery/jquery.js" in the `web.assets_backend` entry of `addons/web/\_\_manifest\_\_.py` to simulate that a customer added it in a custom module. 2. Open the database and Refresh Assets in the debug menu 3. Try to open the editor Crash: "TypeError: $(...).getScrollingElement is not a function" opw-4499576 [1]: https://github.com/odoo/odoo/commit/b8fc93ea97b8
This fix stops an extra dialog from appearing in Point of Sale when the same register session is already being closed. It helps cashiers avoid confusion during the closing process and keeps the workflow smoother.
Original PR description
check commit message for description.
This fixes the status display for draft accounting entries so they once again appear with the expected blue badge. The change helps users quickly distinguish draft moves in accounting lists after a recent view update accidentally removed that visual cue.
Original PR description
In the account move view, since this commit: https://github.com/odoo/odoo/commit/9b47dd1158b2819c74431f30ff137cbb13ce0d4f We made a new column that is status_in_payment but with that we removed the decoration for draft moves task-4497735 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where tables added to chatter messages could lose visible cell borders after being logged or sent. This helps users share formatted information more clearly and reliably in discussions.
Original PR description
**Problem**: When adding a table in the chatter and logging/sending, the table is not displayed properly. This issue is same as: https://github.com/odoo/odoo/commit/99c5a73b2ffc9bef6128059c51574c70cdfc6767. Grouped styles like `border`, `padding`, and `border-radius` do not propagate their values to substyles when variables are used in the value. **Solution**: Apply same fix in `convert_inline` of `mail` **Steps to Reproduce**: 1. Open the full composer. 2. Add a table. 3. Log a note. 4. Observe that `td` borders are not visible. opw-4483477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users are now shown a clear warning when they try to use Print & Send on an invoice that has not yet been confirmed. This prevents a confusing system error caused by draft invoices not having a final invoice number for the PDF filename.
Original PR description
Currently, an error occurs when attempting to print and send an invoice that is in a draft state. Step to produce: - Install the `account` module. - Go to Invoicing / Customers / Invoices, Create one invoice without a customer and invoice line, and come to the list view of Invoices. - Select this invoice and click on 'Print & Send'. `AttributeError: 'bool' object has no attribute 'replace'` The issue occurs because the system attempts to replace the name at [1] to generate a PDF file name. But the invoice's name is not available. Link [1]: https://github.com/odoo/odoo/blob/41de88b930e569daea7624ee3655cef218f9136f/addons/account/models/account_move.py#L5739 To resolve this issue, Raise a user error if the user attempts to select the 'Print & Send' action on an invoice that is not in the confirmed state. Sentry-6185757435 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes Odoo's spreadsheet engine with several fixes that make formulas, selections, popovers, icons, and grid rendering behave more reliably. It also improves Excel compatibility by preserving data validation rules when importing and exporting spreadsheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e8c6bd14c [REL] 18.0.11 Task: 0 https://github.com/odoo/o-spreadsheet/commit/1ae4dd4d6 [FIX] TextValueProvider: Avoid…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e8c6bd14c [REL] 18.0.11 Task: 0 https://github.com/odoo/o-spreadsheet/commit/1ae4dd4d6 [FIX] TextValueProvider: Avoid duplicate key in template Task: 4483494 https://github.com/odoo/o-spreadsheet/commit/b7a2d6f33 [FIX] formulas: binary search returning incorrect index for multiple exact matches Task: 4328300 https://github.com/odoo/o-spreadsheet/commit/a23b0534c [FIX] selection: drag and drop resized cols and rows Task: 4454025 https://github.com/odoo/o-spreadsheet/commit/6dae73692 [FIX] popover: wrong position on updated popover Task: 3814260 https://github.com/odoo/o-spreadsheet/commit/96928270e [FIX] Selection: selection follows the moved header Task: 4461901 https://github.com/odoo/o-spreadsheet/commit/6405df3ce [FIX] icons: Missing dimension on icon Task: 4461359 https://github.com/odoo/o-spreadsheet/commit/a0401a35f [IMP] xlsx: support import/export of data validation rules Task: 4505529 https://github.com/odoo/o-spreadsheet/commit/f0537e96b [FIX] GridComposer: Fix CellReference pill display Task: 4501136 https://github.com/odoo/o-spreadsheet/commit/eccd9fa51 [FIX] renderer: Fix grid rendering Task: 4448426 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: Mehdi Rachico (mera) <mera@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>
This fixes an issue where users could not edit the description of a newly added service line on a confirmed sales order. The change keeps order line descriptions editable when appropriate, reducing friction when updating confirmed orders.
Original PR description
Steps: - Install sale_project - Create a service type product - Create a SO and confirm it - In the confirmed order add a SOL with the new product Issue: - cannot edit the description of the new SOL Cause: - readonly for the SOL is set based on product_updatable and product_updatable is set false when product type service even for new order line Fix - Updated the readonly condition to account for new lines opw - 4473488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a timing issue that could crash the app if a user opened a related record and navigated away before the view finished loading. The change makes the interface safely ignore late-loading results for screens that are no longer active, improving reliability during normal navigation.
Original PR description
Before this commit, loadViews didn't benefit from the "async" protection of services. Indeed, when used in a component (via useService), the promise returned by loadViews could be resolved (when the rpc returned), even if the component had been destroyed meanwhile. This could lead to code in a destroyed component being executed, and eventually doing an rpc, which would lead to the crash `Error: Component is destroyed`. This could be reproduced in a form view with an x2many field, whose form view isn't inline (i.e. needs to be fetched when a record is clicked). In such a form view, click on a record in the x2many, then, during the call to `get_views`, toggle the home menu (for instance). 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
Sales order combo items now allow users to update the delivered quantity, not just the description and taxes. This fixes an editing limitation so delivered amounts can be corrected directly when needed.
Original PR description
Previously, only the description and taxes could be edited on combo item SOLs. However, the delivered quantity should also be editable. opw-4454205
This fixes an issue where employees on flexible working schedules could see a one-day leave request counted as two days. Time off calculations now update once the schedule's daily hours are available, helping keep leave balances accurate.
Original PR description
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an…
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an allocation for the created time off type for the employee with the flexible working schedule - Create a leave for the mentioned employee with the created time off type for 1 day - Notice the duration of the leave is 2 days not 1 ### Cause: When creating a working schedule we compute the duration of the periods and since 'attendance.calendar_id.hours_per_day' won't have a value each period will be 1 day. https://github.com/odoo/odoo/blob/18.0/addons/resource/models/resource_calendar_attendance.py#L82 So, when getting the duration of the leave where its request_unit is not 'day' the duration will be the summation of the periods' duration of the working schedule for the employee which in this case will be 1 for each period -each day has 2 periods with the value of 1- ### Fix: Since 'calendar_id.hours_per_day' will be equal zero at first we should re-compute the duration of periods when this field gets a value. opw-4309551
Manufacturing orders created or partially produced in the Barcode app no longer crash when Lots & Serial Numbers is disabled. This prevents an interruption for warehouse users working without lot tracking enabled.
Original PR description
Before this commit, creating or partially producing an MO within the Barcode app gives a traceback if the "Lots & Serial Numbers" option is not set.
Steps to reproduce
-----
1. Inventory > Configuration > Settings > uncheck Lots & Serial Numbers
2. Barcode > Operations > Manufacturing > New > Add any product and Confirm
3. Traceback occurs
```
TypeError: Cannot read properties of undefined (reading '0')
at MainComponent.saveFormView
```
Cause
-----
Normally if `lot_producing_id` on the MO is False, then `lineRecord.data.lot_producing_id` is also false. But with the Lots & Serial Numbers option unset, `lineRecord.data.lot_producing_id` becomes undefined instead.
Solution
-----
Add an optional chain to handle the possible nullish value.
opw-4460956The Sign app now sends users back to the project they came from after completing a signature request. This avoids opening an unnecessary new wizard and makes the workflow smoother for project users.
Original PR description
version: - 18.0 Steps to reproduce: - Install the Project and Sign modules. - Open a project. - Click on the "Signature Request" action. - Select a document and click "Sign Now." - Complete the signing process. - Click the "Back to Project" button. Issue: - Clicking "Back to Project" opens a new wizard instead of returning to the project view. Cause: - The project view is set to always open in a new target. Solution: - Update the target to "current" to ensure the button redirects correctly to the project view. task:4431882
Users could hit an access error when sending a document for signature if another user had already uploaded the same file in Documents with view-only access. The fix links sign requests to the exact uploaded attachment instead of another document with the same file content, so signing works reliably for internal users.
Original PR description
### Issue: - when a user uploads a document to the Documents app, and grants only view access to that document to other internal users (default behavior). - if another user uploads the same document…
### Issue: - when a user uploads a document to the Documents app, and grants only view access to that document to other internal users (default behavior). - if another user uploads the same document (same checksum) as a sign template in the Sign app. attempting to send it, gives an access error. ### Steps to reproduce: 1. Upload a document to Documents app with a user (ie. Mitchell Admin). 2. by default, the document is uploaded with view access to all internal users. 3. login as another internal user (ie. Mark Demo) and upload the same document as a sign template in the Sign app. 4. set the template's `signed document folder` to the same folder as the document uploaded by Mitchell Admin. 5. attempt to send the document for signing. 6. an access error is raised. ### Solution: - Prior to the fix, the `create` method, relied solely on matching the `checksum` of the `sign_requets` attachment with existing documents which resulted in documents not related to the sign request being set as the `reference document`. - The fix now gets the correct document by searching for documents with the same `attachment_id` as the sign request's template attachment. OPW-4421368
The US payroll payslip report now handles hourly payslip lines with zero worked hours without causing an error. This prevents a server crash when printing affected payslips and keeps payroll reporting available for edge cases or corrections.
Original PR description
### Issue: - A division-by-zero occurs in the calculation of the payslip report, when the number of worked hours is 0 and the contract's wage type is 'Hourly. This causes the system to crash (500…
### Issue: - A division-by-zero occurs in the calculation of the payslip report, when the number of worked hours is 0 and the contract's wage type is 'Hourly. This causes the system to crash (500 Internal Server Error). ### Steps to reproduce: - Go to 'Contracts' and change an employee 'Wage Type' to 'Hourly' - Create a payslip for the employee. - Payslip's structure must be 'United States: Regular Pay' - Using the action wheel click on 'Edit payslip lines' - Set number of hours to 0 for any worked line. - Click on 'Print' button. - 500 Internal Server Error. ### Solution: - Issue introduced here https://github.com/odoo/enterprise/commit/935b23cfe74741d1168d93add8c7a221b5168021#diff-6133beb42a4aef7b7c8e1a19738d1fd2689e40e98a2e4e34c0ad4bf12eb2e1b3R52 `worked_days.amount/worked_days.number_of_hours` cause a division by zero if `worked_days.number_of_hours` is 0. - I've updated the template to handle the case. so now If the value is 0 or less, it simply returns 0 instead of dividing. opw-4478495
Changing the date in the duplicate transaction finder no longer causes an error when results appear after an empty state. This makes the bank synchronization workflow more reliable for users reviewing potential duplicate transactions.
Original PR description
Fix traceback when changing the date in the find duplicate tool When the user changes the date in the find duplicate tool, a traceback occurs when transitioning from no rows displayed to rows being displayed. This issue is caused by the `getRowClass` function referencing the outdated `firstIdsInGroup` field, which is never updated. If there were no values initially, the function attempts to call `includes` on a `false` value, resulting in the error. This commit resolves the issue by removing the obsolete `firstIdsInGroup` field and adding a condition to ensure that the value being checked is an array, preventing any traceback. no task id
Fixed an issue where large PDFs could appear as a blank white viewer when preparing or signing documents. This improves reliability for users working with longer agreements or multi-page documents in Odoo Sign.
Original PR description
Steps ----- 1. Sign > 'Upload a PDF & Sign' 2. Choose a PDF with a large amount of pages (typically 40 pages should trigger the issue). 3. The PDF is not visible, the viewer is fully white. Cause ----- The `canvas` HTML element `#canvas_layer_0` used to display information related to radio buttons crashes if its height is too important because there are a lot of pages in the PDF. There's no issue with the PDF itself, when dragging a sign item over the document, the canvas is hidden and the PDF appears correctly. The exact problematic value depends on browser and environment, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas#maximum_canvas_size Solution ----- Use a maximum canvas size but keep the styling of the canvas element to cover all the PDF viewer. This means a scaling factor needs to be applied to the position of the sign items between which the lines are drawn. opw-4407698
Financial report rows and columns will now keep the intended order automatically during database upgrades. This prevents reports from appearing in an unexpected sequence if the underlying report definitions change, reducing manual maintenance and upgrade risk.
Original PR description
Having no manual sequence on report lines/columns might be problematic in case of DB upgrade, if the line order changed in the xml files, as the report won't adapt and update the sequence field. Setting auto_sequence will ensure that this won't ever be a problem anymore (and avoid the tedious task of manually setting the sequence on each line/column)
This fix ensures subscription invoice lines use the correct quantity when billing products based on ordered quantity, especially around future or deferred billing periods. It prevents incorrect invoiced quantities from being calculated from future subscription periods, improving billing accuracy for subscription customers.
Original PR description
Before this commit, the quantity invoiced in _prepare_invoice_line would be compted based on the result of _get_subscription_qty_invoiced for a future period. For product invoiced based on ordered quantity, it makes no sense as the quantity is the ordered quantity. This commit split the logic to reuse code when we need to know which quantity must be invoiced or which quantity have been invoiced in the past.
Tax closing messages now show a clickable link to the related main closing entry instead of displaying raw HTML text. This makes it easier for accounting users to navigate between dependent tax closing entries and their parent entry.
Original PR description
When you had tax closing entries that depended on a main closing entry, the posting of that main entry would log a message on each depending entry containing a link to the main closing entry. In [this commit] the way that message is constructed was changed, making it safer but also causing the link HTML to be escaped. It would just show raw HTML in the logged message instead of a link. This commit constructs the message in a correct and safe way so the link works again in the logged message. [this commit]: https://github.com/odoo/enterprise/commit/09f5b35493bee7b63e96e8b28ad741aeb5ee80e5
Reconciled batch payments no longer appear as available options during bank reconciliation. This prevents users from accidentally seeing or selecting payments that have already been matched, keeping the reconciliation workflow clearer and more accurate.
Original PR description
### Steps to reproduce: - In Accounting, create a new Customer invoice - Create a payment for this invoice - In Customer > Batch Payments create a new batch payment - Select the payment you created - In the Dashboard click on the three dots of the "Bank" block and click on transactions - Create a new transaction with the same amount as the invoice - Click "Match" on the right - In the "Batch Payments" tab select the Batch payment previously created - Validate - Back in the Dashboard, click on the reconcile button of the Bank block - In the "Batch Payments" tab the batch payment is still here even if it is reconciled ### Cause: There are no domain to filter the batch payments. ### Solution: Add a domain to check the state of the batch payments, do not display if it is "reconciled". opw-4461341
Opening the Documents app after switching to mobile view no longer triggers an error. This improves reliability for users who access documents from phones or resized browser windows without needing to refresh the page.
Original PR description
Steps to reproduce: 1. In the Odoo home menu, switch to the mobile view 2. Don't refresh the page 3. Click on the document app 4. Traceback occurs Technical Reason: without refreshing the template was not updating according to mobile view and in 'documents.SearchPanel' was replacing 'we.SeachPanel.Small' with 'web.SearchPanel.Section' and 'we.SeachPanel.Small' is only called if 'env.isSmall'. After this commit: No traceback will occur while opening the document app in mobile view. Task-4437768
Fixes subscription invoices so their start and end dates reflect the actual billing period, especially when invoicing after delivery. This helps prevent incorrect deferred revenue periods and gives customers and finance teams more accurate invoice information.
Original PR description
The deferred start date (start date) relied on either the `last_invoice_date` or the `order_id.last_invoice_date`. If both were unset, the start date of the invoice was not defined, leading to…
The deferred start date (start date) relied on either the `last_invoice_date` or the `order_id.last_invoice_date`. If both were unset, the start date of the invoice was not defined, leading to incorrect calculations. The deferred end date (end date) was always set to "today" because the calculation used the earliest date among "today," the theoretical stop, or the subscription end date. As "today" is always the earliest, the end date incorrectly marked the current date as the last day of the billing period. The deferred start date should be based on the last invoiced date or the subscription start date as a fallback. The deferred end date marks the last day of the billing period it should be the earliest between: - The end date of the current invoicing period (theoretical stop) - The subscription's end date (if set) Steps to Reproduce: Setup Product with Subscription and Inventory Tracking: Go to Sales > Products and create a new product. Enable Subscription for the product. Enable Track Inventory for the product. Set Invoicing Policy to either "Ordered Quantity" or "Delivered Quantity" based on the scenarios below. Scenario 1: Invoicing Policy - "Ordered Quantity" (No bug here) Create a Sales Order with the product and confirm it. Generate the invoice. Expected and actual Behavior: The Start Date and End Date on the invoice should be correctly populated and correspond to the subscription period. Scenario 2: Invoicing Policy - "Delivered Quantity" Create a Sales Order with the product and confirm it. Deliver the product. Generate the invoice. Actual Behavior:The Start Date and End Date on the invoice are both incorrect. OPW-4458048
Miscellaneous changes
Steps - create an accrual plan with a level giving 1 hour every month and a carry over with a maximum of 4 hours. Set accrued gain time at the start of the period and carry-over time at start of the year. - create an allocation using this accrual plan, for a time off type in days, set the start date on the first day of next year. - go to Time Off Dashboard - check the balance on the middle of the month of the following year (e.g. 15 january 2026 if the allocation starts on 1 january 2025
Original PR description
Steps - create an accrual plan with a level giving 1 hour every month and a carry over with a maximum of 4 hours. Set accrued gain time at the start of the period and carry-over time at start of the…
Steps - create an accrual plan with a level giving 1 hour every month and a carry over with a maximum of 4 hours. Set accrued gain time at the start of the period and carry-over time at start of the year. - create an allocation using this accrual plan, for a time off type in days, set the start date on the first day of next year. - go to Time Off Dashboard - check the balance on the middle of the month of the following year (e.g. 15 january 2026 if the allocation starts on 1 january 2025). -> ~14 days of time off available: the max postpone amount is not applied, the time gained is in days and not in hours and more than 1 day is gained/month (balance a few days after the start of the allocation should be +1 added_value but is more than that). Causes: - the maximum amount of carry over `postpone_max_days` is applied in days even if the accrual `added_value` is in hours and the UI shows `postpone_max_days` as "Up to X hours". - `get_future_leaves` returns a number of hours if the allocation is in hours, even if the time off type is in days. - the number of hours from the accrual at the beginning of the allocation is too high if the start of the accrual is in the future and gain time added at the start of the period due to cache not being invalidated. https://github.com/odoo/odoo/blob/19c7737fc05539079cde8641bab608c605efacc5/addons/hr_holidays/models/hr_leave_allocation.py#L575-L578 opw-4272315 Forward-Port-Of: odoo/odoo#185699
Steps to reproduce the bug: - Create a “Company A” and a “ branch 1” linked to this company - Create a storable product “P1”: - limited to Company A - Select only the branch 1 as current company - Create a receipt for one unit of P1 - Mark it as to do. - Try to create a lot or use lot created in Company A Problem: An acces error is raised: `Incompatible companies on records: - 'Product B' belongs to company 'Branch X' and 'Lot/Serial Number' (lot_id: 'sn_test') belongs to anot
Original PR description
Steps to reproduce the bug:
- Create a “Company A” and a “ branch 1” linked to this company
- Create a storable product “P1”:
- limited to Company A
- Select only the branch 1 as current company
- Create a receipt for one unit of P1
- Mark it as to do.
- Try to create a lot or use lot created in Company A
Problem:
An acces error is raised:
`Incompatible companies on records:
- 'Product B' belongs to company 'Branch X' and 'Lot/Serial Number' (lot_id: 'sn_test') belongs to another company.`
opw-4415565
Forward-Port-Of: odoo/odoo#191529One had a duplicate msgid (i.e. broke the sync) and needed to be re-exported, so re-export them all to fix all other out of date pot files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
One had a duplicate msgid (i.e. broke the sync) and needed to be re-exported, so re-export them all to fix all other out of date pot files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
There is already a placeholder image displayed when an image fails to load. opw-4419565 Forward-Port-Of: odoo/odoo#194011 Forward-Port-Of: odoo/odoo#193825
Original PR description
There is already a placeholder image displayed when an image fails to load. opw-4419565 Forward-Port-Of: odoo/odoo#194011 Forward-Port-Of: odoo/odoo#193825
Scenario: - have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it) - merge these partners => UniqueViolation error because of unicity of (fields_id, company_id, res_id) constraint of ir_property table Why: The query merging property doesn't take NULL into account for company_id when checking if the destination partner already has this property. Also a savepoint was used, without ignoring the error so the import could
Original PR description
Scenario: - have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it) - merge these partners => UniqueViolation error because of…
Scenario: - have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it) - merge these partners => UniqueViolation error because of unicity of (fields_id, company_id, res_id) constraint of ir_property table Why: The query merging property doesn't take NULL into account for company_id when checking if the destination partner already has this property. Also a savepoint was used, without ignoring the error so the import could not be done if an error happened. Fix: Take the case where both records have NULL company_id into account. Also ignore error and log a warning when a legitimate error happens because of duplicate ir.property in source records. Note: This issue should only happen when: - modifying ir.property directly - after a migration with a res.partner field becoming company_dependent field, the partners without company would get an ir.property without company_id Without the fix, the added test would fail because of an error at each _merge call. opw-4300572 opw-4030442 Forward-Port-Of: odoo/odoo#194942 Forward-Port-Of: odoo/odoo#188673
Steps ----- - Have a user with 'Employees' Administator rights and no 'Administration' rights. - Create a new employee. - When viewing the Kanban views of employees, the image for the newly created employee appears corrupted (the text 'binary file' appears instead of the image). Cause ----- When we create a new employee, `_avatar_generate_svg` is called https://github.com/odoo/odoo/blob/717f3a1ab25613c02c2d0b28fa8dd73f4e6c75e0/addons/hr/models/hr_employee.py#L497-L498 that returns a svg
Original PR description
Steps ----- - Have a user with 'Employees' Administator rights and no 'Administration' rights. - Create a new employee. - When viewing the Kanban views of employees, the image for the newly created employee appears corrupted (the text 'binary file' appears instead of the image). Cause ----- When we create a new employee, `_avatar_generate_svg` is called https://github.com/odoo/odoo/blob/717f3a1ab25613c02c2d0b28fa8dd73f4e6c75e0/addons/hr/models/hr_employee.py#L497-L498 that returns a svg/xml base-64 encoded. However, only users with write rights to `ir.ui.view` are able to create svg/xml attachments. https://github.com/odoo/odoo/blob/717f3a1ab25613c02c2d0b28fa8dd73f4e6c75e0/odoo/addons/base/models/ir_attachment.py#L368-L371 Else, the attachment has a text mimetype forced, leading to it being incorrectly displayed. Change ----- A default image is not generated at employee creation if the user doesn't have sufficient rights. opw-4311251 Forward-Port-Of: odoo/odoo#190214
### Description of the issue/feature this PR addresses: - The [_get_plan_available_base_domain()](https://github.com/odoo/odoo/blob/18.0/addons/mail/wizard/mail_activity_schedule.py#L330) method is built and `self.ensure_one()` is placed in it but it is called in `_compute_plan_available_ids()` with `self` which can have multiple records ### Current behavior before PR: - The error `ValueError: Expected singleton: mail.activity.schedule(1, 2)` occurred ### Desired behavior after PR is m
Original PR description
### Description of the issue/feature this PR addresses: - The [_get_plan_available_base_domain()](https://github.com/odoo/odoo/blob/18.0/addons/mail/wizard/mail_activity_schedule.py#L330) method is built and `self.ensure_one()` is placed in it but it is called in `_compute_plan_available_ids()` with `self` which can have multiple records ### Current behavior before PR: - The error `ValueError: Expected singleton: mail.activity.schedule(1, 2)` occurred ### Desired behavior after PR is merged: - The problem has been fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194338
This commit makes the same fix as [1] but it does t for kanban views instead of list views. We discovered in task [2] we were developing for the master branch that we needed this fix and that we wanted to fix it from 17.0 [1]: ecc0a38a1d3b04f854d761fd498b120a4dfef5ad [2]: opw-4370092 Task: opw-4370092 Forward-Port-Of: odoo/odoo#194941 Forward-Port-Of: odoo/odoo#194859
Original PR description
This commit makes the same fix as [1] but it does t for kanban views instead of list views. We discovered in task [2] we were developing for the master branch that we needed this fix and that we wanted to fix it from 17.0 [1]: ecc0a38a1d3b04f854d761fd498b120a4dfef5ad [2]: opw-4370092 Task: opw-4370092 Forward-Port-Of: odoo/odoo#194941 Forward-Port-Of: odoo/odoo#194859
If you pay an invoice with multiple payments some roundings are made for the taxes. On the last payment, the error from those roundings are put on a move to make sure that the exact amount of the invoice is paid. That move was put on the wrong journal. It was put in the 'Exchange Difference' journal instead of the 'Cash Basis Taxes'. opw-4460696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193994
Original PR description
If you pay an invoice with multiple payments some roundings are made for the taxes. On the last payment, the error from those roundings are put on a move to make sure that the exact amount of the invoice is paid. That move was put on the wrong journal. It was put in the 'Exchange Difference' journal instead of the 'Cash Basis Taxes'. opw-4460696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193994
The cogwheel dropdown menu is unwanted and only contains the 'Export All' button, which is disabled with an attribute. This commit extends the existing base tree view for this specific use to avoid interfering with other views that use/extend it. Task ID: [4471980](https://www.odoo.com/odoo/project/966/tasks/4471980) Forward-Port-Of: odoo/odoo#193987
Original PR description
The cogwheel dropdown menu is unwanted and only contains the 'Export All' button, which is disabled with an attribute. This commit extends the existing base tree view for this specific use to avoid interfering with other views that use/extend it. Task ID: [4471980](https://www.odoo.com/odoo/project/966/tasks/4471980) Forward-Port-Of: odoo/odoo#193987
Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback occurs) starting from Odoo version 18.0 and in browsers older than Chrome 112 or Firefox 121. This bug happens because the same selector, used by jQuery, combines both the ":has" pseudo-class and the ":is" pseudo-class (this ":is" pseudo-class was introduced into the same selector by commit [2] st
Original PR description
Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback…
Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback occurs) starting from Odoo version 18.0 and in browsers older than Chrome 112 or Firefox 121. This bug happens because the same selector, used by jQuery, combines both the ":has" pseudo-class and the ":is" pseudo-class (this ":is" pseudo-class was introduced into the same selector by commit [2] starting from Odoo version 18.0). This is not compatible with the older browsers mentioned above. The bug only appears in version 18. However, we already fixed this in 16.0 in case potential customizations had added the ":is" pseudo-class to the same selector. [1]: https://github.com/odoo/odoo/commit/65a85009800dfa45526ebdc41d3a0a808b2e9f6d [2]: https://github.com/odoo/odoo/commit/e0fc83760f991fa2fea39763bb2709d9e0182316 opw-4494945 Forward-Port-Of: odoo/odoo#194908 Forward-Port-Of: odoo/odoo#194676
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#194426 Forward-Port-Of: odoo/odoo#192048
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#194426 Forward-Port-Of: odoo/odoo#192048
Because 'Tax ID' was within the `t-esc` the term was never translated. This goes against some country's compliance requirements for receipts, so we make it translatable now. 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#195014 Forward-Port-Of: odoo/odoo#194801
Original PR description
Because 'Tax ID' was within the `t-esc` the term was never translated. This goes against some country's compliance requirements for receipts, so we make it translatable now. 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#195014 Forward-Port-Of: odoo/odoo#194801
Description of the issue/feature this PR addresses: The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python 3.12, as the requirements.txt specifies werkzeug 3.0.1. This results in a misleading error stating that auth_signup is not installed on the database when authenticating a new user with an OAuth provider. Current behavior before PR: When attempting to authenticate a new user with an OAuth provider i
Original PR description
Description of the issue/feature this PR addresses: The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python…
Description of the issue/feature this PR addresses: The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python 3.12, as the requirements.txt specifies werkzeug 3.0.1. This results in a misleading error stating that auth_signup is not installed on the database when authenticating a new user with an OAuth provider. Current behavior before PR: When attempting to authenticate a new user with an OAuth provider in Odoo using Python 3.12, the method werkzeug.http.parse_www_authenticate_header is called. Since this method is removed in Werkzeug 3.0.1, a misleading error message about auth_signup not being installed on the database is displayed. Desired behavior after PR is merged: The code will use WWWAuthenticate.from_header for parsing the WWW-Authenticate header if available, otherwise, it will fall back to using werkzeug.http.parse_www_authenticate_header for compatibility with older versions of Werkzeug (2.0 and 2.2). The misleading error message will no longer appear, and OAuth authentication will work as expected. Fixes #194002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194484
When creating a new mass mailing from an event, the default domain retrieved when switching mailing type is missing the event id filter Steps to reproduce (mass_mailing_sms required): - Open an event with attendees - Click 'Contact Attendees' - Take note of the mailing domain - Switch Mailing Type from Email to SMS Issue: Domain is missing the event_id This does not occur when opening the form view because the default mailing domain is given via context opw-4337256 Forward-Port-
Original PR description
When creating a new mass mailing from an event, the default domain retrieved when switching mailing type is missing the event id filter Steps to reproduce (mass_mailing_sms required): - Open an event with attendees - Click 'Contact Attendees' - Take note of the mailing domain - Switch Mailing Type from Email to SMS Issue: Domain is missing the event_id This does not occur when opening the form view because the default mailing domain is given via context opw-4337256 Forward-Port-Of: odoo/odoo#194809 Forward-Port-Of: odoo/odoo#189317
The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/odoo#172820 Forward-Port-Of: odoo/odoo#157028
Original PR description
The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/odoo#172820 Forward-Port-Of: odoo/odoo#157028
One had a duplicate msgid (i.e. broke the sync) and needed to be re-exported, so re-export them all to fix all other out of date pot files. Also add `pos_urban_piper_enhancements` to be translated since it was apparently added into stable without being marked to be translated.
Original PR description
One had a duplicate msgid (i.e. broke the sync) and needed to be re-exported, so re-export them all to fix all other out of date pot files. Also add `pos_urban_piper_enhancements` to be translated since it was apparently added into stable without being marked to be translated.
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and approve the expense. - Go back to the expenses list view Issue: Notice this expense is at the top of the list and grayed out Cause: The order is determined by the extract_state_processed field: https://github.com/odoo/enterprise/blob/ba06e216ab73c73e3a67fd917623c6ad357b869f/hr_expense_ext
Original PR description
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and…
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and approve the expense. - Go back to the expenses list view Issue: Notice this expense is at the top of the list and grayed out Cause: The order is determined by the extract_state_processed field: https://github.com/odoo/enterprise/blob/ba06e216ab73c73e3a67fd917623c6ad357b869f/hr_expense_extract/models/hr_expense.py#L21 An expense is muted when this field is set to `True`: https://github.com/odoo/enterprise/blob/1df090289f3c45c200d133734989a6d9a8073145/hr_recruitment_extract/views/hr_applicant_views.xml#L67 Solution: We override `iap_extract` method https://github.com/odoo/enterprise/blob/2e3113562309bf4d440e12ab09eaf94d0b302f1f/iap_extract/models/extract_mixin.py#L69 If the expense is not in draft, it indicates that the process continued without waiting for the extraction process to complete (values were manually entered). To ensure a consistent extraction state, we extend the "Check OCR Status" logic to prevent an infinite waiting_extraction status. fw note: force_write paramater cleaned up in https://github.com/odoo/enterprise/pull/63717 AS FROM 18.0: It appears that the check_ocr_status extension is 'dead code'. In fact, the cron checking the ocr status calls `check_all_status` and not directly `check_ocr_status`. The domain used excludes our case https://github.com/odoo/enterprise/blob/c4a0a4a06b46ba4173024cb07f4666d466306bb9/iap_extract/models/extract_mixin.py#L376-L378 And so `_try_to_check_ocr_status` will not be called. Therefore `_check_ocr_status` will not be called either. `check_ocr_status` is only called when you click 'refresh' on the banner. This banner disappeard because `extract_can_show_banners` is set to `False` when the record is not in draft. And the route will not solve the issue either becasue it filters out non draft records.https://github.com/odoo/enterprise/blob/b34c06c34c7fdaa55d9dbc5cf87fcfaa6f0a7602/hr_expense_extract/controllers/main.py#L8-L14 opw-4239404 X-original-commit: https://github.com/odoo-dev/enterprise/commit/3cfb6517220ae252d633bb9debc5010a0f14efbe
Problem ---------- The SHIF is based on the gross and not the basic. There is no SHIF Relief Objective ---------- Correct the SHIF implementation Solution ---------- Get GROSS in SHIF computation rather than BASIC Remove SHIF Relief Rule task-4414345 Forward-Port-Of: odoo/enterprise#75770
Original PR description
Problem ---------- The SHIF is based on the gross and not the basic. There is no SHIF Relief Objective ---------- Correct the SHIF implementation Solution ---------- Get GROSS in SHIF computation rather than BASIC Remove SHIF Relief Rule task-4414345 Forward-Port-Of: odoo/enterprise#75770
Currently, an error occurs when attempting to insert field `template_autocomplete_ids` into planning slot list view using studio mode. Step to produce: - Install the `sale_planning` and `web_studio` modules (with demo data). - Open the 'My Planning' list view. - Add the `template_autocomplete_ids` field to the list view using 'studio'. - Error generated at the backend. `ValueError: Expected singleton: planning. Slot(5, 7)` The error occurs because the system attempts to access a
Original PR description
Currently, an error occurs when attempting to insert field `template_autocomplete_ids` into planning slot list view using studio mode. Step to produce: - Install the `sale_planning` and `web_studio` modules (with demo data). - Open the 'My Planning' list view. - Add the `template_autocomplete_ids` field to the list view using 'studio'. - Error generated at the backend. `ValueError: Expected singleton: planning. Slot(5, 7)` The error occurs because the system attempts to access a single value of fields from multiple records at [1]. [1] - https://github.com/odoo/enterprise/blob/5a9d3be9fb65d780ce92c437600220b8a0e95023/planning/models/planning.py#L410-L414 To resolve this issue, use an iteration(for loop) to iterate records one by one. Sentry-6217013028 Forward-Port-Of: odoo/enterprise#77318
The aim of this commit is passing correctly the debug mode in the URL params to the bank sync iframe. It allows to debug the iframe during the development. no task id Forward-Port-Of: odoo/enterprise#77501
Original PR description
The aim of this commit is passing correctly the debug mode in the URL params to the bank sync iframe. It allows to debug the iframe during the development. no task id Forward-Port-Of: odoo/enterprise#77501
Since whatsapp templates are posted on a specific model, the current parent computation becomes incorrect when it comes to templates, because of incorrect domain, in particular `model` and `res_is` parts of it. task-4210393 Forward-Port-Of: odoo/enterprise#70718
Original PR description
Since whatsapp templates are posted on a specific model, the current parent computation becomes incorrect when it comes to templates, because of incorrect domain, in particular `model` and `res_is` parts of it. task-4210393 Forward-Port-Of: odoo/enterprise#70718