Tuesday, July 29, 2025
30 changes · saas-18.3
Enhancements to existing features
Discuss call tests now automatically skip peer-to-peer checks when the test environment has no network connection. This avoids false failures in automated testing, helping teams keep development pipelines stable without changing the user experience.
Original PR description
This commit adds a skip to peerToPeer tests for when there is no network as the webRTC API needs to have at least a local network to generate ICE candidates. Forward-Port-Of: odoo/odoo#220093 Forward-Port-Of: odoo/odoo#219587
VoIP call sessions are now cleaned up automatically when a call ends, rather than relying on each separate call-ending action to do it. This reduces the chance of leftover session data and helps keep calling behavior consistent for users.
Original PR description
Instead of clean session in every function that can end a call, it's better that we do it when call model state is changed.
The accounting dashboard now prevents users from clicking “Fetch Transactions” multiple times for the same bank. This avoids duplicate requests to bank connection providers, reducing the chance of errors and improving reliability.
Original PR description
The button `Fetch Transactions` shown on a bank in the accounting dashboard can possibly be clicked multiple times in a row by a user. This would cause several calls to the provider causing potential errors. This commit prevents the user from being able to fetch transactions multiple times by removing this button once clicked. task-4900188 Forward-Port-Of: odoo/enterprise#89127
Resolved issues and error corrections
This update corrects a formula mismatch in the POS HR spreadsheet dashboard. It helps ensure dashboard figures are calculated consistently and reduces the risk of misleading reporting for point-of-sale HR metrics.
Original PR description
Task: 4930419 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#217908
Features or functions removed from Odoo
An obsolete internal test that was not part of the normal test process has been removed because it no longer runs correctly. This has no expected impact on users or business workflows, but it reduces maintenance noise for the development team.
Original PR description
`test_parse_inline_template` has never been run "officially" since it's not in a module's test directory, which is where the built-in test harness looks things up. Miraculously it actually worked…
`test_parse_inline_template` has never been run "officially" since it's not in a module's test directory, which is where the built-in test harness looks things up. Miraculously it actually worked still if one managed to get it run (via some other test harness), however with #212315 it's now broken: - #212315 unconditionally looks up the `test_tags` during `__init__` - way back when test tags were added in b356b190338e3ee032b9e3a7f670f76468965006, a default value for test tags was only set on classes defined somewhere within the `odoo.addons` namespace, this was kept on all subsequent updates (even after the `module` was removed from the test tags and moved to a separate attribute) As a result, when running `test_parse_inline_template` the initialisation of each test now fails with an `AttributeError` right in the `__init__`. Can't be arsed to move the test to a place where it's run, and clearly nobody's cared in the last 4 years. Forward-Port-Of: odoo/odoo#220832 Forward-Port-Of: odoo/odoo#220768
Miscellaneous changes
## Issue description: - When 'qty_producing' is updated, the new move takes the MO date_deadline. - The MO date_deadline is the minimum date of all the finished moves date_deadline. - When the SO commitment_date is incremented (+1day), the FNS move date_deadline is updated, but not the BP move one. - The MO date_deadline stay the same (because BP move is a finished move, and BP.date_deadline < FNS.date_deadline) - The new FNS move deadline will not be equal to the existing FNS move deadline
This fix removes pricing-list requirements from point-of-sale loyalty test setup. It helps ensure loyalty program tests can run reliably for deployments using only community apps, reducing false failures in validation.
Original PR description
Since 39b15f1 the pricelists in the loyalty programs creation made them not work if they were only using the community apps. The pricelists were removed from the loyalty program creation so that the tests can be run again. runbot-229672
This fix makes an automated mail test stable by removing timing-sensitive checks around repeated message edits. It helps keep Odoo's validation pipeline reliable without changing normal user-facing behavior.
Original PR description
Before this commit, the "Can edit message comment in chatter" test could fail intermittently. The test performs three edits on the same message, and due to the asynchronous nature of the bus (mock server > websocket > worker bus service > subscribers), bus notification are received later than rpc results. The test was asserting composer content between edits, which is unnecessary and sensitive to race conditions. For example: - First edit is sent. - Second edit is sent. - First edit is received. - Third edit opens the composer with outdated content. This is unlikely to occur in practice. This commit resolves the issue by removing non essential composer assertions. fixes runbot-227618 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#220389
Analytic entries created from split invoice lines now add up exactly to the original invoice line amount. This prevents small rounding differences, such as one cent discrepancies, from appearing in accounting analytics reports.
Original PR description
**PROBLEM** Sometimes, the sum of the generated analytic lines for an invoice line doesn't equal the amount on the invoice line. For example, in invoice line with a price of 182.25, with an analytic…
**PROBLEM** Sometimes, the sum of the generated analytic lines for an invoice line doesn't equal the amount on the invoice line. For example, in invoice line with a price of 182.25, with an analytic distribution split into 98% and 2%, the generated analytic lines amount to 182.26 (off by 0.01) because of rounding. **STEP TO REPRODUCE** 1. install the accounting module and enable the Analytical Accounting option. 2. create an invoice, with a line with a price of 182.25, and a distribution of 98%/2%. 3. confirm the invoice. 4. go to Accounting/Analytics Items and notice the sum of analytical line is 182.26 instead of 182.25. **CAUSE** We only apply rounding after having calculated all the analytic line amounts. This mean we will sum the rounding error. In our example, the computation is like so: 98% of 182.25 = 178.605 rounded to 178.61 2% of 182.25 = 3.645 rounded to 3.65 178.61 + 3.65 = 182.26 **FIX** We compute the last analytic line for each plan, relatively to the other. `last_line_amount = invoice_price - sum(rounded_other_line_amount)` This ensure that the sum of analytic lines is always equal to the invoice price. opw-4848784 Forward-Port-Of: odoo/odoo#220614 Forward-Port-Of: odoo/odoo#214736
Event registrations purchased and paid through Point of Sale now stay in the same “Registered” status as registrations bought through the website. This prevents paid PoS registrations from being incorrectly marked as already attended, improving consistency in attendee tracking.
Original PR description
Before this commit, if we buy an event registration from PoS and pay for it, its state will be 'done', i.e. "Attended" [1]. While if we buy the registration from the website and pay for it, its state is 'open', i.e. "Registered" [2]. We want the state of the registration to be 'open' when we buy it. After this commit, we set the state of events bought from PoS to 'open' as well, matching the case where we buy them from the website. [1]: https://github.com/odoo/odoo/blob/c3ae4b29c51c7b0cff11aac5f4bf4aab5fad16c9/addons/pos_event_sale/models/event_registration.py#L14 [2]: https://github.com/odoo/odoo/blob/c3ae4b29c51c7b0cff11aac5f4bf4aab5fad16c9/addons/event_sale/models/event_registration.py#L40 opw-4920574 Forward-Port-Of: odoo/odoo#219622
This fix prevents an error when creating an Analytic Distribution while multiple companies are selected and one company has no fiscal localization configured. It helps accounting users continue setup work without crashes in multi-company environments.
Original PR description
Currently, an error occurs when a new company is created without selecting a `Fiscal Localization`, and then both companies are selected while creating a new `Analytic Distribution`. Steps to…
Currently, an error occurs when a new company is created without selecting a `Fiscal Localization`, and then both companies are selected while creating a new `Analytic Distribution`. Steps to reproduce: --- - Install `Accounting` module(without demo) - Enable `Analytic Accounting` - Create a New company and switch to it - Select both companies and Open `Analytic Distribution` and click `New` Traceback: --- `TypeError: 'bool' object is not subscriptable` At [1], we are searching by `account_type`, but if `Fiscal Localization` is not set for the current company, there will be no records in `account.account`. However, due to the multi-company setup, it still return accounts from the first company. In such cases, the `code` field is empty, which causes the `code` to be treated as False. [1]: https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/account/models/account_analytic_distribution_model.py#L55-L58 sentry-6754820454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220089
This change makes an internal website test wait until an image is fully loaded before checking it. This reduces random test failures and helps keep releases more stable without changing customer-facing behavior.
Original PR description
The goal of this commit is to avoid potential undeterminism that could occur in the `drop_404_ir_attachment_url` test (introduced by [this commit]). Before this commit, an error was thrown if the image was not loaded at the time the test checks the `naturalWidth` and `naturalHeight` property of the image. This could lead to undeterministic error as nothing ensures that the image is loaded at that time. To solve the problem this commit first waits for the image to be loaded before accessing the `naturalWidth` and `naturalHeight` property of the image. Side note: even if the source of the image is of type `data:` it is not directly loaded. [this commit]: https://github.com/odoo/odoo/commit/fbc6a697c1adf67ee8a90c49b0150d6ca170e081 task-4931144 Forward-Port-Of: odoo/odoo#220204 Forward-Port-Of: odoo/odoo#217968
This fixes a display issue on eCommerce product pages where promotional ribbons could shift away from the product image when the browser zoom level changed. The ribbon now remains correctly positioned, preserving a polished shopping experience.
Original PR description
<b>Steps to Reproduce:</b> 1. Install Sales and eCommerce modules. 2. Go to Sales → Products, open any product, go to Sales tab, and set a Ribbon. 3. Navigate to Website → Shop, search for the…
<b>Steps to Reproduce:</b> 1. Install Sales and eCommerce modules. 2. Go to Sales → Products, open any product, go to Sales tab, and set a Ribbon. 3. Navigate to Website → Shop, search for the product and open its page. 4. Zoom in or out. <b>Issue:</b> - The ribbon on the product image becomes misaligned (shifts away from the image) when zooming in or out on the product detail page. This results in a broken visual layout. <b>Cause:</b> - A previous change in [PR #175473](https://github.com/odoo/odoo/pull/175473) unintentionally replaced the height class (h-100) with width (w-100) on ribbon container, causing layout instability during zoom operations. <b>Solution:</b> - Restore the proper layout by reintroducing h-100 to both the ribbon container and inner image div. This ensures the ribbon stays correctly positioned relative to the image regardless of zoom level. <b>opw-4854217</b> <b>Before FIX :</b>  <b>After FIX:</b>  Forward-Port-Of: odoo/odoo#216545
This fix makes mail conversation loading more consistent by avoiding an error when a conversation is missing and applying the same behavior whether data is already loaded or fetched from the server. This reduces the chance of unexpected failures when users open or access discussions.
Original PR description
1. Ensure the thread is not undefined before calling exists. 2. `hasReadAccess` was only checked after the RPC, but if the thread data was already fetched the condition was not checked. The choice is made to remove the condition as it makes the code more flexible. The caller can always decide to check `hasReadAccess` afterwards if necessary. How to reproduce: https://github.com/odoo/odoo/pull/220605 Forward-Port-Of: odoo/odoo#220782
This fix prevents an error when users edit a website button and change it into a regular link. The editor now correctly hides button-specific controls once the element is no longer a button, making saving the page work as expected.
Original PR description
Problem: Saving the button snippet after changing its type to a link throws an error because `snippet_key` is `undefined`. Cause: The button snippet editor should be disabled if the button is changed…
Problem: Saving the button snippet after changing its type to a link throws an error because `snippet_key` is `undefined`. Cause: The button snippet editor should be disabled if the button is changed to a link. However, `updateOptionsUIVisibility` is only triggered on click events. In this case, the element type changes through the editor itself, not by clicking, so the UI isn't updated accordingly. Solution: Trigger a `click` event on the link element programmatically to call `updateOptionsUIVisibility` and hide the button snippet editor when the element is no longer a button. Steps to reproduce: - Drop a button snippet - Click inside the button to edit - Notice the Button snippet editor appears - Change the type to "Link" instead of "Primary" - The Button snippet editor is still visible - Click the floppy disk icon (save) in the snippet editor -> A traceback occurs opw-4936796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220787 Forward-Port-Of: odoo/odoo#219660
This fixes an issue in Discuss calls where denying camera permission after leaving a call could trigger an error. The change makes call handling more reliable when users leave before camera access finishes processing.
Original PR description
Before this commit, a traceback would occur of the camera access was rejected after leaving a call that requested it. This race condition could also happen in other cases where the call is left before the camera promise resolves. Forward-Port-Of: odoo/odoo#220770
Agents now only see a warning about ending a live chat when the conversation is still active. This avoids confusing alerts after a live chat has already finished, making the support workflow clearer.
Original PR description
Before this PR, when leaving a live chat from the discuss sidebar action as an agent, the user was always getting a warning that this action would end the livechat, even when the livechat has already ended! task-4926337
This fixes an internal live chat automated test so it waits until changes are fully saved before finishing. It helps prevent false test failures and reduces the risk of inconsistent background activity during quality checks.
Original PR description
Tour "test_chatbot_clear_answers_on_step_type_change" could fail with following error before this commit: ``` Tour finished with a dirty form view being open. Dirty form views are automatically saved when the page is closed, which leads to stray network requests and inconsistencies. ``` The tour was saving the changes to form view but was not awaiting a trigger when the form is saved, thus the tour could end and still see form is dirty. This commit replaces `.o_form_view` to `.o_form_saved` for awaiting the form is fully saved and not dirty at end of test tour. Fixes runbot error 230296
Shared Helpdesk ticket links now show the logo and branding of the company that owns the ticket, even when opened by someone who is not logged in. This prevents customers from seeing the wrong company identity on portal pages in multi-company setups.
Original PR description
**Steps to reproduce**: 1. Install `helpdesk` only 2. Create a second company and configure a distinct logo for both the default and new companies. 3. Create a Helpdesk ticket under the new company.…
**Steps to reproduce**: 1. Install `helpdesk` only 2. Create a second company and configure a distinct logo for both the default and new companies. 3. Create a Helpdesk ticket under the new company. 4. Use the 'Share Ticket' (gear icon) feature to generate a portal link. 5. Open the link in an incognito window or a different browser (where no user is logged in). 6. Observe the logo shown in the portal navigation bar. **Observed behavior**: The portal incorrectly displays the logo and branding of the default/main company, even when the Helpdesk ticket belongs to a different company. **Issue**: When no portal user is logged in, the `res_company` used in the portal rendering context defaults to the system’s primary company (`env.company`). The template expects `res_company` to be explicitly set to reflect correct branding. See: https://github.com/odoo/odoo/blob/880954ebfc1106411b7f7a7d60aee05dfae60893/odoo/addons/base/models/ir_qweb.py#L781 **Solution**: Explicitly pass `ticket_sudo.company_id` as `res_company` in the portal view context to ensure correct company branding is used. opw-4855281 Forward-Port-Of: odoo/enterprise#90600
This fixes how Indian GST return periods are calculated after a previous change to quarter handling. Reports will now use the correct month for quarterly return periods, helping avoid incorrect period labels in tax reporting.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/75b72df06a109b5e89a2c8e98bc29a1fe120fb68, the quarters key was updated. Previously, it used the start month of the quarter, but it now uses the end month instead. However, the `return_period_month_year` field is still being computed based on the start month. With this PR, the `return_period_month_year` will now be computed correctly based on the updated logic. **opw**-4970000
This fix ensures Dutch tax report submissions correctly handle cases where more than one closing entry exists for a return. Users are now warned only when at least one related closing entry is still in draft, reducing incorrect warnings and helping prevent submission issues.
Original PR description
Before this commit: As multiple closing moves can exist for a return, the check for the state of the closing move was incorrect. It was assuming only one closing move exists, which could lead to issues if multiple closing moves were present. After this commit: The code now checks if any of the closing moves are in 'draft' state before raising a warning. opw-4976827
Sign reminders now handle requests that do not have a “Valid Until” date set. This prevents the scheduled reminder process from crashing, so reminder emails can continue to be processed reliably.
Original PR description
When a `sign.request` record has `validity` as `False`, attempting to send a reminder via the `_cron_reminder` method leads to a crash. **Steps to Reproduce:-** 1. Install the `Sign` module. 2.…
When a `sign.request` record has `validity` as `False`, attempting to send a reminder via the `_cron_reminder` method leads to a crash.
**Steps to Reproduce:-**
1. Install the `Sign` module.
2. Navigate to the Sign section and click on `Upload PDF & Sign`
3. Upload any PDF document and add your signature, then click `Send`
4. In the new wizard, remove the value for `Valid Until` and enable the `reminder` option. Set the reminder to `every 1 day.`
5. When our scheduled action named `Sign: Send Mail Reminder` executes the following day, it will throw an error.
**Error:-**
`TypeError(''<' not supported between instances of 'bool' and 'datetime.date'') while evaluating 'model._cron_reminder()''`
**Root Cause:-**
The SQL query within the `_cron_reminder()` method retrieves all records where:
- The request is `active` and in the `sent` state.
- Either:
- `validity < today` or
- A reminder is due based on `last_reminder + reminder`.
The fetched records are then iterated through at [1].
[1]
https://github.com/odoo/enterprise/blob/ac4aeeea98dcf2fc7f06e6a3fabc55e256330e2c/sign/models/sign_request.py#L454
If `validity` is `False`, this comparison raises a `TypeError` because it is invalid to compare a `boolean` with `datetime.date`.
**Solution:-**
- A safety check was added before the comparison between `request.validity` and today's date, ensuring that `request.validity` exists.
Sentry-6727599497
Forward-Port-Of: odoo/enterprise#89646The optional columns menu no longer shows the “Add custom field” button when users view bank statement lines. This prevents users from trying to customize a reconciliation-related view where custom field creation is not supported, reducing confusion in Accounting workflows.
Original PR description
`Add custom field` button shouldn't be displayed with `account.bank.statement.line` model. Since c6ade2de937a30a13620a64a4779ebd827088755, we use an action to open the bank reconciliation widget, therefore in the `computeStudioEditable` method, we didn't pass in the first condition `!action.xml_id` anymore and we were returning `true`. With this commit, we return `false` if model is `account.bank.statement.line`. Steps: - Install `accountant` - Go to Accounting dashboard - Click on the `Bank` card title - Toggle the list view - Open the optional columns dropdown -> The `Add custome field` button is displayed opw-4953156 Forward-Port-Of: odoo/enterprise#90935
This update removes leftover code from a previous reconciliation workflow cleanup. It helps keep the accounting-related payment and sales features simpler and reduces the risk of confusion or unexpected maintenance issues.
Original PR description
In this commit: https://github.com/odoo/enterprise/pull/80787/commits/04a304d58a56c7d2eeb70429340eb048fa9f2be6 We refactored the reconciliation model to be easier to use for users. However, by doing the refactor we forgot to remove some code. no task id
The Accounting dashboard's "To Check" link now correctly opens only bank transactions that still need review. This prevents already-checked transactions from cluttering the list, helping accountants focus on pending work.
Original PR description
**Issue** When accessing bank transactions via the "To check" link in the Accounting dashboard, the expected filter to show only unchecked transactions is not applied. As a result, all transactions are displayed, including those that have already been checked. **Steps to Reproduce** 1. Navigate to Accounting > Dashboard > Bank 2. Create two bank statement lines: one marked as checked, the other unchecked 3. Return to the dashboard 4. Click the “1 To Check” link 5. Observe that both entries are shown, instead of only the unchecked one **Root Cause** The corresponding filter (`to_check`) is missing from the search view of the `account.bank.statement.line model`. Although the action context correctly includes `search_default_to_check=True`, Odoo is unable to apply the filter without a matching `<filter name="to_check" ... />` in the search view definition. Opw-4945705
Payroll payment reports now use the company linked to the payslip batch instead of the company currently selected by the user. This prevents confusion when working with multiple companies and helps ensure payroll payment documents show the correct business entity.
Original PR description
Steps to reproduce: - install payroll and create a batch - generate payslips - select multiple companies. - Click on "Create Payment Report." - create any payment method issue: - The report displays the currently selected company instead of the one associated with the payslip batch. reason - the default company is given on the field which is self.env.company fix - now the company field is computed to the payslip company task-4643306 Forward-Port-Of: odoo/enterprise#81812
The Tax Return periodicity setting now automatically selects the dedicated Tax Return miscellaneous journal. This prevents users from being blocked when saving the setting because a required journal field was empty.
Original PR description
Before this commit: - The "Journal" field in the Tax Return periodicity setting was required but left empty by default, making it impossible to save the settings change without manually selecting a journal. After this commit: - The "Tax Return" miscellaneous journal is automatically set as the default in the Tax Return Periodicity setting. task-4938896
Installing Accounting after Point of Sale now correctly creates or assigns the default Tax Returns journal. This prevents missing tax return journal settings and helps ensure tax configuration is ready to use after installation.
Original PR description
To reproduce: ============= 1- install point of sale 2- install account => check taxes in the setting, journal item is not set Problem: ======== The accounting journal was not being set when the accounting module was installed. The tax return journal field (`account_tax_return_journal_id`) remained unset Solution: ========= if Tax Returns doesn't exist we will create it and assign it as default as accountChart is working. https://github.com/odoo/enterprise/blob/saas-18.3/accountant/models/chart_template.py#L10-L30 opw-4950538
Original PR description
## Issue description: - When 'qty_producing' is updated, the new move takes the MO date_deadline. - The MO date_deadline is the minimum date of all the finished moves date_deadline. - When the SO…
## Issue description:
- When 'qty_producing' is updated, the new move takes the MO date_deadline.
- The MO date_deadline is the minimum date of all the finished moves date_deadline.
- When the SO commitment_date is incremented (+1day), the FNS move date_deadline is updated, but not the BP move one.
- The MO date_deadline stay the same (because BP move is a finished move, and BP.date_deadline < FNS.date_deadline)
- The new FNS move deadline will not be equal to the existing FNS move deadline
- The merge is blocked
## How to reproduce:
- Enable By-Products in setting
- Unarchive MTO route
- Create storable products FNS, CMP and BP
- Set FNS route: Manufacture and MTO
- Create BoM:
- Producing: 1 of FNS
- Component: 1 of CMP
- By-Product: 1 of BP
- Create Sale Order for 1 unit of FNS ⇾ Confirm
- Set Delivery Date to 1 day in the future (date must be incremented)
- Go to MO, set quantity producing to 2
- => 2 Finished move for FNS exists; the merge was not done due to a discrepancy in 'date_deadline'
- Click "Produce All"
- !! Singleton Error
## Fix:
On date_deadline change: propagate deadline to sibling FNS moves
OPW-4671555
---
## Test result without fix:
```
2025-06-03 11:54:54,076 37053 ERROR oes_test_17 odoo.addons.sale_mrp.tests.test_sale_mrp_flow: FAIL: TestSaleMrpFlow.test_date_deadline_propagation
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/sale_mrp/tests/test_sale_mrp_flow.py", line 2624, in test_date_deadline_propagation
self.assertEqual(len(fns_move), 1)
AssertionError: 2 != 1
```
## Test result without fix and the asserts on finished moves removed (to reach 'button_mark_done'):
```
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/sale_mrp/tests/test_sale_mrp_flow.py", line 2622, in test_date_deadline_propagation
mo.button_mark_done()
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/models/mrp_production.py", line 2014, in button_mark_done
productions_not_to_backorder._post_inventory(cancel_backorder=True)
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/models/mrp_production.py", line 1723, in _post_inventory
order._cal_price(moves_to_do_by_order[order.id])
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp_account/models/mrp_production.py", line 89, in _cal_price
finished_move.ensure_one()
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/odoo/models.py", line 5899, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: stock.move(8252, 8255)
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#213256
Forward-Port-Of: odoo/odoo#212718