Daily updates from Odoo
Saturday, September 27, 2025
46 changes
8 changes
Resolved issues and error corrections
This fixes an issue where website pages could fail to load after setting an SEO cover image and a website domain. The cover image is now saved in a way that works reliably across domains, preventing visitor-facing server errors.
Original PR description
Scenario: - in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize SEO > Cover Image) - set a domain on the website - go to the page with the cover image Result: an error 500 with this…
Scenario:
- in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize
SEO > Cover Image)
- set a domain on the website
- go to the page with the cover image
Result: an error 500 with this traceback error:
```py
File "addons/website/models/mixins.py", line 92, in get_website_meta
opengraph_meta['og:image'] = url_join(root_url, self.env['ir.http']
._url_for(self.website_meta_og_img or opengraph_meta['og:image']))
File "odoo/tools/urls.py", line 59, in urljoin
raise ValueError("Extra URL must use same scheme and host as base,
and begin with base path")
```
Cause: since 19.0 977e62d91f3e8235e251e9d21b08f53db1856c6b werkzeug
url_join is replaced by odoo urljoin, which requires that the path that
is appended has no host, or the same host. Since the current code saves
the scheme and host of the website_meta_og_img, if the URL is different
than the saved one (because of domain or another reason), we get an
error.
Fix: save a relative URL instead of an absolute one.
opw-5101875
opw-5102079
opw-5105258
opw-5107443
opw-5111474
opw-5112343
opw-5113844
opw-5114544
__Note:__ I rebased on 17.0 since the code has not changed since then, the problem just become visible because of the urljoin change.
__Note:__ I created a upgrade PR to fix the issue for migrated database https://github.com/odoo/upgrade/pull/8494
Forward-Port-Of: odoo/odoo#228253This fix ensures cash basis journal item lines show the correct journal entry name instead of a placeholder slash. It helps accounting users rely on accurate labels in journal item lists and reduces confusion during reconciliation and review.
Original PR description
This commit adds a test for the [change made in community](https://github.com/odoo/odoo/pull/225558). ### Issue: In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if…
This commit adds a test for the [change made in community](https://github.com/odoo/odoo/pull/225558). ### Issue: In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name. ### Steps to reproduce: - Activate Cash Basis in the accounting settings - Create a tax with "Tax Exigibility" set "Based on Payment" - Set the "Cash Basis Transition Account" to "Current Assets" - Activate reconciliation on "Current Assets" - Create an invoice with this tax, confirm - In the dashboard, click on Bank and new - Set the name of the invoice as the label, and the amount of the invoice as amount - Save & Close - Go in Accounting > Transactions > Journal Items - The lines created for the cah basis entry display '/' in the column "Journal Entry" ### Cause: This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned. When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`. The callstack is something like this: - `_set_next_sequence()` calls `_locked_increment()` to compute the sequence - `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields - `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()` - `_compute_needed_terms()` needs `invoice_line_ids` - the fetch on `account.move.line` is ordered by `move_name` - So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute` Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`. This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache. ### Solution: Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards. It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`. opw-5056938 Forward-Port-Of: odoo/enterprise#94111
This fixes an accounting display issue where cash basis journal item lines could show '/' instead of the correct journal entry name after posting. The change ensures related accounting fields are refreshed after the sequence number is assigned, improving accuracy in journal item lists and reducing confusion during reconciliation or review.
Original PR description
### Issue: In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name. ### Steps to reproduce: - Activate Cash Basis in the accounting…
### Issue: In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name. ### Steps to reproduce: - Activate Cash Basis in the accounting settings - Create a tax with "Tax Exigibility" set "Based on Payment" - Set the "Cash Basis Transition Account" to "Current Assets" - Activate reconciliation on "Current Assets" - Create an invoice with this tax, confirm - In the dashboard, click on Bank and new - Set the name of the invoice as the label, and the amount of the invoice as amount - Save & Close - Go in Accounting > Transactions > Journal Items - The lines created for the cah basis entry display '/' in the column "Journal Entry" ### Cause: This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned. When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`. The callstack is something like this: - `_set_next_sequence()` calls `_locked_increment()` to compute the sequence - `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields - `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()` - `_compute_needed_terms()` needs `invoice_line_ids` - the fetch on `account.move.line` is ordered by `move_name` - So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute` Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`. This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache. ### Solution: Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards. It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`. opw-5056938 Forward-Port-Of: odoo/odoo#225558
Sales orders now ignore archived projects when deciding whether to show the related project button. This prevents users from seeing a project shortcut when only inactive projects are linked, keeping the sales order view cleaner and less confusing.
Original PR description
Issue: ----- When a project is archived, the project stat button still appears on the sale order. Fix: --------- This commit excludes archived projects from the project count. As a result, the project stat button will be hidden when only archived projects are linked. Steps to reproduce: -------- - Install sale_project module - Create a product with service type, linked to a project and task - Create a sale order with the above product and confirm it - Archive the linked project - Return to the sale order and check the project stat button task-4780817 Forward-Port-Of: odoo/odoo#212730
Users can now archive multiple Helpdesk teams at once even when those teams are connected to different websites. This prevents an error that interrupted routine Helpdesk administration and makes multi-website management more reliable.
Original PR description
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration >…
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration > Websites and create two websites (`W1` and `W2`). - Go to Helpdesk, Configuration > Helpdesk Teams > create two teams (`T1` and `T2`). - Enable the `Website Form` (under `Help Center`), assign `W1` to `T1` and `W2` to `T2`. - Return to the list view, select both teams, and attempt to `archive` them. **Error:** `ValueError: Expected singleton: website(3, 1)` **Root Cause:** At [1], the code incorrectly uses `with_website.website_id.id`, when `multiple websites` are involved, this leads to an `error`. **Fix:** This commit prevents errors and ensures that users can archive multiple helpdesk teams linked to different websites [1]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/website_helpdesk/models/helpdesk.py#L102 sentry-6867906123 Forward-Port-Of: odoo/enterprise#94318
Online shop availability now updates correctly when customers add either a kit product or one of its shared components to their cart. This prevents shoppers from seeing misleading remaining quantities and helps avoid overselling when out-of-stock sales are disabled.
Original PR description
### Steps to reproduce: - In the settings website > Shop: - Disable `Out-of-Stock: Continue Selling`. - Enable `Show Available Qty` if below 5 units. - Create 2 storable products published on the…
### Steps to reproduce:
- In the settings website > Shop:
- Disable `Out-of-Stock: Continue Selling`.
- Enable `Show Available Qty` if below 5 units.
- Create 2 storable products published on the website:
- COMP, put 1 unit in stock.
- KIT with bom of type Kit using 1 x COMP.
- With a private window go to the shop.
- Add 1 x COMP or KIT to the chart.
#### > This is not reflected on the available quantity in stock of the other product
### Cause of the issue:
The availability on the website is computed from the product availability using the `free_qty` fetched because of this override: https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/controllers/variant.py#L10-L13 from which the cart quantity of the product itself is deduced before re-render:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L49-L51 https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L83-L86 While the `free_qty` is correctly computed from kit products based on the component availability:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/mrp/models/product.py#L211-L221 The qties in the virtual cart quantities are not recomputed base on kits.
opw-4889956
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228754
Forward-Port-Of: odoo/odoo#222945This fix swaps two DIOT report columns for Mexico so “exempt imports” and “exempt” appear in the correct positions. The calculated values were already correct, but placing them in the right columns helps avoid confusion and supports accurate reporting.
Original PR description
Description of the issue/feature this PR addresses: The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. Current behavior before PR: “exempt” is column 49 “exempt imports” is column 50 Desired behavior after PR is merged: “exempt” is column 50 “exempt imports” is column 49 Task-id: 5096808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228882 Forward-Port-Of: odoo/odoo#228303
This fixes the Mexican DIOT downloadable TXT report so the two exempt amount columns appear in the correct order. The reported values were already calculated correctly, but placing them in the right columns helps avoid confusion and supports accurate tax filing review.
Original PR description
The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. This Pr changes the order of the columns in the downloadable file (txt) and corrects the tests due to the change. Task-id: 5096808 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95679 Forward-Port-Of: odoo/enterprise#95383
6 changes
Resolved issues and error corrections
This fix prevents website pages from crashing when an SEO cover image is set and the website uses a configured domain. The cover image is now stored in a way that remains valid across domains, keeping pages accessible and social sharing metadata working correctly.
Original PR description
Scenario: - in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize SEO > Cover Image) - set a domain on the website - go to the page with the cover image Result: an error 500 with this…
Scenario:
- in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize
SEO > Cover Image)
- set a domain on the website
- go to the page with the cover image
Result: an error 500 with this traceback error:
```py
File "addons/website/models/mixins.py", line 92, in get_website_meta
opengraph_meta['og:image'] = url_join(root_url, self.env['ir.http']
._url_for(self.website_meta_og_img or opengraph_meta['og:image']))
File "odoo/tools/urls.py", line 59, in urljoin
raise ValueError("Extra URL must use same scheme and host as base,
and begin with base path")
```
Cause: since 19.0 977e62d91f3e8235e251e9d21b08f53db1856c6b werkzeug
url_join is replaced by odoo urljoin, which requires that the path that
is appended has no host, or the same host. Since the current code saves
the scheme and host of the website_meta_og_img, if the URL is different
than the saved one (because of domain or another reason), we get an
error.
Fix: save a relative URL instead of an absolute one.
opw-5101875
opw-5102079
opw-5105258
opw-5107443
opw-5111474
opw-5112343
opw-5113844
opw-5114544
__Note:__ I rebased on 17.0 since the code has not changed since then, the problem just become visible because of the urljoin change.
__Note:__ I created a upgrade PR to fix the issue for migrated database https://github.com/odoo/upgrade/pull/8494
Forward-Port-Of: odoo/odoo#228253Sales orders now ignore archived projects when deciding whether to show the project shortcut. This prevents users from seeing a project button that only leads to inactive work, keeping sales order information cleaner and less confusing.
Original PR description
Issue: ----- When a project is archived, the project stat button still appears on the sale order. Fix: --------- This commit excludes archived projects from the project count. As a result, the project stat button will be hidden when only archived projects are linked. Steps to reproduce: -------- - Install sale_project module - Create a product with service type, linked to a project and task - Create a sale order with the above product and confirm it - Archive the linked project - Return to the sale order and check the project stat button task-4780817 Forward-Port-Of: odoo/odoo#212730
Users can now archive multiple Helpdesk teams connected to different websites in one action without triggering an error. This keeps multi-website helpdesk administration smooth and avoids interruptions during routine cleanup.
Original PR description
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration >…
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration > Websites and create two websites (`W1` and `W2`). - Go to Helpdesk, Configuration > Helpdesk Teams > create two teams (`T1` and `T2`). - Enable the `Website Form` (under `Help Center`), assign `W1` to `T1` and `W2` to `T2`. - Return to the list view, select both teams, and attempt to `archive` them. **Error:** `ValueError: Expected singleton: website(3, 1)` **Root Cause:** At [1], the code incorrectly uses `with_website.website_id.id`, when `multiple websites` are involved, this leads to an `error`. **Fix:** This commit prevents errors and ensures that users can archive multiple helpdesk teams linked to different websites [1]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/website_helpdesk/models/helpdesk.py#L102 sentry-6867906123 Forward-Port-Of: odoo/enterprise#94318
Analytic account dropdowns now show only accounts for the relevant company when users create or edit analytic distributions. This prevents cross-company account visibility and helps keep multi-company data access aligned with business rules.
Original PR description
**Description of the issue/feature this PR addresses:** When creating or editing an analytic distribution, the analytic account selection does not respect the company context. This allows users to…
**Description of the issue/feature this PR addresses:** When creating or editing an analytic distribution, the analytic account selection does not respect the company context. This allows users to see and select analytic accounts from other companies, which violates the multi-company record rules. <img width="669" height="333" alt="2025-09-08_09-28" src="https://github.com/user-attachments/assets/488eb4b1-fdfa-49ca-a57e-8f46a264107d" /> **Current behavior before PR:** The analytic account dropdown in the analytic distribution widget shows analytic accounts from all companies, instead of being restricted to the current company. **Desired behavior after PR is merged:** The analytic account selection in the analytic distribution widget is filtered by company. Only analytic accounts belonging to the document company will be displayed, ensuring compliance with multi-company record rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228268 Forward-Port-Of: odoo/odoo#225835
This fixes the Mexican DIOT report so the “exempt imports” and “exempt” amounts appear in the correct columns. The underlying values were already calculated correctly, but placing them in the right columns helps avoid confusion in tax reporting.
Original PR description
Description of the issue/feature this PR addresses: The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. Current behavior before PR: “exempt” is column 49 “exempt imports” is column 50 Desired behavior after PR is merged: “exempt” is column 50 “exempt imports” is column 49 Task-id: 5096808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228882 Forward-Port-Of: odoo/odoo#228303
This fixes the order of two exempt amount columns in Mexico DIOT report downloads. The reported values were already calculated correctly, but placing them in the proper columns helps ensure submitted TXT files match the expected tax authority format.
Original PR description
The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. This Pr changes the order of the columns in the downloadable file (txt) and corrects the tests due to the change. Task-id: 5096808 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95679 Forward-Port-Of: odoo/enterprise#95383
1 change
Resolved issues and error corrections
Users can now archive multiple helpdesk teams at once even when those teams are connected to different websites. This prevents an error that interrupted normal helpdesk administration and makes multi-website setups easier to manage.
Original PR description
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration >…
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration > Websites and create two websites (`W1` and `W2`). - Go to Helpdesk, Configuration > Helpdesk Teams > create two teams (`T1` and `T2`). - Enable the `Website Form` (under `Help Center`), assign `W1` to `T1` and `W2` to `T2`. - Return to the list view, select both teams, and attempt to `archive` them. **Error:** `ValueError: Expected singleton: website(3, 1)` **Root Cause:** At [1], the code incorrectly uses `with_website.website_id.id`, when `multiple websites` are involved, this leads to an `error`. **Fix:** This commit prevents errors and ensures that users can archive multiple helpdesk teams linked to different websites [1]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/website_helpdesk/models/helpdesk.py#L102 sentry-6867906123 Forward-Port-Of: odoo/enterprise#94318
4 changes
Resolved issues and error corrections
Fixed an issue that prevented users from archiving multiple Helpdesk teams when those teams were connected to different websites. This keeps day-to-day Helpdesk configuration work smooth for companies managing more than one website.
Original PR description
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration >…
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration > Websites and create two websites (`W1` and `W2`). - Go to Helpdesk, Configuration > Helpdesk Teams > create two teams (`T1` and `T2`). - Enable the `Website Form` (under `Help Center`), assign `W1` to `T1` and `W2` to `T2`. - Return to the list view, select both teams, and attempt to `archive` them. **Error:** `ValueError: Expected singleton: website(3, 1)` **Root Cause:** At [1], the code incorrectly uses `with_website.website_id.id`, when `multiple websites` are involved, this leads to an `error`. **Fix:** This commit prevents errors and ensures that users can archive multiple helpdesk teams linked to different websites [1]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/website_helpdesk/models/helpdesk.py#L102 sentry-6867906123 Forward-Port-Of: odoo/enterprise#94318
The barcode workflow now correctly blocks receipt validation when the operation type requires a destination location scan. This helps ensure stock is put into the intended location and prevents incomplete warehouse processing.
Original PR description
This commit fixes the the problem of not forcing destination location scan before barcode validation even if the setting `Force a destination for all products` is activated. To reproduce: 1- Open `Operation Types` in Inventory. 2- Go to Receipt and open the `Barcode App` page. 3- Select `Destination Location` to be `After group of products`. 4- Activate the checkbox `Force a destination for all products`. 5- Create a receipt and validate it in Barcode App without scanning a destination location. = Validation is accepted. However you shouldn't be able to validate unless you scan a destination location. Forward-Port-Of: odoo/enterprise#94781
A test was added to ensure cash basis journal item lines keep the correct journal entry name after posting instead of showing '/'. This helps accountants trust that journal item lists display accurate references for reconciled payments and cash basis tax entries.
Original PR description
This commit adds a test for the [change made in community](https://github.com/odoo/odoo/pull/225558). ### Issue: In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if…
This commit adds a test for the [change made in community](https://github.com/odoo/odoo/pull/225558). ### Issue: In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name. ### Steps to reproduce: - Activate Cash Basis in the accounting settings - Create a tax with "Tax Exigibility" set "Based on Payment" - Set the "Cash Basis Transition Account" to "Current Assets" - Activate reconciliation on "Current Assets" - Create an invoice with this tax, confirm - In the dashboard, click on Bank and new - Set the name of the invoice as the label, and the amount of the invoice as amount - Save & Close - Go in Accounting > Transactions > Journal Items - The lines created for the cah basis entry display '/' in the column "Journal Entry" ### Cause: This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned. When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`. The callstack is something like this: - `_set_next_sequence()` calls `_locked_increment()` to compute the sequence - `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields - `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()` - `_compute_needed_terms()` needs `invoice_line_ids` - the fetch on `account.move.line` is ordered by `move_name` - So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute` Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`. This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache. ### Solution: Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards. It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`. opw-5056938 Forward-Port-Of: odoo/enterprise#94111
This fix updates Planning test behavior so one test no longer causes delays or failures in later tests. It helps keep automated checks stable, reducing false alarms during development and release validation.
Original PR description
Due to the nature of the test cases written returning an empty object to actionService in test cases as they overriden using onRpc and causes a delay error, which causes the next case to fail. Fix: - Replace the empty object with a false, which is handled in the function runbot-231599 Forward-Port-Of: odoo/enterprise#94605
21 changes
Resolved issues and error corrections
This fixes Planning test behavior that could cause later automated checks to fail unexpectedly. It improves confidence in test results without changing the product experience for end users.
Original PR description
Due to the nature of the test cases written returning an empty object to actionService in test cases as they overriden using onRpc and causes a delay error, which causes the next case to fail. Fix: - Replace the empty object with a false, which is handled in the function runbot-231599
The AI service now handles invalid tool requests and usage limits more clearly instead of failing silently. This helps conversations recover from errors, avoids stalled responses, and keeps final answers cleaner for users.
Original PR description
This commit introduces several related fixes to the LLM API service to make tool call processing more robust and prevent silent failures. - **Unknown Tool Calls**: When an LLM requests a tool with an…
This commit introduces several related fixes to the LLM API service to make tool call processing more robust and prevent silent failures. - **Unknown Tool Calls**: When an LLM requests a tool with an invalid or unknown name, it previously resulted in an empty response, causing the conversation to stall. This change ensures that a proper error message is now returned to the LLM for the invalid tool call. This allows the LLM to process the failure and continue the conversation. - **Failing on Limits**: The query processing loop in `_request_llm` has limits for both successive API calls and the number of tool calls per request. Previously, these limits would be reached silently. - **API Call Limit**: If the `AI_MAX_SUCCESSIVE_CALLS` limit is reached without the LLM providing a final answer, a `ValueError` is now raised. This prevents silent failures and makes it clear to the calling code that the request could not be completed. - **Tool Call Limit**: If the number of tool calls in a single response exceeds `AI_MAX_TOOL_CALLS_PER_CALL`, any calls beyond the limit are now provided with a result stating that the limit was reached. This gives the LLM the opportunity to try the unprocessed tool calls again in a subsequent turn. - **Ignore Explanatory Text**: The text that LLMs often include alongside a tool call request (the "thinking" text) is now ignored to provide a cleaner and more concise final response to the user.
The project creation wizard now displays the Customer field neatly on one line when Billable is enabled. This improves visual consistency and makes the form easier to read, without changing any business process or data behavior.
Original PR description
**Steps to Reproduce:** - Go to the Projects app - Click "Create" to open the wizard - Enable the "Billable" option - Observe the alignment of the "Customer" field that appears **Issue:** The…
**Steps to Reproduce:** - Go to the Projects app - Click "Create" to open the wizard - Enable the "Billable" option - Observe the alignment of the "Customer" field that appears **Issue:** The "Customer" label and input field are stacked vertically, with the input's underline (green line) positioned below the label, leading to uneven spacing and misalignment compared to other fields. **Current behaviour:** - The "Customer" field is visually misaligned , its label and input are not horizontally aligned, causing UI inconsistency. **Expected behaviour:** - The "Customer" label and input field should align horizontally on a single line, with the input's underline matching the label's baseline. **Fix:** The layout is updated using proper flexbox classes to ensure the "Customer" label and input field appear on the same line with proper vertical alignment. Task-4949146 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221242
Point of Sale now prevents two users or sessions from creating separate invoices for the same order at the same time. If invoicing is already underway, the user sees an error, and if an invoice already exists, the system opens it instead of creating another one.
Original PR description
This fix prevents multiple users from generating separate invoices for the same POS order simultaneously. Steps to reproduce: 1. Create a new POS order. 2. Open two tabs (or two POS sessions). 3. Generate an invoice in the first tab. 4. Immediately try to generate an invoice in the second tab. 5. Two invoices will be generated. With this fix: - If a user attempts to generate an invoice while another is already in progress, an error message is shown. - If the invoice has already been generated, the existing invoice view is opened instead of creating a duplicate. opw-5004504 Forward-Port-Of: odoo/odoo#223845
This update fixes an internal equity test that could fail unpredictably because records were compared in an inconsistent order. Making the test deterministic helps reduce false alarms in automated checks and supports smoother maintenance without changing customer-facing behavior.
Original PR description
The test `test_option_into_share` was failing because `assertRecordValues` compares lists in order, and the records returned by the `cap.table` search were not in the same sequence as the expected values in the test. This commit makes the test deterministic by replacing list-based `assertRecordValues` calls with individual assertions per record. [RB-232585](https://runbot.odoo.com/odoo/error/232585)
This update fixes two time off request issues: users can now clear an end date without triggering an error, and edited leave dates use the correct employee work schedule. It also improves the related calendar calculation performance, helping leave requests stay accurate when contracts or schedules change.
Original PR description
Bug 1 - traceback on removing end date
Steps to reproduce:
- open the time off request form
- remove the end date
Cause:
- bool comparison with date
Fix:
- add a check before using the request_date_from or request_date_to
Bug 2 - inappropriate resource calendar use
Steps to reproduce:
- Create two different version with different working calendar.
- now while creating leave record it uses correct resource calendar as per
request dates.
- but after saving the leave record, if try to change the request dates
it does not use correct resource calendar.
Cause:
- resource calendar compute method is not dependent on request dates.
Fix:
- updated the depends of compute method.
moreover refactored the method to improve the performance.
task-4965122
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#220313The Point of Sale discount flow now avoids a crash when staff use the ticket screen with draft orders and keyboard input. This keeps the checkout/ticket review experience stable when global discounts are configured.
Original PR description
Steps: ---------- - Install pos_discount. - Open a PoS config with a global discount configured. - Add a product to the order. - Open the ticket screen, select an order line, and press any key on the keyboard. Issue: ---------- - A traceback is raised for accessing product_id from an undefined order line. Cause: ---------- - The system tries to compare the selected order line's product with the global discount product, but draft order lines cannot be selected on the ticket screen. Fix: ---------- - Compare only if the selected line is available. task-5095765
Bill matching no longer fails when a purchase order and vendor bill use the same individual contact linked to a company. Odoo now consistently matches the vendor through the parent company, preventing errors and helping purchasing teams process bills without interruption.
Original PR description
**Issue** When both a Purchase Order and a Vendor Bill are created using the same individual contact linked to a company, Bill Matching fails with a traceback. **Steps to Reproduce** 1. Create an…
**Issue** When both a Purchase Order and a Vendor Bill are created using the same individual contact linked to a company, Bill Matching fails with a traceback. **Steps to Reproduce** 1. Create an individual contact and link it to a company. 2. Create a Purchase Order with the individual as a vendor. 3. Create a Vendor Bill with the same individual as the vendor. 4. Try to perform Bill Matching. 5. A `ValueError: Expected singleton: res.partner(...)` is raised. Video for reference: https://drive.google.com/file/d/1qVnPLpk8jyMTKz-6AVLSaN2nVVeWiF4y/view **Root Cause** Purchase Orders store the partner exactly as selected (the individual contact), while Vendor Bills are normalized internally to the parent company (`commercial_partner_id`). This creates a mismatch in the Bill Matching logic, where records reference both the individual and the company, leading to an invalid recordset and the singleton error. **Fix** Always normalize vendors to their `commercial_partner_id` during Bill Matching. This ensures that both Purchase Orders and Vendor Bills consistently reference the same partner, avoiding mismatches between individual contacts and their parent company. Opw-5050339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226130
The salary configurator now presents currency amounts and employer cost details more consistently, making contract offers easier to read. It also fixes a Belgian salary calculation display issue so part-time gross salary information keeps all required values instead of losing details.
Original PR description
The salary configurator had several UI inconsistencies that impacted the readability of contract offers:
- Replaced complex input-group styling with flexbox layout in resume_sidebar.xml to properly align currency symbols and values using Bootstrap's fs-5 and fw-normal classes
- Added align-items-center and justify-content-end for consistent spacing
- Changed tuple reconstruction in main.py to use (_('Gross (Part Time)'), *salary_tuple[1:]) to preserve all salary_tuple values (positions 1-5) instead of truncating to only first 3 elements
task-5063224Users with view-only access can now mark or unmark documents as favorites using the keyboard shortcut without seeing an access error. This makes the Documents app shortcut behavior consistent with manual favoriting and avoids interruptions for users browsing shared documents.
Original PR description
steps to reproduce =================== - Select a document where you have viewer permission. - Try to toggle the favorite through a hotkey. - Access Error when toggling favorite. Technical =========== - To maintain compatibility with stable versions and avoid changing the return type of the existing method, created the helper method, which will call `toggle_favorited` as we need to handle it for multiple records. After this commit ================== - This commit handles the accessError for shortcut flow. As in 18.3 we already have documents_favorite widget https://github.com/odoo/enterprise/pull/82639 which will work for manually favoriting the document, but it is not handling the shortcut flow. Task-4910326 Forward-Port-Of: odoo/enterprise#89928
Manufacturing backorders now keep earlier operations in the correct cancelled state instead of incorrectly changing them to in progress after later work is completed. This helps production teams avoid misleading work order statuses and better track what still needs action.
Original PR description
In this bug, in backorder created for later work opertions, the `state` of initial operation is changed to `progress` after, the backorder is `done`. To produce the bug: 1- Create a Bill of Materials with at least two operations at two work centers 2- Create a manufacturing order and confirm it. 3- Complete the first operation and edit the quantity on the second operation so there is a backorder for the remaining quantity 4- In the second work order, the first operation initially appears as `Cancelled`. Once the second operation is completed, it will change to `In progress`. opw-4931653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222075
Chilean electronic supplier bills now import certain exempt lines as negative amounts when the official document marks them that way. This prevents overstatement of vendor bill totals and improves compliance with Chilean electronic invoicing rules.
Original PR description
### Issue: When, in a DTE file, a line has the code 6 in `IndExe`. The amount of the line is supposed to be negative. (See the [doc](https://www.sii.cl/factura_electronica/formato_dte.pdf) page 31/32) ### Steps to reproduce: - Install 'l10n_cl_edi' and switrch to a Chilean company - Have a DTE file with a line having '6' in `IndExe`: - In Accounting > Vendor > Bills, click the button "Upload" and select the DTE file - The imported move has positive values on the every lines ### Cause: The values of `IndExe` are not considered. ### Solution: Add a condition changing the sign of `price_unit` when 6 is in `IndExe` opw-4954723 Forward-Port-Of: odoo/enterprise#95405 Forward-Port-Of: odoo/enterprise#93393
This fixes an error that blocked newly created users from loading demo data in the Appraisal app. The change ensures the demo data loading process has the necessary access rights, making onboarding and testing smoother.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module. Steps to reproduce: --- - Install `hr_appraisal` module (without demo data) - Create NEW user > Login…
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module.
Steps to reproduce:
---
- Install `hr_appraisal` module (without demo data)
- Create NEW user > Login with new user
- Open `Appraisal` and Click `Load Demo Data`
Traceback:
---
```py
ParseError: <record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">
<field name="user_id" ref="base.user_admin"/>
<field name="name">Appraisal of Emma Granger</field>
<field name="partner_ids" eval="[(6,0,[ref('hr.work_contact_sj'), ref('hr.work_contact_mw'), ref('hr.work_contact_eg')])]"/>
<field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 07:00:00')"/>
<field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 09:00:00')"/>
<field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>
<field name="res_model">hr.appraisal</field>
<field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>
</record>
ValueError: ParseError('while parsing /home/odoo/odoo/enterprise/hr_appraisal/data/scenarios/hr_appraisal_scenario.xml:561, somewhere inside\n<record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">\n <field name="user_id" ref="base.user_admin"/>\n <field name="name">Appraisal of Emma Granger</field>\n <field name="partner_ids" eval="[(6,0,[ref(\'hr.work_contact_sj\'), ref(\'hr.work_contact_mw\'), ref(\'hr.work_contact_eg\')])]"/>\n <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 07:00:00\')"/>\n <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 09:00:00\')"/>\n <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>\n <field name="res_model">hr.appraisal</field>\n <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>\n </record>') while evaluating
'action = model._load_demo_data()'
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
Forward-Port-Of: odoo/enterprise#93461Forward-Port-Of: odoo/enterprise#95022
Original PR description
Forward-Port-Of: odoo/enterprise#95022
When no receipt printer is connected, self-order payments now send the order to the preparation display before showing the browser print prompt. This prevents staff from missing or waiting on paid orders because a print dialog was left open in another tab.
Original PR description
Steps to reproduce: ------------------- 1. Enable self orderdering, and set an online payment method 2. Open 3 tabs: the main PoS one, the self order one, and the preparation display one (we have to…
Steps to reproduce: ------------------- 1. Enable self orderdering, and set an online payment method 2. Open 3 tabs: the main PoS one, the self order one, and the preparation display one (we have to setup the prep display too) 3. In the self order tab, make an order and pay for it Observe that in the main tab, a receipt modal (window.print) appears, and the order is not sent to the payment display (on the third tab) until we either dismiss or accept the printing popup on the main tab. Reason: ------- If there is no printing device connected, we fallback to printing the receipt with `window.print`; this operation blocks the execution of the code that follows it, in our case sending the order to the preparation display, until we either dismiss or confirm the printing popup. Now if the user is not paying attention to the main tab (only looking at the preparation display for instance), the order will not appear in the prep display. Fix: ---- In the case of fallbacking to web printing, we execute the print in a `setTimeout`, so to not block the code that comes after it. opw-5039685 Forward-Port-Of: odoo/odoo#225742
The mobile preview button now uses the intended color in both the website menu and the HTML builder top bar. This makes the editing interface more visually consistent and easier to recognize for users previewing pages on mobile.
Original PR description
- The mobile preview button color is changed at two places: 1. In the website systray menu. 2. In the HTML builder top-bar. Before: <img width="222" height="103" alt="outsidediff" src="https://github.com/user-attachments/assets/b2d3997a-4011-440f-8d14-22b5ebaf295c" /> <img width="428" height="104" alt="indiff" src="https://github.com/user-attachments/assets/2cb07173-2f20-42b0-abb2-289ed7476347" /> After: <img width="251" height="89" alt="image" src="https://github.com/user-attachments/assets/2c6f516c-96a7-495e-bea4-0e6e7b39ae8c" /> <img width="409" height="92" alt="image" src="https://github.com/user-attachments/assets/ea939d9d-d47c-472f-b62d-db1dc8bd81c4" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
New users can now load demo data in the Attendance app without running into a permissions error. This makes it easier for teams to try or evaluate Attendance features without needing administrator intervention.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module. Steps to reproduce: --- - Install ``hr_attendance`` module (without demo data) - Create NEW user >…
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module.
Steps to reproduce:
---
- Install ``hr_attendance`` module (without demo data)
- Create NEW user > Login with new user
- Open ``Attendance`` and Click ``Load Demo Data``
Traceback:
---
```
AccessError
You are not allowed to create 'Resource Working Time' (resource.calendar) records.
This operation is allowed for the following groups:
- Administration/Settings
Contact your administrator to request access if necessary.
ParseError
while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside <record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">
<field name="name">Standard 32 hours/week (4 work days, friday free)</field>
<field name="company_id" eval="False"/>
<field name="hours_per_day">8</field>
<field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {'name': 'Monday Morning', 'dayofweek': '0', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Monday Lunch', 'dayofweek': '0', 'hour_from': 12, 'hour_to': 13, 'day_period': 'lunch'}), (0, 0, {'name': 'Monday Afternoon', 'dayofweek': '0', 'hour_from': 13, 'hour_to': 17, 'day_period': 'afternoon'}), (0, 0, {'name': 'Tuesday Morning', 'dayofweek': '1', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Tu...
ValueError
ParseError('while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside\n<record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">\n <field name="name">Standard 32 hours/week (4 work days, friday free)</field>\n <field name="company_id" eval="False"/>\n <field name="hours_per_day">8</field>\n <field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {\'name\': \'Monday Morning\', \'dayofweek\': \'0\', \'hour_from\': 8, \'hour_to\': 12, \'day_period\': \'morning\'}), (0, 0, {\'name\': \'Monday Lunch\', \'dayofweek\': \'0\', \'hour_from\': 12, \'hour_to\': 13, \'day_period\': \'lunch\'}), (0, 0, {\'name\': \'Monday Afternoon\', \'dayofweek\': \'0\', \'hour_from\': 13, \'hour_to\': 17, \'day_period\': \'afternoon\'}), (0, 0, {\'name\': \'Tuesday Morning\', \'dayofweek\': \'1\', \'hour_from\': 8, \'hour...
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195714This fixes an accounting display issue where cash basis journal item lines could show '/' instead of the actual posted journal entry name. The change ensures related fields are recalculated after the entry number is assigned, so users see accurate journal entry references in accounting lists.
Original PR description
### Issue: In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name. ### Steps to reproduce: - Activate Cash Basis in the accounting…
### Issue: In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name. ### Steps to reproduce: - Activate Cash Basis in the accounting settings - Create a tax with "Tax Exigibility" set "Based on Payment" - Set the "Cash Basis Transition Account" to "Current Assets" - Activate reconciliation on "Current Assets" - Create an invoice with this tax, confirm - In the dashboard, click on Bank and new - Set the name of the invoice as the label, and the amount of the invoice as amount - Save & Close - Go in Accounting > Transactions > Journal Items - The lines created for the cah basis entry display '/' in the column "Journal Entry" ### Cause: This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned. When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`. The callstack is something like this: - `_set_next_sequence()` calls `_locked_increment()` to compute the sequence - `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields - `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()` - `_compute_needed_terms()` needs `invoice_line_ids` - the fetch on `account.move.line` is ordered by `move_name` - So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute` Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`. This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache. ### Solution: Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards. It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`. opw-5056938 Forward-Port-Of: odoo/odoo#225558
This fix ensures cash basis journal item lines show the correct journal entry name instead of a placeholder slash. It helps accounting users see accurate transaction references in Journal Items and adds test coverage to prevent the issue from returning.
Original PR description
This commit adds a test for the [change made in community](https://github.com/odoo/odoo/pull/225558). ### Issue: In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if…
This commit adds a test for the [change made in community](https://github.com/odoo/odoo/pull/225558). ### Issue: In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name. ### Steps to reproduce: - Activate Cash Basis in the accounting settings - Create a tax with "Tax Exigibility" set "Based on Payment" - Set the "Cash Basis Transition Account" to "Current Assets" - Activate reconciliation on "Current Assets" - Create an invoice with this tax, confirm - In the dashboard, click on Bank and new - Set the name of the invoice as the label, and the amount of the invoice as amount - Save & Close - Go in Accounting > Transactions > Journal Items - The lines created for the cah basis entry display '/' in the column "Journal Entry" ### Cause: This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned. When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`. The callstack is something like this: - `_set_next_sequence()` calls `_locked_increment()` to compute the sequence - `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields - `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()` - `_compute_needed_terms()` needs `invoice_line_ids` - the fetch on `account.move.line` is ordered by `move_name` - So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute` Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`. This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache. ### Solution: Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards. It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`. opw-5056938 Forward-Port-Of: odoo/enterprise#94111
Website pages with an SEO cover image could fail to load when a website domain was configured. The fix stores the cover image as a relative link, preventing server errors and keeping shared page previews working reliably.
Original PR description
Scenario: - in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize SEO > Cover Image) - set a domain on the website - go to the page with the cover image Result: an error 500 with this…
Scenario:
- in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize
SEO > Cover Image)
- set a domain on the website
- go to the page with the cover image
Result: an error 500 with this traceback error:
```py
File "addons/website/models/mixins.py", line 92, in get_website_meta
opengraph_meta['og:image'] = url_join(root_url, self.env['ir.http']
._url_for(self.website_meta_og_img or opengraph_meta['og:image']))
File "odoo/tools/urls.py", line 59, in urljoin
raise ValueError("Extra URL must use same scheme and host as base,
and begin with base path")
```
Cause: since 19.0 977e62d91f3e8235e251e9d21b08f53db1856c6b werkzeug
url_join is replaced by odoo urljoin, which requires that the path that
is appended has no host, or the same host. Since the current code saves
the scheme and host of the website_meta_og_img, if the URL is different
than the saved one (because of domain or another reason), we get an
error.
Fix: save a relative URL instead of an absolute one.
opw-5101875
opw-5102079
opw-5105258
opw-5107443
opw-5111474
opw-5112343
opw-5113844
opw-5114544
__Note:__ I rebased on 17.0 since the code has not changed since then, the problem just become visible because of the urljoin change.
__Note:__ I created a upgrade PR to fix the issue for migrated database https://github.com/odoo/upgrade/pull/8494
Forward-Port-Of: odoo/odoo#228253Archiving multiple Helpdesk teams connected to different websites no longer causes an error. This helps administrators manage teams in bulk more reliably when using website helpdesk forms.
Original PR description
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration >…
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration > Websites and create two websites (`W1` and `W2`). - Go to Helpdesk, Configuration > Helpdesk Teams > create two teams (`T1` and `T2`). - Enable the `Website Form` (under `Help Center`), assign `W1` to `T1` and `W2` to `T2`. - Return to the list view, select both teams, and attempt to `archive` them. **Error:** `ValueError: Expected singleton: website(3, 1)` **Root Cause:** At [1], the code incorrectly uses `with_website.website_id.id`, when `multiple websites` are involved, this leads to an `error`. **Fix:** This commit prevents errors and ensures that users can archive multiple helpdesk teams linked to different websites [1]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/website_helpdesk/models/helpdesk.py#L102 sentry-6867906123 Forward-Port-Of: odoo/enterprise#94318
6 changes
Resolved issues and error corrections
The Mexican DIOT report export now places the “exempt imports” and “exempt” values in the correct columns. This prevents confusion or filing issues when businesses download and submit the TXT report, while the underlying calculations remain unchanged.
Original PR description
The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. This Pr changes the order of the columns in the downloadable file (txt) and corrects the tests due to the change. Task-id: 5096808 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95383
This fixes the placement of two exempt-value columns in the Mexican DIOT report. The amounts were already calculated correctly, but the report now shows “exempt imports” and “exempt” in the required positions, reducing filing confusion.
Original PR description
Description of the issue/feature this PR addresses: The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. Current behavior before PR: “exempt” is column 49 “exempt imports” is column 50 Desired behavior after PR is merged: “exempt” is column 50 “exempt imports” is column 49 Task-id: 5096808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228303
This fixes an issue where website pages could show a server error after setting an SEO cover image and configuring a website domain. Cover image links are now stored in a safer relative format, keeping pages accessible when domains differ or change.
Original PR description
Scenario: - in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize SEO > Cover Image) - set a domain on the website - go to the page with the cover image Result: an error 500 with this…
Scenario:
- in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize
SEO > Cover Image)
- set a domain on the website
- go to the page with the cover image
Result: an error 500 with this traceback error:
```py
File "addons/website/models/mixins.py", line 92, in get_website_meta
opengraph_meta['og:image'] = url_join(root_url, self.env['ir.http']
._url_for(self.website_meta_og_img or opengraph_meta['og:image']))
File "odoo/tools/urls.py", line 59, in urljoin
raise ValueError("Extra URL must use same scheme and host as base,
and begin with base path")
```
Cause: since 19.0 977e62d91f3e8235e251e9d21b08f53db1856c6b werkzeug
url_join is replaced by odoo urljoin, which requires that the path that
is appended has no host, or the same host. Since the current code saves
the scheme and host of the website_meta_og_img, if the URL is different
than the saved one (because of domain or another reason), we get an
error.
Fix: save a relative URL instead of an absolute one.
opw-5101875
opw-5102079
opw-5105258
opw-5107443
opw-5111474
opw-5112343
opw-5113844
opw-5114544
__Note:__ I rebased on 17.0 since the code has not changed since then, the problem just become visible because of the urljoin change.
__Note:__ I created a upgrade PR to fix the issue for migrated database https://github.com/odoo/upgrade/pull/8494
Forward-Port-Of: odoo/odoo#228253This fix ensures online shop orders keep the correct pricelist when a shopper signs in or creates an account without an address. It uses the shopper’s GeoIP country during price list selection, preventing customers from being assigned pricing meant for another region.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st…
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st pricelist be incompatible w/ the current GeoIP location; 5. open a cart as a public user; 6. check pricelist in back-end (should be correct); 7. go to "Sign In" & create a new portal account without address; 8. check pricelist in back-end (should still be correct); 9. go back to cart with portal account; 10. check pricelist in back-end. Issue ----- The first pricelist is assigned to the order, which shouldn't be compatibly with the partner's current GeoIP location. Cause ----- The pricelist is recomputed on changing the `partner_id` on a sale order. Commit 6504c0624b990 added a check on the `country_code` context value when retrieving the `property_product_pricelist` for a partner. This context value is currently not getting added during `_compute_pricelist_id`. Because all pricelists are restricted to a country group, when the pricelist gets recomputed on `partner_id` change, there's no location-independent pricelist to fall back on, which is why the first pricelist is used regardless of country restrictions. Solution -------- Add a `_compute_pricelist_id` override which adds the current GeoIP country code to the context when computing the field for website orders. opw-5000198 Forward-Port-Of: odoo/odoo#225582
Support Document Credit Notes in Colombia now consistently use the required internal reference format for product identification. This prevents DIAN validation error NSAZ13 and reduces the risk of rejected documents when products also have barcodes or UNSPSC codes configured.
Original PR description
Before this PR:
- Support Document Credit Notes sent barcode (scheme 010) when available, causing DIAN `NSAZ13` error and document rejection.
After this PR:
- Although a product has all of these 3 fields configured (barcode, UNSPSC, internal reference), still, for a Support Document Credit Note, the `cac:StandardItemIdentification` is always sent with the Internal Reference information ('999', 'Estándar de adopción del contribuyente').
- If internal reference is not configured, then barcode or UNSPSC code is sent with scheme ('999', 'Estándar de adopción del contribuyente').
task-4796034Sale orders now ignore archived projects when deciding whether to show the project shortcut button. This prevents users from seeing a project indicator when only inactive projects are linked, keeping the order view cleaner and less confusing.
Original PR description
Issue: ----- When a project is archived, the project stat button still appears on the sale order. Fix: --------- This commit excludes archived projects from the project count. As a result, the project stat button will be hidden when only archived projects are linked. Steps to reproduce: -------- - Install sale_project module - Create a product with service type, linked to a project and task - Create a sale order with the above product and confirm it - Archive the linked project - Return to the sale order and check the project stat button task-4780817 Forward-Port-Of: odoo/odoo#212730