Tuesday, July 29, 2025
23 changes · saas-18.3
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
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