Friday, October 10, 2025
3 changes · saas-18.2
Resolved issues and error corrections
Cash basis journal item lines now keep the proper journal entry name instead of showing '/'. This prevents confusing accounting lists after payments are reconciled and helps users identify posted entries correctly.
Original PR description
This is the backport of https://github.com/odoo/enterprise/pull/94111/commits/e379cf04cc1aa97d28d73566daadad193310ae9a Issue: In the list view of Journal Items, cash basis lines show a `move_name` of…
This is the backport of https://github.com/odoo/enterprise/pull/94111/commits/e379cf04cc1aa97d28d73566daadad193310ae9a 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`. Community PR - https://github.com/odoo/odoo/pull/230751 opw-4747878 Forward-Port-Of: odoo/enterprise#96721
Appointments now create video call links using the website tied to the appointment type. This prevents customers on multi-website setups from receiving links with the wrong domain, improving reliability for online meetings.
Original PR description
**Steps to reproduce:** - Create 2 companies - Create a website for each company - Set a custom website domain on the second one - Create appointement type for each website - Create an appointement on both websites - The link created for the video call has the wrong base for one of them **Issue:** Appointment `get_base_url` finds its base_url without considering the current website. **Fix:** Compute the base_url according to the appointement type to ensure the current website is taken into account. opw-4880715 Forward-Port-Of: odoo/enterprise#92734
Colombian online checkout could get stuck when customers selected an obligation type whose internal code had more than one digit. The fix lets the address form save correctly and continue to the delivery step, reducing checkout interruptions for Colombian websites.
Original PR description
Problem: When there is an obligation type code with id greater than 9, and it is selected in the dropdown of the website sale address form for obligation type, the screen keeps loading forever and…
Problem: When there is an obligation type code with id greater than 9, and it is selected in the dropdown of the website sale address form for obligation type, the screen keeps loading forever and there is an “expected singleton” traceback in the logs. This is because in the method `_parse_form_data` in `l10n_co_website_sale`, the obligation type field on `form_data` is set to be a list of “type ids” which leads to an error when `convert_to_cache` is called as the browse function in this attempts to convert the list to a tuple of single characters. For example, if the list is ["10"], it gets converted to ("1","0") hence leading to the expected singleton traceback.
Purpose: Instead of passing a form list to form_data,we pass the record set which will correctly set the values in the address, much like how `default_obligations_ids` is also currently set. After this correction, the website address screen will save the address properly and redirect to the delivery screen for further actions.
Steps to Reproduce on Runbot:
1. Create a Colombian company, make sure l10n_co is installed
2. Set the company on the website to this company
3. Ensure that there is a record in the table `l10n_co_edi_obligation_type_ids` with id > 9. Create one if it does not exist.
4. Open the /shop page in incognito mode as a public user.
5. Add a product, go to the checkout page, proceed to the address page.
6. Enter all the information including the Identification Number (e.g. 623.456.789-1). Choose “NIT” in identification type and select the type code from step 3 in the dropdown for obligation type. Choose country “Colombia” along with a state and city
7. Click on "Continue checkout". The page gets stuck in a loading state
forever.
opw-4776301
Forward-Port-Of: odoo/enterprise#90862