Saturday, September 27, 2025
9 changes · saas-18.4
Enhancements to existing features
This update makes it easier for other Odoo modules to influence how analytic distributions are prepared for accounting entries. It supports more flexible accounting customizations, such as basing analytic distribution rules on employee-related information, without changing the core accounting behavior.
Original PR description
**Description of the issue/feature this PR addresses:** Add an inherit point to let others modules specify others/new values when the analytic distribution is build on the analytic distribution model. **Functional example:** If you wan to determine your analytic distribution on the employee (so the `employee_id` field is added into `account.analytic.distribution.model`), the specific module can not edit the dict (who is extracted by this PR). So I propose to extract the `dict` creation into a dedicated method. **Current behavior before PR:** It's not possible to edit the `dict` **Desired behavior after PR is merged:** Update the `dict` (and let it as a `frozendict` to use it as a key). ✅ I don't find any duplicates PR --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222661
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