Daily updates from Odoo
Monday, June 30, 2025
24 changes
10 changes
Resolved issues and error corrections
This fixes an issue where using the Tab key in the color picker could preview or apply colors incorrectly, including changing more text than selected in the editor. Users can now navigate color options by keyboard more reliably, reducing accidental formatting changes.
Original PR description
Following [1], which introduced the preview when focusing color buttons inside a colorpicker (and revert when focusing out of them), tabbing on the color selector within html_editor stopped working as expected: 1. the reset button doesn't trigger a preview 2. For instance in the To-Do app: - Select a single word - Open the "Apply Font Color" picker and use tab to navigate => The color of the whole line is changed. [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
This fix improves the range slider used in the website builder so keyboard navigation no longer triggers repeated updates that can confuse sidebar options. It also makes keyboard focus styling clearer, improving usability for people navigating with the keyboard.
Original PR description
1) This commit adds proper styling on focus-visible on the BuilderRange. 2) When using the arrows to modify its value, it commited after every keydown. If the action relies on a load, the behavior is buggy. This is for instance the case on image optimization options: - Select an image - Set a filter on top > the "Quality" option appears - Use tab to focus it - Press an arrow and stay pressed for a while => The sidebar options are wrongly computed. To avoid that, we debounce the commit just like what was already done in the BuilderNumberInput. Note that while it prevents unwanted UI flickers and doesn't commit until after you let go of the key, the preview doesn't happen: this is due to the fact that each preview is cancelled by the next, preventing the load to ever complete, and thus the apply from happening. task-4367641
Website editors can no longer accidentally submit forms or navigate away by clicking page content while the builder is open. This keeps users safely in editing mode and avoids disruptions such as login attempts or forum post navigation during page edits.
Original PR description
> [ROLE] Go to '/@/web/login' > Edit > > - Click on "Login" => instead of allowing to edit the label, it opens the warning that every field must be completed. > - Enter a login/password and clock on "Login" > you're logged in, redirected, and now out of the editor iframe (every link is clickable). > - (Another way to reproduce the same bug: go to Forum > Help > New Post, then edit)
This update fixes several issues in website image galleries, especially when all images are removed. Galleries now handle empty states safely, show the add-image prompt only when appropriate, and keep navigation controls intact for easier editing.
Original PR description
Miscellaneous fixes about the image gallery: - survive when empty - "Add images" message display conditions - "Remove all" detroying the navigation
This fixes an issue where Chrome could show a “too many redirects” error inside the website editor after translated page names changed. The editor now reloads the preview with a fresh URL when this browser cache behavior is detected, helping users continue editing without disruption.
Original PR description
Since [1], the fix introduced with [2] was lost. This commit adapts [2] to the new `WebsiteBuilderClientAction`. If you have the backend in a language A but the website in English only, you can: 1)…
Since [1], the fix introduced with [2] was lost.
This commit adapts [2] to the new `WebsiteBuilderClientAction`.
If you have the backend in a language A but the website in English only, you can:
1) modify a record's (event, product...) name in language A (say "New Name").
2) visit the page `/new-name-11` => the server will redirect you to the English page `/origin-11`, with the only slug that actually exists on the website. Chrome caches the redirection.
3) give the same name in English as in language A, try to visit
=> the server now wants to access `/new-name-11`
=> Chrome uses the cache to redirect `/new-name-11` to `/origin-11`,
=> the server tries to redirect to `/new-name-11`
=> infinite loop, Chrome puts an end to it after ± 20 redirects.
In effect, Chrome injects a "Too many redirects" layout inside the iframe, which in turn raises a CORS error when the app tries to update it.
At the time of this commit, the flow described here should be expected of users, because the translation UI in the backend is not clear: the default field displayed is in language A even though the website does not use it, and the way to update translations is not obvious (you have to click on the language tag, which doesn't look like a button).
After this commit, if we detect that behavior, we reload the iframe with a new query parameter, making the URL brand-new (and not cached) for Chrome.
Another way to artificially reproduce the issue would be:
- Create a website.redirect from /dog to /cat
- Same from /cat to /dog
- Go to /@/dog (Obviously, reproducing it that way is not fixed by this commit.)
[1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
[2]: https://github.com/odoo/odoo/commit/16d47ddf128f31f13e8d0d74597635faf7f9702a
task-4367641Fixes an issue where installing a missing app from a website snippet did not refresh the website builder afterward. The install dialog now shows the correct app name instead of the snippet name, making the process clearer for users.
Original PR description
This was forgotten in the website refactor [1]. The builder was not reloading after installing a new module via the "Install" button on a snippet. The install module dialog was showing the snippet name and not module name, because of a forgotten recent change [2]. Adapted tests to check presence of the module name and not snippet name. Steps to reproduce: - Install website - Click install on a snippet that's missing its module (e.g. Donation button) - Install module dialog appears - Dialog should show the module name - Builder should reload after clicking on "Save and Install" [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 [2]: https://github.com/odoo/odoo/commit/dd33ab018db7aa0fe7ad5e636636b75aaadd5d7a Related to task-4367641 Related to task-4434981
This fixes a regression in the HTML builder where special handling for style options like text and background colors was lost during a previous refactoring. Restoring this behavior helps users apply visual styling in the builder as expected, reducing disruption when editing website content.
Original PR description
Following the refactoring introduced in [1], the `builder_style_actions` which defines custom behavior for specific CSS styles such as `background-color` and `color` was unintentionally omitted. This commit restores its implementation. The `border-radius` style implementation, that still remains untouched will be restored in another PR: [2] [1]: https://github.com/odoo/odoo/commit/b4b2153 [2]: https://github.com/odoo/odoo/pull/215371
Saving changes in the website menu editor now preserves any page edits already made in the website builder. This prevents users from losing their work when adjusting navigation menus during website editing.
Original PR description
This plugin fixes a bug where making changes on the editor, opening the menu editor and clicking save would cause the changes to be discarded. Steps to reproduce: - Open editor - Make any change - Click on any navbar element (like Home) to open the navbar popover - Click on the edit menu button in the popover - A modal will open, click save - All changes have been discarded After the fix the changes will be saved when clicking save in the menu editor modal
When an invoice submission to Kenya's eTIMS times out, the system now checks whether the government already received it before trying again. If it was received, Odoo restores the confirmation details such as the QR code, reducing duplicate submissions and manual follow-up.
Original PR description
When a timeout occurs during invoice submission to eTIMS, we had no way to know if the invoice was actually received. Retrying could lead to duplicate invoices being accepted by the government. With the release of the selectInvoiceDetails endpoint, we now check if the invoice was already submitted before retrying. If found, we treat it as successfully sent and retrieve its details (QR code, etc). If not, we proceed to resend. task-4863787 Forward-Port-Of: odoo/enterprise#88858 Forward-Port-Of: odoo/enterprise#88608
This fix ensures that when users save a website form, the related access setting is properly applied instead of being skipped. It also makes the option clearer with a tooltip and improves reliability by avoiding inconsistent handling of form model information.
Original PR description
When [1] converted the form access option to fit inside `html_builder`, the form access was supposed to be enabled upon saving a form, but the used selector was incorrect, which led to the form access not being enabled. Also, a `ModelCache` was created which kept track of the same model but according to various ways to write this key. This system was flawed and led to reaching distinct object depending on the used "synonym" key. This commit: - fixes the selector used during the save operation - removes `ModelCache` and uses a plain cache with the model name as key in all situations - makes changes to form access included in the history - adds a tooltip on that confusing option [1]: https://github.com/odoo/enterprise/commit/689a2186fbe3b932b90bef3b64716c8443bad551 task-4367641
2 changes
Resolved issues and error corrections
The Kenyan eTIMS integration now checks whether an invoice that timed out was already received before trying again. This helps avoid duplicate submissions to the government and restores confirmation details such as QR codes when the original submission succeeded.
Original PR description
When a timeout occurs during invoice submission to eTIMS, we had no way to know if the invoice was actually received. Retrying could lead to duplicate invoices being accepted by the government. With the release of the selectInvoiceDetails endpoint, we now check if the invoice was already submitted before retrying. If found, we treat it as successfully sent and retrieve its details (QR code, etc). If not, we proceed to resend. task-4863787 Forward-Port-Of: odoo/enterprise#88858 Forward-Port-Of: odoo/enterprise#88608
Fixed an issue where Chilean point-of-sale invoice settlements always showed an amount of $1 instead of the actual outstanding balance. This ensures staff can settle customer invoices accurately in POS and avoid undercharging or manual corrections.
Original PR description
**Problem:** When trying to settle an order in POS with a Chilean company, the amount to be settle will be 1$, regardless of how much needed to be settled. **Steps to reproduce:** - Set the company to a Chilean company. - Make an invoice for a Chilean customer and confirm it. - Go to pos, and click settle invoices for your client, chose the invoice you just made. - The amount will be 1$ **Why the fix:** The field *pos_amount_unsettled* was not loaded into the invoice if the company is from Chile. It resulted in it being undefined, thus it was set to 1 afterwards. We now load this variable into the invoice when loading the data. opw-4856764
1 change
Resolved issues and error corrections
Selecting an existing signing template from the search option now brings users back to the Contract Template form with their choice filled in. This avoids an unexpected detour to the signing template setup page, while keeping the normal setup flow for newly uploaded PDFs.
Original PR description
### Steps to Reproduce: - Create a contract template. - Try assigning signatories to it by clicking on the search more option. ### FIX: - We will use inherited view id to view the list view of sign_template_id task-4860340
11 changes
Resolved issues and error corrections
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
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
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
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 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
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 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
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