Monday, July 13, 2026
31 changes · 19.0
Resolved issues and error corrections
The Employee app’s demo data button now automatically adjusts its width so longer translated labels, such as French or Arabic, display correctly. This prevents text from overflowing when a company has no employees, improving readability for multilingual users.
Original PR description
Steps to reproduce: ---------------------------------------- - Be in a company with no employees - Switch to French or Arabic - Open the Employee app - The text in the button overflows Cause: ---------------------------------------- The button has a specified width: `w-100` And the text is `text-nowrap` So it overflows from the button box Solution: ---------------------------------------- Make the width auto adapt to the text with `w-auto`. Before: <img width="727" height="201" alt="image" src="https://github.com/user-attachments/assets/0347125b-1595-44ea-a0bd-b7c77e6c753d" /> After: <img width="723" height="236" alt="image" src="https://github.com/user-attachments/assets/18e40b39-f7b9-488c-9e47-3b9b82bdb445" /> opw-6345094 Forward-Port-Of: odoo/odoo#274405
This fixes several editing issues when users work with file boxes in the HTML editor. It keeps editing actions contained in the file name area, avoids unsupported formatting behavior, and removes an unwanted scrollbar in the link preview popover.
Original PR description
### Purpose of this PR: * Prevent the powerbox from opening inside a static file box. * Paste content as plain text inside a static file box, since formatting is not supported there. * Prevent the cursor from leaving an empty file name box when pressing `ArrowLeft` or `ArrowRight`. * o_we_preview_favicon had a fixed height larger than its content, causing the link popover to overflow and show an unwanted scrollbar when the file input was empty as there was nothing to preview. Reduced the height to match the actual content size. * Shorthands (such as `#` for headings or `*` for lists) should not trigger when editing inside a file box. task-6283420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275308 Forward-Port-Of: odoo/odoo#268827
This fixes an error that could occur when adding a new carousel slide while editing a website page. Editors can now add slides without the carousel breaking or showing a console error, improving reliability for website content updates.
Original PR description
Steps to reproduce: - Edit a page. - Drop a carousel snippet like s_quotes_carousel - Click "Add Slide" with the browser console open. => Traceback: TypeError: Cannot read properties of null (reading 'classList') Cause: `slide()` used the editor window's `Carousel` instead of the iframe's. This created a second Carousel instance for the same element. Both instances updated the indicators at the same time, causing one to remove the active indicator before the other tried to use it, leading to the traceback. Fix: Use `this.window.Carousel` so the iframe's existing Carousel instance is reused instead of creating a second one. task-6084484 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
This fixes a case where empty analytic distribution models could trigger an error during processing. Empty models are now skipped instead of being merged, improving reliability without changing normal user workflows.
Original PR description
It is possible to have an empty distribution model, there is therefore ne need to merge it, especially since it raises when doing this ```python self.env['account.analytic.plan'].mapped(lambda p: p._column_name()) ``` Forward-Port-Of: odoo/odoo#275839
Invoice PDFs now base the discount column on the lines actually shown in the report. This prevents an empty discount column from appearing when section composition is hidden, making customer invoices cleaner and less confusing.
Original PR description
### Steps to reproduce 1. Create a invoice with a section and add products under it with values 2. Enable **Hide Composition** on the section. 3. Print the invoice PDF. <table> <tr> <td> <img…
### Steps to reproduce
1. Create a invoice with a section and add products under it with values
2. Enable **Hide Composition** on the section.
3. Print the invoice PDF.
<table>
<tr>
<td>
<img width="1278" height="425" alt="image" src="https://github.com/user-attachments/assets/969a222a-5e2f-48e2-962d-fc1cf6440619" />
</td>
</tr>
</table>
### Description
When an invoice contains a section and products in it with values and with **Hide Composition** enabled, the PDF invoice report incorrectly displays the **Disc.%** column header even though no discount values in that section line.
The report currently computes `display_discount` using `o.invoice_line_ids`:
```xml
<t t-set="display_discount" t-value="any(l.discount for l in o.invoice_line_ids)"/>
```
Since `o.invoice_line_ids` still contains the hidden product lines, `display_discount` evaluates to `True`, causing the **Disc.%** column header to be displayed. However, those product lines are replaced by the section line in the report, so no discount values are shown, resulting in an empty column.
### Current behavior
The **Disc.%** column is displayed, but all its cells are empty.
<table>
<tr>
<td>
<img width="808" height="488" alt="image" src="https://github.com/user-attachments/assets/7d9afee6-fef5-49c8-bc4e-b01caa8b43bd" />
</td>
</tr>
</table>
### Expected behavior
The **Disc.%** column should not be displayed when the reported lines do not contain any discounts.
<table>
<tr>
<td>
<img width="798" height="427" alt="image" src="https://github.com/user-attachments/assets/6ffe7985-a7d0-43f5-8d40-41e700ecbed3" />
</td>
</tr>
</table>
### Solution
Compute `lines_to_report` before evaluating `display_discount` and use it instead:
```xml
<t t-set="lines_to_report" t-value="o._get_move_lines_to_report()"/>
<t t-set="display_discount" t-value="any(l.discount for l in lines_to_report)"/>
```This fix ensures VAT reference-related messages in Accounting use the correct user language when translations are available. It prevents untranslated text from appearing in some company or partner account flows, improving clarity for multilingual users.
Original PR description
It can happen that _ref_vat has some lazy translate object. Without the self.env._ the translation would be ignored. (no translation language detected, skipping translation) runbot-941504 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a crash that occurred when opening the purchase product catalog after switching to a mobile-sized view. Users can now access the catalog on smaller screens without interruption, improving reliability for mobile and responsive workflows.
Original PR description
Currently, th purchase catalog crashes in mobile view. Steps to reproduce: ------------------- * Open purchase order form on desktop * From the devtools put window size to mobile (don't refresh) * Select catalog > Traceback: Cannot find the definition of component "Dropdown" Why the fix: ------------ PurchaseSuggestCatalogSearchPanel extends AccountProductCatalogSearchPanel which also extends AccountProductCatalogSearchPanel. Components were completely overridden and not inherited. opw-6219505
Fixed an issue where stock availability messages could pile up when shoppers changed product variants on pages with certain menu-based add-to-cart elements. This keeps product availability information clear and avoids confusing customers during checkout decisions.
Original PR description
Steps to reproduce:
- Add an `s_add_to_cart` snippet inside a mega menu
- Open a product detail page for a storable product
- Change the product variant several times
- Stock availability messages keep appending under `availability_messages` instead of replacing the previous one
`_onChangeCombinationStock` removed existing messages with `document.querySelector('.oe_website_sale').querySelectorAll(...)`, but appended the new message with
`this.el.querySelector('div.availability_messages').append(...)`.
`document.querySelector('.oe_website_sale')` only returns the first `.oe_website_sale` element in the document. When a mega menu contains an `s_add_to_cart` snippet, that element appears before the product page container, so the removal step runs on the wrong subtree and never clears the messages on the product page.
Fix by scoping the removal to `this.el`, the current `WebsiteSale` interaction root, so both removal and insertion target the same product page container.The API keys view now shows scope and expiration details on separate lines instead of running them together. This makes key information easier to read and avoids confusion when reviewing scoped API keys.
Original PR description
The API keys kanban rendered the "Scope:" and "Expires on:" hints as two adjacent inline <small> elements. For a scoped key both are visible, so they were displayed stuck together, e.g. "Scope: rpcExpires on: ...". Render each hint as a block so they stack on their own lines. Keys without a scope are unaffected since the scope hint stays hidden. Description of the issue/feature this PR addresses: Current behavior before PR: <img width="980" height="414" alt="image" src="https://github.com/user-attachments/assets/6cd8b338-1d2e-4abb-a90b-03218aaef941" /> Desired behavior after PR is merged: <img width="979" height="389" alt="image" src="https://github.com/user-attachments/assets/83ffa680-ffb8-415f-af3f-8e53cb8e8351" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Cashmatic point-of-sale module is now included in the translation setup. This helps ensure its text can be translated for users working in different languages.
Original PR description
This commit add the pos_cashmatic module inside the .weblate.json file so that the srings are translated. 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
This fixes an editing issue where triple-clicking inside a small editable text area could accidentally select nearby content outside that area. The change keeps selections contained, making inline editing more predictable and reducing accidental edits.
Original PR description
Problem: Triple-clicking inside an inline `contenteditable="true"` element causes the selection to extend outside of it. Cause: Inline `contenteditable="true"` elements are not considered when looking for the closest block boundary, allowing the browser selection to expand beyond the editable content. Solution: Treat `contenteditable="true"` elements as block boundaries when searching for the closest block. Steps to reproduce: - Add an inline `contenteditable="true"` element inside an editable area. - Triple-click inside it. - Observe that content outside the `contenteditable` element is also selected. task-6255094 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that appeared when editing a website header after switching the logo from an image to text and toggling the company logo option. This makes website editing smoother and prevents users from hitting a technical traceback during a common branding adjustment.
Original PR description
Steps to reproduce: - Enter in edit mode - Click on the navbar logo - Change "Logo" option from "Image" to "Text" - Toggle "Company Logo" in "Visuals" option - Traceback appears: it should hide the logo This commit awaits `loadConfigKey` so `websiteLogoParams` reads the loaded config; otherwise the button targeted the wrong brand view and collided on the `#o_fake_navbar_brand` xpath. task-6284593
The invoice sending wizard now avoids incorrectly labeling attachments as unsupported when the selected sending method does not depend on UBL. This reduces confusing warnings for users and also corrects a spelling error in the message.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
Users who see an error while opening a mail conversation can now use the retry button to load messages again. This prevents users from getting stuck after a temporary loading failure and improves reliability in Discuss and mail threads.
Original PR description
The `retry` button shown after a failed initial fetch did nothing when clicked (it goes through `thread.fetchMoreMessages` which is for load older and load newer). This change routes the click through `fetchMessages` when the failure is an initial one. task-6223358 backport of #272153
This fixes unreliable automated checks around joining and leaving mail channels and corrects a related issue in how channel membership changes refresh message bus subscriptions. It helps ensure Odoo updates mail channel subscriptions correctly when users join or leave, reducing the risk of missed or stale notifications.
Original PR description
The "bus subscription is refreshed when channel is joined/left" tests were flaky: - `mockDate` needs 2 digit date/time parts. The format used here didn't always produce them, so it silently fell back…
The "bus subscription is refreshed when channel is joined/left" tests were flaky: - `mockDate` needs 2 digit date/time parts. The format used here didn't always produce them, so it silently fell back to a past date. That was enough to make the "left" test pass even without actually leaving. - The "left" test never actually left the channel: a confirm dialog blocked it. - The "join" test never actually joined the channel. - The tests expected `runAllTimers` to guarantee that every initial subscription was done, but thats not the case, making the number of `subscribe` calls non-deterministic (e.g. flushing calls to `bus_service.add` but not ensuring the worker received them through its message port, and triggered the debounced `updateChannels`). Fixing the tests exposed a real bug: `memberBusSubscription` is meant to trigger a refresh whenever membership changes relative to the bus start time. As a boolean, "member, no refresh needed" and "not a member" are indistinguishable (both `false`), so leaving a channel joined before the bus started never changed the value and never triggered a refresh. This PR add a third state so membership and non-membership stay distinguishable regardless of when the bus started. runbot-941462 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
A small syntax mistake in the stock forecast details screen was corrected. This prevents the forecast view from failing to load, helping users access inventory forecast information reliably.
Original PR description
Issue: There is a missing closing curly bracket on line 67 in odoo/addons/stock/static/src/stock_forecasted/forecasted_details.xml (View) This PR corrects this error opw-6367046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A messaging screen issue caused the “Load More” button to appear transparent, making it difficult for users to find when reading older messages. The update restores the correct visibility behavior so users can reliably access more conversation history.
Original PR description
Since #198829, a `t-att-class` has been added to the `loadOlder` template that relies on `mountedAndLoaded` of thread state to control the visibility of the `Load More` button. But it doesn't read the value from the state properly. As a result, the button is always transparent. This change fixes this by reading the value from the state. Forward-Port-Of: odoo/odoo#275253
This fix prevents list-specific font size validation from running when users apply unrelated formatting, such as bold text. It makes editor formatting more predictable and reduces the chance of unexpected behavior when editing lists.
Original PR description
#### Description of the issue this PR addresses: - Fully selected list items could go through font size checks even when applying unrelated formatters. #### Desired behavior after PR is merged: - Restrict list item font size checks to font size formatters only. task-6329161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275096 Forward-Port-Of: odoo/odoo#272104
Creating or opening a new company no longer creates a batch payment sequence too early. This prevents payment numbering records from being linked to the wrong or missing company and improves reliability for multi-company accounting setup.
Original PR description
Previously, batch payment sequence will be created by simply select to create new company due to having lambda in default. Hence, the created sequence does not have a correct company_id set as company hasn't yet created. Switch to creating sequence in ``create`` function to avoid this issue. Also use ``range_year`` for payment prefix because it was set to use date range. 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#273487 Forward-Port-Of: odoo/odoo#268689
Notification emails sent after a login from a new device now correctly follow the recipient user's selected language. This ensures users receive the email subject and content in the expected language when two-factor authentication is enabled.
Original PR description
**Steps to reproduce:** - Enable 2FA - Change user language - Log in in another private window / device - Check the notification email of a login with another device - Email body/subject are not properly adapted to user language **Issue:** View manual rendering doesn't pass the user language. **Fix:** Add it to the context before `_render_template` and subject translation (reapply similar fix [1]). [1] https://github.com/odoo/odoo/commit/4d8d1736ca03a3d6b4e86cbc7463a79a284d1f3c opw-6042550 Forward-Port-Of: odoo/odoo#274333 Forward-Port-Of: odoo/odoo#261468
Chilean export invoice PDFs now keep customs information in the correct columns even when origin or destination port details are missing. This prevents package quantities and other export details from appearing under the wrong headings, improving document accuracy for customers and compliance workflows.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#121923
This change stops Sendcloud delivery shipments from including tax numbers in customs information by reverting a previous update. It helps ensure customs data sent to the carrier matches the intended requirements and avoids sharing unnecessary tax details.
Original PR description
Revert of c696339. ----- Ticket: opw-6384570
This fix corrects how Belgian CODA bank statement data is read after a related compatibility change. It prevents import errors and ensures the correct statement details are used when processing bank files.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id
This fixes an issue where companies using Peru localization could not create a certificate when Chile localization was also installed. The Chile-specific serial number requirement now applies only where appropriate, preventing unnecessary setup errors for other Latin American companies.
Original PR description
With a l10n_pe company and having a l10n_cl company installed: - Try to create a certificate in the settings, there is a missing field error. The template certificate_certificate_view_form have a required subject_serial_number field in l10n_cl but it shouldn't in other latam localization. opw-6274126
Demo social feed comments now use the correct standard demo user data after older demo partner data was removed. This ensures comments in demo mode show the right author image, making demo feeds look consistent and accurate.
Original PR description
Bug === Since ce264a2 , we remove the demo partner in the social_demo module, but we didn't update the code to use the demo data in base. Task-6293738
This update adds the Belgian CODA extension module to the translation configuration. It helps ensure the module can be included in the normal translation workflow, with no direct change to day-to-day user behavior.
Original PR description
This commit will add l10n_be_coda_extension_number in the weblate json file. no task id
Printing an appraisal form from the action menu now waits briefly so the menu can close before the browser print dialog opens. This prevents the menu from appearing on printed appraisal documents, improving the professionalism and clarity of the output.
Original PR description
When printing the appraisal form from the action (cog) menu, the drop down menu itself was incorrectly showing up in the printed document. This happened because the browser started printing immediately before the menu had time to close. By adding a small delay before triggering the print action, the menu now has time to completely close, so it no longer appears in the final print. task-6369240
This update makes the database authentication module available for translation work, helping improve language coverage for users. It also corrects minor wording mistakes and adjusts an internal error check that users would not encounter directly.
Original PR description
The aim of this commit is to allow the translator to work on this module translation and fix a typo that was made. Task-id: None
This fix prevents an error when users clear the start or end date on a Mexican payroll payslip. The system now checks that dates are present before running salary-limit warning calculations, so payroll users can edit payslip periods without disruption.
Original PR description
Currently, an error occurs when a user removes the payslip dates. **Steps to reproduce:** - Install the `l10n_mx_hr_payroll_account_edi` module with demo data. - Switch to `ZAPATERIA URTADO ÑERI`…
Currently, an error occurs when a user removes the payslip dates. **Steps to reproduce:** - Install the `l10n_mx_hr_payroll_account_edi` module with demo data. - Switch to `ZAPATERIA URTADO ÑERI` company - Go to `Payslips`, create a payslip. - Set an `employee`, and remove either the `start date` or the `end date` from Period.. `TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'` After the [recent commit] adding a warning about the employee exceeding the salary limit, when the user removes the dates from the payslip, the compute method attempts to compute the warning from [1], and when it adds relativedelta to date_from, which is False, it raises the error [2]. This commit ensures that the payslip dates are checked first before adding relativedelta to the date and performing the comparison. [recent commit]: https://github.com/odoo/enterprise/commit/6abfa47dafe439f9328d606ef6ac5126ec6eb1f6 [1]- https://github.com/odoo/enterprise/blob/53a7fd4d53ffd510ad42632c69ce9d3a22c59e70/hr_payroll/models/hr_payslip.py#L1446 [2]- https://github.com/odoo/enterprise/blob/53a7fd4d53ffd510ad42632c69ce9d3a22c59e70/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py#L272-L276
Signed recruitment offer certificates now show the applicant's actual email address instead of a placeholder. This prevents confusion when reviewing signature certificates and keeps recruitment records accurate.
Original PR description
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's…
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment, hr_contract_salary 2) Create an new application and add basic detail like name and email as (path and path@test.com) 3) Generate offer and sign with all the required signer. 4) Open the application form view and open the certificate. ### **Observed Behavior:** Email is not set correctly in the generated certificate (appearing as john@example.com). ### **Expected Behavior:** The email of the applicant should be correctly set(e.g as path@test.com) ### **Root Cause:** When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed. [1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54 [2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59 ### **Fix:** Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time. **opw-6280170** Forward-Port-Of: odoo/enterprise#123901 Forward-Port-Of: odoo/enterprise#123767
Sendcloud shipping labels now correctly keep dots in address numbers, such as “12.345”, instead of shortening them. This prevents incorrect house number data being sent to Sendcloud and helps ensure delivery labels match the customer address.
Original PR description
Issue ----- Labels have unexpected format when the delivery address has a dot (`.`) in the number. Steps to reproduce ----- - Set up Sendcloud (carrier shouldn't matter) - Enable logs - Create a customer (with valid address, phone and email) - Address must contain a dot, eg Grand Place 12.345 - Deliver a product to the customer - Add sendcloud as delivery method - Go to the logs - Open the "sendcloud request parcels" log > house_number is 12 Cause ----- The `house_number` field is populated using `_get_house_number`, where the regex used to extract the number from the address line does not accept the `.` character. https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/delivery_sendcloud/models/sendcloud_service.py#L323 ----- Ticket: opw-6295904 Forward-Port-Of: odoo/enterprise#123266