Daily updates from Odoo
Monday, June 30, 2025
30 changes · 18.0
Resolved issues and error corrections
This fixes how employee online status lists are combined in Time Off, replacing behavior that only worked accidentally. It reduces the risk of incorrect availability checks when showing or using employee presence information.
Original PR description
PR above made a typo in code in which list of "online" member IM status is a list of string, and it uses + to concatenate items like in python but this doesn't work in JS. Thankfully it kinda "worked" because this casted the array into list (e.g. `["a", "b"]` becomes "a,b") and other items were appended to string. Since this list was used for `.includes()` by chance the ".includes()" method is on Array and String and functionally this results to about the same intention... Again by chance! Forward-Port-Of: odoo/odoo#216598
This fixes Spanish SII reporting so credit notes identify OSS taxes using the correct refund tax information instead of invoice tax information. It helps ensure refunds are reported accurately and reduces the risk of incorrect tax data being sent.
Original PR description
Before this commit, the method _has_oss_taxes was determining whether a tax is OSS based on the tax_ids.invoice_repartition_line_ids.tag_ids This works fine for invoices, but for credit notes it should be based on tax_ids.refund_repartition_line_ids.tag_ids This commit solves this issue followup of: https://github.com/odoo/odoo/pull/215614 task-4548095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216603 Forward-Port-Of: odoo/odoo#216543
The mail message composer now keeps a consistent height when empty in Chromium-based browsers. This prevents the input box from visibly resizing as users begin typing, making messaging feel smoother and more polished.
Original PR description
Before this commit, composer height was too small when it had no content. This lead to composer changing height when typing some characters which looks off. This bug is specific to Chromium browsers and seems to be new since Chrome 138.0. The code expected that textarea had unchanged scrollheight when textarea has height 0 and fits its content in at most 1 line, but this seems to have changed with Chrome 138.0. This commit fixes the issue by cheating when composer is empty: the fake textarea artificially adds a character so that the computation for height when empty works as if it has 1 character, thus the computed height is the same when there are few characters in composer.
New Argentine companies will now start with the more commonly used Responsable Inscripto chart of accounts instead of the less common Monotributista option. This reduces incorrect default accounting setup for most Argentine businesses and aligns automatic setup with typical usage.
Original PR description
### Description of the issue/feature this PR addresses: Odoo will try to auto install a Coa when creating a database or creating a new company where country is defined The problem is that in Argentina we have different CoA depending on the AFIP Responsibility, and the one that is currently installed by default is the 'ar_base' (Responsable Monotributista): the less used one. In this case we prefer to do not install any CoA and let the user to install it manually (as it was working in older versions, but it is not possible). For that reason we made this change force to install 'ar_ri' (Responsable Inscripto) CoA by default instead ### Current behavior before PR: 1. Create a new company with country AR 2. Will automatically install the "Responsable Monotributista" Coa ### Desired behavior after PR is merged: Now will install the "Responsable Inscripto" Coa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a visual issue on invoice forms where an empty section could leave an odd line and extra spacing beside invoice amounts. The invoice screen now hides that whole section when it is not relevant, making the layout cleaner for draft invoices or invoices without outstanding items.
Original PR description
Repro steps: Navigate to the form view of an invoice that is either 1. not posted 2. does not have outstanding debits/credits Problem spotted: next to the invoice amounts, a weird line and margin to the right can be seen Cause: The field invoice_outstanding_credits_debits_widget of an invoice may be invisible with this condition invisible="state != 'posted' or not invoice_has_outstanding" and in that case, it's containing group would still be visible (showing the aforementioned margin). Fix: This commit fixes this issue by moving the invisible condition to the group containing the field invoice_outstanding_credits_debits_widget instead of the condition being on the field itself. task-4882509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change reverts recent shortcut naming in the web testing library that could cause some databases to show a blank screen with a browser error. It helps restore normal loading while the underlying asset generation issue is investigated separately.
Original PR description
**What's the issue?** On multiple database instances, there is a blank screen appearing with a console error: unknown token 'export' **Why is it happening?** While the exact reason is still unknown,…
**What's the issue?** On multiple database instances, there is a blank screen appearing with a console error: unknown token 'export' **Why is it happening?** While the exact reason is still unknown, here are the main cuplrits: [this first commit](<https://github.com/odoo/odoo/pull/213223/commits/d4c7e7abbde31806a49d4cdba340cd238eb9130b>) and [this second commit](<https://github.com/odoo/odoo/pull/213223/commits/f7426b366431ebc6266113700eeb3821e9e6a884>). The first commit adds support for '$' characters in JS variable names, while the second takes advantage of that feature to declare short-hand aliases for the Hoot-DOM library. The issue is caused because the aliases from the second commit seem to have been applied to the static assets (and it also seems that they have been correctly transpiled by the server), but for some reason the transpiler still doesn't support '$' characters and ignores the added export statements. Database server code has been verified as having the correct version of the transpiler code, but the resulting static assets still present this issue. **What can be done?** This PR should fix the issue, as it effectively reverts changes on the second commit. The first commit has not been reverted (yet), as the cause of the issue is still unknown, and the damage need to be mitigated as quickly as possible. A temporary fix while the revert arrives in stable is to head to the crashing DB in `debug=assets` mode, to head to the debug menu (Bug icon) and to `"Regenerate Assets"`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an automated website payment donation test so it handles the payment confirmation redirect reliably. It helps keep donation-related website checks stable and reduces false test failures during quality assurance.
Original PR description
In this commit, we fix the donation_snippet_use tour. At the end of the tour, when you click on submit donation, you are redirected to a page "Your payment has been processed." From this page, you are then redirected to a page with "Thank you". This intermediate redirection page can be a problem if there are several steps that concern it because we do not know when the redirection will be triggered (in the first or the second step?) Therefore, it is essential to have only one step for intermediate redirections. 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
Error dialogs in debug mode no longer show an unrelated internal request ID as if it were a record ID. This avoids misleading information when users or support teams review crash details for server actions.
Original PR description
Steps: - Enable debug mode - Go to server actions - Create a server action that crashes with `Execute code` - Example -> "a" (will crash because `a` is undefined) - Traceback will contains an invalid ID `Occured on odoo180 on model ir.actions.server and id 19 on 2025-06-30 09:20:48 GMT` This was an error and this ID is not linked with the model, it is the rpc id, so it should not be on the traceback. This commit remove this id to have something like this `Occured on odoo180 on model ir.actions.server on 2025-06-30 09:20:48 GMT` opw-4816514
Saudi and GCC invoice reports now show the regular invoice date separately from the Saudi confirmation date, reducing confusion for backdated invoices. The issue date is also consistently shown using Saudi Arabia time, regardless of the customer's location.
Original PR description
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will display both the standard invoice date and l10n_sa_confirmation_date separately for clarity. The issue date will always be passed in SA timezone to the report to ensure consistency, regardless of the partner's country. task-4508551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Spanish SII electronic invoicing integration now identifies OSS taxes using tax tags instead of relying only on predefined system records. This ensures custom OSS taxes created by users are correctly recognized, reducing reporting errors for cross-border EU sales.
Original PR description
This commit fixes the search for OSS taxes in `_has_oss_taxes` function. The current search approach (with tax tags) is better in the following points: 1. No need to use `sudo` for ir.model.data access 2. Currently, user-created OSS taxes are considered in the search task-4548095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216375 Forward-Port-Of: odoo/odoo#215614
This change restores the previous behavior of an automated test for creating project sales order lines. It helps keep quality checks stable so future updates to sales-project workflows can be validated reliably.
Original PR description
This reverts commit bde64f4dd19d30f807142fea6f04409de0696c54. runbot-error-226711
The emoji picker now keeps focus when a user selects an emoji category, so keyboard navigation continues to work as expected. This makes emoji selection smoother and more accessible for users who rely on keyboard controls.
Original PR description
Before this PR, the keyboard navigation capability was lost after clicking on a category. This PR adds a tabindex to avoid losing focus on the emoji picker.
Helpdesk tickets will no longer be closed when automated email scanners check links in customer emails. Only an intentional visit to the close-ticket link will trigger closure, reducing accidental ticket closures and support disruption.
Original PR description
Currently some customers with email scanners will have their ticket closed soon after it's opened. Steps to reproduce ----- 1. Enable "Closure by Customers" on the helpdesk team 2. Create a new ticket 3. Send a HEAD request to the "Close ticket" link in the received email, using `curl -I <url>` 4. The ticket gets closed Cause ----- Some email scanners send HEAD requests to links contained in emails, which is incorrectly interpreted as a user action. Fix ----- Implement a check so that only GET requests to the route will close the ticket. opw-4837167 Forward-Port-Of: odoo/enterprise#88547
A payroll expense process was pointing to the wrong type of record, which could cause incorrect handling of expense sheets linked to payslips. This fix ensures expense sheets are referenced correctly, improving reliability for payroll-related expense workflows.
Original PR description
this commit fixes wrong reference to `hr.payslip`. `payslip_sheets` should be a recordset of `hr.expense.sheet` and not `hr.payslip`.
Fixed an issue where the timer could briefly use outdated information after start or pause actions, causing an incorrect time calculation. This helps users see a more reliable timer value and avoids large discrepancies in tracked time.
Original PR description
Before this change, onRecordChange listens to changes on the record for timer_start and timer_pause to drive the timer, depending on whether timer_pause was present on the record. However, since record is a proxy object that also subscribes to changes when its data is read, onRecordChange fires twice, once with the *previous* state and once with the updated data. On the first call, timer_pause would have the data from the previous button call, but by that point timer_pause is already in the past and forces a recalculation of the timer's server offset, causing a large discrepancy. This commit changes onRecordChange to use the second parameter nextProps instead, which bypasses the record from subscribing the callback for the outdated data. opw-4658402
This update fixes a translation-related error that could occur when referral links or loan information were processed in different languages. It improves reliability for multilingual users without changing business workflows or features.
Original PR description
Issue: Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. Fix: Replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-98198
This fix prevents an error when users edit payslip lines through the payroll wizard. Payroll staff can update payslip details more reliably without being blocked by an unintended record creation issue.
Original PR description
In this PR we add edit_payslip_lines_wizard_id in the view to prevent a new line record creation error. Forward-Port-Of: odoo/enterprise#88033
A test counter in the Mail Enterprise test suite was corrected to better reflect expected activity behavior. This helps keep automated quality checks reliable and reduces the chance of false failures during development.
This update fixes the conditions used to apply payroll subsidy rules in Mexican payroll. It helps ensure employee payslips calculate the subsidy correctly, reducing payroll errors and manual corrections.
Original PR description
task-4690544
Mexican payroll can now generate payslips for employees who only have variable income, such as commissions or bonuses, and no fixed base salary. This prevents a payroll processing error and helps ensure affected employees can be paid correctly.
Original PR description
BUG An error is raised when trying to generate a payslip for an employee with only variable income (e.g., commissions/bonuses, no fixed base salary) FIX The rule's find_index function needs to return 0 instead of None in case the daily_wage does not fall within any of the measure ranges Task: 4723413
Fixes an error that could block users when adding a rental product with variants during subscription renewal. The system now only processes rental dates when they are actually available, keeping the renewal flow usable before confirmation.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a rental product with multiple variants; 2. create a subscription order via the Rental app; 3. add the rental product; 4. confirm & invoice the subscription; 5. renew the subscription; 6. add the rental product to the renewal. Issue ----- > `Uncaught Promise > value.setZone is not a function` Cause ----- Commit 76526bdb3835 implemented the `_getAdditionalDialogProps` method for using OWL in the product configurator. In our flow, it simply checks whether the order is a rental order, and if so, it attempts to serialize its rental dates. Issue is that rental dates are not a required field as long as the order hasn't been confirmed yet, causing the traceback. Solution -------- Instead of checking whether it is a rental order, verify that the order has rental dates before attempting to serialize them. opw-4898437
This update fixes an issue in the Belgian salary contract offer process. It helps ensure salary offers are handled more reliably for HR teams using the Belgian localization.
The employee document smart button now shows only documents the user can actually access. This avoids confusing count mismatches and gives users a more reliable view of available HR documents.
Original PR description
Previously the smartbutton showed the number of documents the user was a contact of, without checking if the user had access to such documents or not, resulting in sometimes different values Task: 4771754
The Journal Report now shows the account name in the Account column, making entries easier to identify and review. This fixes a visibility issue so business users can better understand accounting report lines without relying only on account codes.
Original PR description
The purpose of this pr is to add account name in the Account column of the Journal Report. Before this code changes:  After this code changes:  OPW : 4702276
Odoo Studio now uses each field's official capabilities to decide whether it can be grouped, sorted, or aggregated instead of relying on less reliable guesses. This makes view editing more accurate and helps prevent users from being offered options that do not work well for a given field.
Original PR description
Before this commit we used some heuristics in studio to determine whther some field had some ability (groupable, sortable, aggregator) After this commit, we use the not so new tools given by https://github.com/odoo/odoo/commit/b177b058be1531c3d2af2b591c22591c19240d33 Note that we still rely on the field type, because even if possible, groupong by some fields doesn't make much sense (eg.: float) task-4879382
The Partner Ledger partner filter has been corrected so companies are no longer missing from the dropdown when they have a parent company. This helps users select the right partners for reporting and avoids incomplete filtering options.
Original PR description
Steps to reproduce - create a company - add a contact to this company - go to its contact form and transform this contact from Individual to Company - go to the Partner Ledger - open Partner filtering dropdown list Current behavior - show company and individual with no parent Expected behavior - show individual with no parents and all the companies - Company with parent company seems to be the expected behavior since 2016. If there is one, the Parent company appear in the contact form as defined [there](https://github.com/odoo/odoo/blob/9b03d99fd0174bd67c8ea30e5fd2c26fb2ad2467/odoo/addons/base/views/res_partner_views.xml#L168) opw-4729020
The Helpdesk menu now only shows teams assigned to the website a visitor is using. This prevents teams from other websites appearing in the wrong place, reducing confusion for customers and staff.
Original PR description
**Steps to Reproduce:** 1. Install the website_helpdesk module. 2. Create a Helpdesk Team A with 'Website Form' enabled, and set the website to 'My website' 3. Create another Helpdesk Team B with 'Website Form' enabled, and Set website to 'My website2' 4. Navigate to Website → Help menu on "My Website". **Observation:** - Both Helpdesk teams appear on "My Website", even though Team B is linked to "My Website 2". **Issue:** - The current domain filter only checks if the Website Form is enabled. - It doesn't restrict teams to the current website, so all teams are visible. https://github.com/odoo/enterprise/blob/b191f16abb5913893a228ccc4eedb8a2242a0298/website_helpdesk/controllers/main.py#L22 **Solution:** - Update the domain to filter on the website ID, to ensure only helpdesk teams related to the current website are shown. OPW-4673939
Users can now preview XLSX spreadsheets from the document list view. Older XLS files are clearly blocked with a message explaining that only XLSX files can be opened in Odoo Spreadsheet, reducing confusion.
Original PR description
Before this commit: 1. Can't preview the xlsx file in the list view. 2. Can't preview the xls file. Reason: 1. The mimetype is not set in the isViewable for xlsx. 2. currently xls file is not compatible with our spreadsheet. After this commit: 1. Able to preview the xlsx file in the list view. 2. A notification will be displayed, indicating that `Only XLSX files can be opened with the Odoo Spreadsheet` for .xls file. Task- 3461536 Forward-Port-Of: odoo/enterprise#65162 Forward-Port-Of: odoo/enterprise#47585
A test setup issue in Documents Sign was corrected so signer email details are populated from the right contact record. This prevents false test failures in builds without demo data and helps keep automated quality checks reliable.
Original PR description
This commit fixes a ValidationError triggered during sign request creation tests due to missing signer emails in "no demo" builds. The root cause was incorrect data passed into the test helper create_sign_request_1_role: the user record (res.users) was passed instead of its corresponding partner (res.partner). Since the sign.request.item expects a valid partner_id, this led to signer_email being computed as False, violating the constraint that requires all signers to have valid email addresses. This change ensures the proper partner_id (user.partner_id) is passed when creating the request item, allowing the email computation and constraint to behave as expected. This fix unblocks TestSignedDocument.test_gc_clear_bin build_error-224070
EasyPost shipping labels now include the related Odoo delivery reference, making it easier for staff to match physical labels and carrier dashboard records with the correct delivery order. This reduces manual lookup effort and confusion during shipping operations.
Original PR description
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the…
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the corresponding Odoo move. Steps to reproduce ----- - Set an Easypost delivery method up - Create a sale - Add delivery product & get a rate - Confirm the sale - Go to the linked delivery & confirm it --> The printed label has no reference field Discussion ----- As per EasyPost: The reference field within the shipment body is used for transmissions of electronic data between the shipper and EasyPost, and typically does not get expressed anywhere on the physical label. To get data to the label, you need to leverage the "print_custom" fields outlined in the options section of the shipment. See also https://docs.easypost.com/docs/shipments/options Visual comparison ----- DPD UK labels, before and after the change:  USPS labels, before and after the change:  ----- Ticket: opw-4681615