Thursday, August 21, 2025
33 changes · saas-18.3
Resolved issues and error corrections
The Attendance overview list now shows employees only when they have matching attendance records. This avoids clutter and makes grouped attendance reports easier for HR teams to read, while preserving the existing Gantt view behavior.
Original PR description
To reproduce: ============= - Activate the "Attendances" app. - Go to Attendances > Overview. - Switch to list view. - Group by Employee. Issue: ====== The current domain fetches all employees…
To reproduce: ============= - Activate the "Attendances" app. - Go to Attendances > Overview. - Switch to list view. - Group by Employee. Issue: ====== The current domain fetches all employees matching the filter, regardless of whether they have attendance entries in the grouped model. https://github.com/odoo/odoo/blob/5b5f0bf795ca538e91f063f2b3185c12b1d0a992/addons/hr_attendance/models/hr_attendance.py#L677 Fix: ==== Restrict the employee list to only those linked to a resource that appears in the grouped data https://github.com/odoo/odoo/blob/5b5f0bf795ca538e91f063f2b3185c12b1d0a992/odoo/models.py#L2360-L2361 The problem is the behavior of gantt view will change it's behavior So we have to applied only to the list. there's something unique when we call it from the gantt which is `gantt_start_date` property that we will use it so we can differentiate between list and gantt view -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223594 Forward-Port-Of: odoo/odoo#223181
Online-paid self-order POS orders are now sent to the preparation display, matching the behavior of terminal-paid orders. This prevents kitchen or preparation teams from missing orders that customers already paid for online.
Original PR description
After this pr: https://github.com/odoo/odoo/pull/213493 the orders were not sent to the preparation display if the order was payed with and online payment method. This commit add the same logic as the terminal payments to send the order to the preparation display. 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 fix prevents copied databases using the Greek e-invoicing module from unintentionally contacting external services. It helps support teams investigate customer issues safely without affecting live operations or customers.
Original PR description
This commit adds the missing neutralization necessary for the l10n_gr_edi module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] odoo#203428 Forward-Port-Of: odoo/odoo#223536
Updating a parent or child contact no longer raises an error when one VAT value is blank and the other is unset. This prevents unnecessary blocking of partner updates while still protecting accounting consistency when VAT numbers truly differ.
Original PR description
An error exists if we update the parent partner and the the VAT number does not match with the child partner to prenvent inconsistencies between journal item created before the change. This error is also triggered when one partner vat is '' and the other is False. This commit aims to fix that. opw-4915851 Forward-Port-Of: odoo/odoo#223413 Forward-Port-Of: odoo/odoo#223022
This fix ensures the customer name used in a point-of-sale loyalty gift card test is unique and can be found reliably in the PoS. It helps prevent false test failures and supports more stable validation of loyalty workflows.
Original PR description
This commit make sure that the partner name is unique and can be retrieved in the PoS opw-230992 Forward-Port-Of: odoo/odoo#223387
Fixes an issue where payment methods set up in a parent company were not visible when viewing a contact from a child branch. This ensures branch users can see and use the expected payment details without switching company context.
Original PR description
In this bug, the payment method is not shown in the child branch. To reproduce: 1- Create a db with account and contact app installed 2- Create a company and a branch 3- Create a payment method in parent company and add it to contact form of a partner 4- Go to child branch. You can see the payment method is not shown in the contact form. opw-4920219 Forward-Port-Of: odoo/odoo#223598 Forward-Port-Of: odoo/odoo#219448
This update refreshes Odoo Spreadsheet with several fixes that improve everyday reliability. It corrects chart exports to Excel, avoids duplicate pasted content from the clipboard, prevents inconsistent table row moves, and restores pivot data properly after undoing deletions.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ab02b0cb9 [REL] 18.3.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ab02b0cb9 [REL] 18.3.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/0d2a01e6c [FIX] xlsx: correctly export aggregated charts [Task: 4954426](https://www.odoo.com/odoo/2328/tasks/4954426) https://github.com/odoo/o-spreadsheet/commit/4d2398b70 [FIX] clipboard: don't paste both image and text content [Task: 4876682](https://www.odoo.com/odoo/2328/tasks/4876682) https://github.com/odoo/o-spreadsheet/commit/7f80875f3 [FIX] selection: prevent partial move of table rows with headers [Task: 4862731](https://www.odoo.com/odoo/2328/tasks/4862731) https://github.com/odoo/o-spreadsheet/commit/64cf69dc0 [FIX] pivot: reload when delete is undone [Task: 5001153](https://www.odoo.com/odoo/2328/tasks/5001153) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix prevents custom readonly fields on invoice lines from becoming editable when users open invoices. It avoids accidental changes and incorrect dirty-state warnings while keeping intended editing behavior for product labels and products.
Original PR description
Steps to reproduce ================== - Go to invoices - Open studio - Click on the invoice lines - Edit the list view - Add a new field of type checkbox - Mark that field as readonly - Exit studio - Open an invoice - Click on the checkbox => The form is marked as dirty and the checkbox is toggled Cause of the issue ================== https://github.com/odoo/odoo/commit/291518a7e7708690d183b9d1ca53c84d0c56ad90 If the state is not in ["cancel", "done", "posted"], the fields are never in readonly Solution ======== Only do this for the "name" and "product_id" fields opw-4917471 Forward-Port-Of: odoo/odoo#222595
The Italian localization now includes the required 0% EU services export tax with the correct legal note. This helps businesses issue compliant invoices for EU service exports and distinguish them from other zero-rated EU tax cases.
Original PR description
Description of the issue this commit addresses: The export tax for services is missing in the italian localization. It's required because it has a different legal note than the usual 0% EU tax. --- Desired behavior after this commit is merged: The italian localization has a 0% EU S for exported services in EU with the right legal note. --- task-4715771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223524 Forward-Port-Of: odoo/odoo#205521
The sales order availability indicator is now hidden when the remaining delivery has been intentionally canceled. This prevents users from seeing a confusing “No future availability” warning after deciding not to deliver the outstanding quantity, even when stock exists.
Original PR description
Issue ----- The availability widget states "No future availability" when the backorder of a product has been cancelled, despite the product being available in stock. Steps to reproduce ----- - Create…
Issue ----- The availability widget states "No future availability" when the backorder of a product has been cancelled, despite the product being available in stock. Steps to reproduce ----- - Create a stored product with some on hand quantity - Create a SO for the product - Register a partial delivery (or set the move quantity to 0) - Cancel the backorder - Go back to the SO --> The widget is red and states that there is "No future availability". While the logic is sound, this is confusing the user because they have some qty in stock. Solution ----- The user has manually decided not to deliver the (full qty of) product. There is aready some logic to set the `display_qty_widget` field to False when the user deletes the move from the the picking. https://github.com/odoo/odoo/blob/693e1ef2f934f58209a78787404d5c76be550af4/addons/sale_stock/models/sale_order_line.py#L61 Since the user specified that there is nothing left to deliver, we can extend the condition to include our use case. To do so, we can simply check the existence of a move that is not in a 'done' or 'cancel' state. This will make the widget invisible because it is conditionally invisible. https://github.com/odoo/odoo/blob/693e1ef2f934f58209a78787404d5c76be550af4/addons/sale_stock/static/src/widgets/qty_at_date_widget.xml#L7 ----- Ticket: opw-4942277
This fixes cases where files could be acted on before their upload was fully recognized, which could cause attachments to delete without confirmation or block messages from sending. It improves reliability when adding files in chat, messaging, live chat, and course review workflows.
Original PR description
\* = im_livechat, website_slides Not waiting for the uploading state to be resolved can lead to unexpected behavior, such as deleting the attachment immediately when clicking on the delete button rather than showing the confirm dialog. This might also prevent the composer from being sent if the attachment is still uploading. This is checked when checking the enabled state of the send button when clicking on it, but it is not checked when pressing enter directly. Some tests also checked uploading was finished but didn't target the correct attachment. https://runbot.odoo.com/odoo/error/230901 https://github.com/odoo/enterprise/pull/92620 Forward-Port-Of: odoo/odoo#223464 Forward-Port-Of: odoo/odoo#223367
This fix prevents products used as loyalty rewards from being hidden in the Point of Sale. It helps ensure loyalty promotions remain usable at checkout and avoids cashier confusion when applying rewards.
Original PR description
Before this commit, a product used as a loyalty reward could be hidden in the PoS. opw-5005934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222451
Point of Sale order logs now include clearer details about which order lines and payments were added. This makes it easier for support teams to investigate mismatches and resolve issues faster without changing the checkout experience.
Original PR description
Before this commit, in case of a mismatch it was difficult to identify the root cause since the logs did not show which lines or payments were added to the order. opw-4954736 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223266
Shared Microsoft Office documents now keep the correct file type instead of being treated as ZIP files. This lets portal users open and work with documents in Odoo features such as spreadsheets without file type errors.
Original PR description
Issue: Inconsistent mimetype vs filename for documents shared by portal users. 1. Share a ms office document logged in as a portal user. 2. filename is correct, but mimetype is `application/zip`. 3.…
Issue: Inconsistent mimetype vs filename for documents shared by portal users. 1. Share a ms office document logged in as a portal user. 2. filename is correct, but mimetype is `application/zip`. 3. User can't interact with the file to open the file in the Odoo spreadsheet because the mimetype is zip. <img width="387" height="192" alt="image" src="https://github.com/user-attachments/assets/be31f05f-e4e3-44d9-b12a-66f96feba950" /> <img width="274" height="67" alt="image" src="https://github.com/user-attachments/assets/93064e5c-c028-41ce-8e79-1b9c9447c018" /> With `fix_filename_extension()`, the following two commits fixed the issue of Odoo's `guess_mimetype` function incorrectly guessing extensions such as `.xlsx` as `.zip` extension. https://github.com/odoo/odoo/commit/8842b6b43e7c3d1cc67d7d399bb210e4009e23b2 https://github.com/odoo/odoo/commit/34d9375e2efb604f8e7036cb710f44b01f9ccaee However, the `_from_request_file()` still uses the incorrectly guessed mimetype to create an attachment, leading to inconsistent extension from the filename (.xlsx) vs attachment record's mimetype (.zip). This commit fixes the issue by using the mimetype from the filename's extension. This is safe if the following assumption is correct: At the point where the `from_request_file()` attempts to create the attachment record, the `filename` contains correct extension name, presumably fixed by the `fix_filename_extension()`. Commit message to be changed after with Julien's confirmation; opw-4753670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222556 Forward-Port-Of: odoo/odoo#222368
Applying a button style to text in the HTML editor now preserves the font size the user already chose. This prevents unexpected visual changes and helps website content keep its intended appearance.
Original PR description
### Steps to reproduce: - Type some text and apply a large font-size. - Select the text and apply the button style. - Notice that the font-size is not reflected on the button. ### Description of the…
### Steps to reproduce: - Type some text and apply a large font-size. - Select the text and apply the button style. - Notice that the font-size is not reflected on the button. ### Description of the issue/feature this PR addresses: - The `<a class=btn>` element was placed inside a font-size `<span>`. - However, the `.btn` class defined its own font-size, causing the original styling to be overridden. ### Desired behavior after PR is merged: - Improved the splitAroundUntil utility to correctly handle cases where the target node has no previous or next sibling. In such edge cases, the function now recursively splits up the inline ancestry until the specified limitAncestor, ensuring that the target node is fully isolated. - The font-size `<span>` is moved inside `<a>` tag when applying a button style. - This ensures the original font-size is preserved and correctly displayed. task-4731416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222348 Forward-Port-Of: odoo/odoo#216300
This fixes invalid formatting in the delivery report template that could cause problems when editing or rendering reports. Business users should see more reliable delivery report handling, especially in the report editor.
Original PR description
because of odoo/odoo#169512, there was some illegal html generated in the delivery report. Indeed a <div> in a <p> is not supported. This created issues in the reportEditor, and possibly elsewhere 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#223158
This fix keeps paragraph line breaks visible when users split a paragraph after inserting a manual line break. It prevents edited website or HTML content from unexpectedly losing spacing, helping pages keep the layout users intended.
Original PR description
Problem: When at the end of a paragraph, pressing SHIFT+ENTER followed by ENTER creates a new paragraph, but the previous one loses its last line break. Cause: When splitting an element, the `<br>` at the selection point is moved to the newly created split element. However, to render an empty line visibly, two `<br>` elements are needed. Moving the existing `<br>` makes the last line break in the original paragraph invisible. Solution: In this special case, instead of moving the `<br>` at the selection point, insert a new `<br>` in the new element, preserving the visual line break in the original paragraph. Steps to reproduce: - Add a paragraph - Type some text, then press SHIFT+ENTER - Press ENTER to create a new paragraph -> The last line break in the first paragraph is lost opw-4987922 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221869
Combo product discounts now display correctly when a pricelist discount applies, both on the product page and during checkout. This prevents customers from seeing confusing crossed-out zero prices or missing discounts, improving pricing clarity in eCommerce flows.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a combo product; 2. create a pricelist that gives a 10% discount on the product; 3. go to product's website page; 4. observe the displayed discount; 5. add product to cart; 6. go to checkout. Issue ----- The discount has disappeared, instead it displays the original price next to a stricken-through "$ 0.00" Cause ----- The `_compute_discount` method does not get the correct `pricelist_item_id` for the combo items. Additionally, on checkout, it shows the `price_unit` of the combo line in the strike-through, which is always 0. Solution -------- When computing the discount of a combo item, retrieve the discount of its linked line, which has the correct value. Additionally, when displaying a combo product in eCommerce, use `_get_display_price_ignore_combo` instead of the `price_unit`. opw-4968848 Forward-Port-Of: odoo/odoo#223436 Forward-Port-Of: odoo/odoo#222472
This fixes checks around file uploads across messaging, knowledge, helpdesk knowledge, spreadsheet comments, and WhatsApp-related areas. It helps ensure files are properly treated as uploading when added, reducing upload-related errors and test failures.
Original PR description
\* = knowledge, test_mail_enterprise, test_spreadsheet_edition, website_helpdesk_knowledge, whatsapp Enterprise counter-part. https://runbot.odoo.com/odoo/error/230901 https://github.com/odoo/odoo/pull/223367 Forward-Port-Of: odoo/enterprise#92697 Forward-Port-Of: odoo/enterprise#92620
This fix ensures appointment booking updates sent to Google Reserve keep all existing slot information while adding the party size. This helps Google receive a complete, correctly formatted booking response and reduces the risk of update failures or missing booking details.
Original PR description
The controller incorrectly modified the given "slot" to only contain the party size key. Instead, it should update the information to add this key next to the existing ones, and in turn return a properly formatted slot to Google. Task-3083812 Forward-Port-Of: odoo/enterprise#92839
Employee clock-in updates in Belgian POS now include the required staff identification field when shared with other devices. This prevents errors when another device receives the update and needs to communicate with the Belgian fiscal blackbox.
Original PR description
Before this commit, when clocking, the session was synchro with other devices but without the _employee_insz_or_bis_number custom field. _employee_insz_or_bis_number was thus not accessible after the device receives the websocket message and the pos was returning a traceback when trying to send a message to the blackbox. This commit fixes the issue.
Products that are neither rentable nor sellable are now kept out of sales order product selections. This prevents staff from accidentally adding unavailable products and helps keep sale and rental workflows accurate.
Original PR description
This PR adds a test for the explained case which was solved by: - PR https://github.com/odoo/enterprise/pull/91701 - Commit…
This PR adds a test for the explained case which was solved by: - PR https://github.com/odoo/enterprise/pull/91701 - Commit https://github.com/odoo/enterprise/commit/a2bbf33f5e787420389f1550d8e66b7b6995dc75 #### Issue: Not rentable product were displayed in sale order product dropdown list whether they were salable or not #### Step to reproduce: - install Sale, Rental, - create a product no Sales, no Rental - create a new sale order #### Current behavior: - your product appears in the dropdown list to add a product #### Expected behavior: - your product shouldn't appear in the dropdown list to add a product #### Cause: - From the commit [d5f72c2](https://github.com/odoo/enterprise/commit/d5f72c201bf0642f2f47315f06468528268251a3) domain for rental are computed on back end. - sale_renting module override the `_domain_product_id()` method. It add a OR to the domain on `'rent_ok' = order_is_rental`. Therefore, if one create a sale order outside of the rental app, every not rentable product is displayed. #### Solution: - This domain should apply only if `order_is_rental` is enabled. Therefore add a AND to check if `order_is_rental` is enabled. opw-4966082
This fixes an issue in the Belgian salary contract offer process. It helps ensure salary contract offers are handled correctly, reducing the risk of errors for HR teams using Belgian payroll workflows.
Original PR description
Forward-Port-Of: odoo/enterprise#88918
A test user setup was simplified by removing an unnecessary timesheet approval permission. This prevents failures when the manufacturing work order accounting app is tested on its own, improving reliability without changing business functionality.
Original PR description
on the test `test_mrp_aa_employee_without_account_rights` the user was created with the group `hr_timesheet.group_hr_timesheet_approver` which is not needed and was causing the test to fail on Single app test as this module does not depend on hr_timesheet. This commit removes this group from the user creation. runbot-231137 Forward-Port-Of: odoo/enterprise#92747
Belgian payroll accounting can now be installed even if the Mobility Budget Special Contribution salary rule was deleted or is absent from an older database. This prevents an installation error and helps companies complete accounting setup without manual technical intervention.
Original PR description
Currently an issue occurs when the user tries to install `10n_be_hr_payroll_account/account` after follow steps: - Install `l10n_be_hr_payroll` and switch to `BE Company CoA` - Go to Payroll > Configuration > Salary > Rules - Delete `Mobility Budget Special Contribution` - Error occurs when trying to install accounting error: `ValueError: External ID not found in the system: l10n_be_hr_payroll.cp200_employees_salary_mobility_budget_tax` The salary rule mentioned above steps was added with commit [1], and the issue also occurs if the database was created before commit [1] with a module `l10n_be_hr_payroll` and the user tries to install the account after commit [1]. This commit fixes the issue by using `raise_if_not_found=False`, which prevents an error from being raised when the salary rule is missing. [1] - https://github.com/odoo/enterprise/commit/16c8a223beda4e4ebcf2c24f716687726f7230f3 sentry-6578747340 Forward-Port-Of: odoo/enterprise#84578