Thursday, June 11, 2026
20 changes · 19.0
Enhancements to existing features
The point of sale number entry popup was reorganized so its input update behavior can be customized more easily. This is a small internal improvement that supports future extensions without changing the cashier experience.
Original PR description
We extract the update buffer method in order to allow patching. see odoo/enterprise#119702 task-5942777
This PR improves the error logs posted in the chatter when GSTR-1 filing fails. The error message now includes the GST portal error code, error description, and all failing HSN codes. Each HSN code is clickable, allowing users to directly open the related journal items and identify the records that need correction. Previously, only the error code and message were shown. Users had to manually inspect the GST response JSON to find the failing HSN codes and then search for the corresponding j
Original PR description
This PR improves the error logs posted in the chatter when GSTR-1 filing fails. The error message now includes the GST portal error code, error description, and all failing HSN codes. Each HSN code is clickable, allowing users to directly open the related journal items and identify the records that need correction. Previously, only the error code and message were shown. Users had to manually inspect the GST response JSON to find the failing HSN codes and then search for the corresponding journal items. This enhancement makes it much easier and faster to identify and resolve filing issues.
Resolved issues and error corrections
This fix ensures product names stay consistent when purchase and sales documents are created between companies, even when optional product matrix features are installed. It prevents false test failures and reduces the risk of mismatched product descriptions on linked purchase and sales orders.
Original PR description
**Step to reproduce** Reproducible in single app The "name" field make this assertion fails: ``` self.assertRecordValues(sale_order.order_line[0], [{ "product_id":…
**Step to reproduce**
Reproducible in single app
The "name" field make this assertion fails:
```
self.assertRecordValues(sale_order.order_line[0], [{
"product_id": no_variant_product_tmpl.product_variant_id.id,
"name": 'No Variant\nAttribute: Value 1',
```
**Observation**
The name will not be the same depending which app are installed, purchase_product_matrix, changes the name of the product if there is a attribute value of a never variant: https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase_product_matrix/models/purchase.py#L168-L174 Which will be passed to the purchase_order_line:
https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase/models/purchase_order_line.py#L630-L634 that will pass the information to the sale order:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L114 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L125-L126
**Additional information**
Since this [commit](https://github.com/odoo/odoo/commit/b8ebb26553f8170061debc7532606fd4777f0fcd#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56ab50334a1d7db9ef4224R90) product_no_variant_attribute_value_ids was directly added in the purchase module.
breaking commit : https://github.com/odoo/enterprise/commit/bf286a0005b8e22ffa717419cd2dfacff861a265
runbot-242362Calendar event descriptions now only show contact details when there is exactly one attendee besides the organizer. This prevents group meetings from displaying an arbitrary attendee as the contact, reducing confusion for users reviewing event notes.
Original PR description
When a calendar event has multiple attendees, `_get_contact_details_description` picks the first non-organizer partner from a set-based recordset to render under "Contact Details" in the event description. The recordset is built from `partner_ids_from_attendees`, a set whose iteration order depends on Python's hash seed, so the displayed contact is effectively random and not controllable from the UI. Restrict the "Contact Details" block in `_get_contact_details_description` to events with exactly one non-organizer attendee (1-on-1 meetings). For group meetings the block is omitted entirely, since any single attendee picked from a larger group is arbitrary by construction. Steps to reproduce: 1. Go to Calendar > New 2. Add 3+ attendees (e.g. Alice, Bob, Charlie) 3. Save the event 4. Check the Notes tab in the event form => One random attendee's contact info appears under "Contact Details" Ticket [link](https://www.odoo.com/odoo/project.task/6035192) opw-6035192
The chat status now shows the correct out-of-office return date for users in negative time zones. This prevents employees from seeing an incorrect day when checking a colleague's availability in Discuss.
Original PR description
Issue: ---------------------------------------- When in a negative timezone, the "Out of Office until..." text in discuss shows the day before. Steps to reproduce:…
Issue: ---------------------------------------- When in a negative timezone, the "Out of Office until..." text in discuss shows the day before. Steps to reproduce: ---------------------------------------- - Change the timezone of the user to "America/Toronto" for example - Have an employee currently on leave until tomorrow - Open discuss to chat with this employee - The "Out of Office until..." shows today's date Cause: ---------------------------------------- When calling `toLocaleString()` without a timezone specified in the options, the date is converted to local time (in the browser's timezone). Here `persona.out_of_office_date_end` is just a date, `deserializeDateTime()` converts it to a timestamp, so the same day at 0am. Then if the timezone is negative, the timestamp becomes an hour the previous day when calling `toLocaleString()`. The format we give `DateTime.DATE_MED` doesn't include hours, so we just display the previous date. Solution: ---------------------------------------- Add `timeZone:"UTC"` in the options to avoid the timezone conversion. opw-6252040 Forward-Port-Of: odoo/odoo#268631 Forward-Port-Of: odoo/odoo#267479
Affiliate tracking links in the online shop now correctly assign the referenced user as the salesperson on new sales orders. This helps businesses credit the right person for ecommerce orders and improves sales attribution accuracy.
Original PR description
[FIX] website_sale: affiliate_id key in url query does not used in _prepare_sale_order_values to update the salesperson Description of the issue/feature this PR addresses: when used affiliate_id in query string like that https:/odoo.com?affiliate_id=500 user with id 500 does not added to the sale order when a user tries to make an order through the website Current behavior before PR: user access the odoo ecommerce through https:/odoo.com?affiliate_id=500 and existing user with id 500 does not added to salesperson in sale.order Desired behavior after PR is merged: user with id 500 should be added to the sale order as a salesperson --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website page slugs now keep separators such as slashes as word boundaries instead of silently removing them. This prevents URLs or page names like "foo/bar" from being compressed into confusing text and restores the expected readable format, such as "foo-bar".
Original PR description
After Unicode slug support was introduced in https://github.com/odoo/odoo/commit/926e45aa93ffc3f74fe9bf4ae8f06642976c2ae5, `/`
characters started being silently removed instead of treated as
slug boundaries.
As a result:
"foo/bar" -> "foobar"
while it should instead generate:
"foo/bar" -> "foo-bar"
This restores the previous behavior by treating each non word character
as separators normalized to `-`.
task-6219984
Forward-Port-Of: odoo/odoo#264557The accounting module now skips unnecessary sequence gap checks when an accounting entry has no assigned number yet. This reduces avoidable database work and helps keep accounting operations responsive without changing user-facing behavior.
Original PR description
Commit odoo/odoo@1789308 introduced a new way to check for sequence gaps in account moves. Forward-ported revisions of this change include this early return to avoid some queries (and the inner method is itself there to prevent some costlier queries). If the move has no name (or the default '/'), there is no sense in checking for gaps anyhow - it has no number at all. In addition, calling `_get_sequence_format_param` instead of `_get_next_sequence_format` avoids queries (since it is obtained from the journal and cached, and not checking the previous move every time) as well. Task-5253768
Fixes an issue in Email Marketing templates where images next to long text could be stretched and cropped. Images now keep their natural shape, making marketing emails look cleaner and more professional.
Original PR description
The media list snippet forces the image to fill the height of its row. The image column carries align-self-stretch and the image carries h-100, so when the text next to the image is longer than the…
The media list snippet forces the image to fill the height of its row. The image column carries align-self-stretch and the image carries h-100, so when the text next to the image is longer than the image is tall, the row grows to fit the text and the image is stretched to that height (and cropped through object-fit: cover). The longer the text, the more the image is distorted. Drop h-100 from the image and align-self-stretch from its column in the s_media_list snippet and in the mass_mailing_themes templates that reuse it. With no forced height the image keeps its natural aspect ratio and the row height follows its content, so the image is laid out next to the text instead of being stretched to match it. Steps to reproduce: 1. Open Email Marketing and create a new mailing. 2. Select the Blogging template for the mail body. 3. In a media item, replace the text next to an image with a very long paragraph. => The image is stretched and cropped to match the height of the text. Ticket [link](https://www.odoo.com/odoo/project.task/5117571) opw-5117571 Forward-Port-Of: odoo/odoo#238138
This fix updates how Odoo prepares and combines PDF pages so it works cleanly with newer PDF software libraries. It helps prevent document generation warnings and potential failures when producing PDFs such as reports or letters.
Original PR description
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's…
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors. This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow: 1. Add the unmodified source page directly to the `PdfFileWriter`. 2. Retrieve the newly created, writable output page. 3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page. [^1]: https://github.com/py-pdf/pypdf/pull/3638 [^2]: https://github.com/py-pdf/pypdf/pull/3669 Forward-Port-Of: odoo/odoo#268865 Forward-Port-Of: odoo/odoo#267958
Timesheet kanban cards now display the correct employee avatar for users who do not have HR access rights. This avoids confusing placeholder images and makes timesheet entries easier to recognize at a glance.
Original PR description
Steps to reproduce:
- Install the hr_timesheet module
- Create a user without HR access rights
- Create a timesheet
- Log in with the above user
- Open the kanban view
Issue:
Instead of showing the employee's avatar, a placeholder image
is displayed.
Reason:
The user does not have access to the hr.employee model.
Fix:
In this commit, if the user does not have access to hr.employee,
we fetch the image from the hr.employee.public model.
Task: 4461272
X-original-commit: b3018b1ab4bcdfebd8bb83bad38209b96646da3c
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#269262This fix ensures employee salary distribution details are recalculated when bank accounts are archived or restored. It helps payroll information stay accurate after account status changes, reducing manual corrections and payment setup errors.
Original PR description
When archiving or unarchiving bank accounts, salary distribution map is not recomputed. Task-6180142
This update resolves an issue where thumbnails weren't generated when attaching documents to messages within the Composer. The fix ensures that thumbnails are correctly created, improving the user experience when sharing documents. This enhancement aligns with our goal of providing a seamless and functional communication platform.
Original PR description
When attaching a documents to a message in the composer, the thumbnail was not generated. This commit fix this issue. Task-5096039
This update ensures that tax details are now included in test orders sent to UrbanPiper. Previously, test orders lacked this crucial information, leading to potential issues with order processing. This change resolves a technical issue and improves the reliability of our integration with UrbanPiper.
Original PR description
Commit 1: ======== Before this commit: =================== - Test orders sent to UrbanPiper did not include tax details for order items. After this commit: ================== - Tax details are now included in the order item payload of test orders. Task-6013007 --- Commit 2: ======== Cause: ====== In the `without demo` environment, the discount product does not have any `taxes_id`, causing the test assertion to fail. Fix: ==== Set a tax on the discount product in the test to ensure the same behavior in both `with demo` and `without demo` environments. Error-241138 Forward-Port-Of: odoo/enterprise#119764 Forward-Port-Of: odoo/enterprise#109958
This update fixes an inconsistency in how accrual entries are created. Previously, the default accrual date in the Bill to Receive view was the current date, which was incorrect. Now, accrual dates will default to the last day of the previous month, aligning with the standard process for Purchase Order accruals.
Original PR description
Problem: When creating accrual entries using the "Create Accrual Entries" button in the Bill to Receive view in Accounting, the accrual date is defaulted to the current date which is not the expected…
Problem: When creating accrual entries using the "Create Accrual Entries" button in the Bill to Receive view in Accounting, the accrual date is defaulted to the current date which is not the expected behavior. Purchase Orders' accrued entries' date should be the last day of the previous month since it necessarily concerns a bygone period. On the other hand, the expected behavior can be seen when creating accrual entries from a PO's page using the "Accrued Expense Entry" action button. This creates inconsistency among the two ways of creating accrual entries. Steps to reproduce: 1. Go to Accounting > Review > Bill to Receive 2. Select a PO line and click on "Create Accrual Entries" 3. Notice how the date is the current date (wrong behavior) 4. Now go to the same PO's page and click on "Accrued Expense Entry" action button 5. Notice how the date is the last day of the previous month (expected behavior) Inspired by: https://github.com/odoo/odoo/commit/25f26acc05acb73d998560e0e9797fb14473a31f opw-6205947
This update fixes a warning related to how Odoo handles PDF merging using the PyPDF library. The change ensures stability and prevents potential errors by adjusting the order of operations when modifying PDF pages, improving the reliability of document generation. This impacts the sign module.
Original PR description
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's…
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors. This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow: 1. Add the unmodified source page directly to the `PdfFileWriter`. 2. Retrieve the newly created, writable output page. 3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page. [^1]: https://github.com/py-pdf/pypdf/pull/3638 [^2]: https://github.com/py-pdf/pypdf/pull/3669 Forward-Port-Of: odoo/enterprise#119694 Forward-Port-Of: odoo/enterprise#119239
This update fixes an issue where the shop floor displayed excessive decimal places for component quantities, leading to inaccurate readings. The change prevents floating-point precision errors during quantity calculations, ensuring more reliable data display for finished goods. This improves the accuracy of shop floor reporting.
Original PR description
**Issue** In the shop floor, floating-point values may display excessive decimals. **Steps to reproduce** - Create a BoM for a product, with a component tracked by lots - Set the component to be…
**Issue** In the shop floor, floating-point values may display excessive decimals. **Steps to reproduce** - Create a BoM for a product, with a component tracked by lots - Set the component to be consumed in a work order operation - Create several lots for the component, per ex 2: - LOT01 with 16.528 units - LOT02 with 10,000.00 units - Create an MO for 220.800 units of the finished product - Click on the shopfloor icon - Click to register the component consumption for the component. - Choose the first lot - Then choose the remaining units from the second lot -> This will display the quantity consumed as 220.79999999999998, even if the decimal accuracy is set to only 2 digits. **Cause** Since, there are 2 `moveLines`, one for each lot, the getter `quantityDone` add 2 floating point together: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L63-L69 inducing a floating-point precision error. The result is rendered directly in the XML template: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.xml#L8-L14 without rounding. opw-6243804
This update corrects a bug in the website editor for renting products. Previously, removing the quantity field caused an error. This fix ensures the system handles scenarios where the quantity field is not present, preventing the error and maintaining functionality. This change was introduced in version 19.0.
Original PR description
Before this commit, the function below assumes `this.el.querySelector("input[name='add_qty']");` will always be present but you can change this in the website editor.
https://github.com/odoo/enterprise/blob/c1d47899c90fcfa426e1863887111d3ea9f6f15e/website_sale_renting_planning/static/src/interactions/website_sale.js#L18-L39
Steps to reproduce issue:
Runbot 19.0
Open renting -> Products
Select a product (preferably one created by default runbot setup) Click the smartbutton to go to this products web page Open the website editor
Click Edit
Under the styles tab, de-select the quantity field See error message
**Only happens in 19.0**
Introduced in https://github.com/odoo/enterprise/commit/89962571c246caf05e669bb63ad933e67e74ab61
[Ticket](https://www.odoo.com/odoo/project/49/tasks/6294612)
opw-6294612This update resolves an issue where unnecessary code was inadvertently carried over during the port of a previous feature. The fix ensures the l10n_pe_reports module aligns with the requirements of Odoo Enterprise version 19.0, streamlining the reporting functionality for Peruvian users.
Original PR description
During the FW port of https://github.com/odoo/enterprise/pull/117891 We forgot to remove the unnecessary code opw-5978673
This update resolves a technical issue that caused the account reports audit tour to fail in complex Odoo environments. Specifically, the tour now waits for the Kanban view to be active before opening the necessary reports, preventing a premature trigger and ensuring a smoother user experience.
Original PR description
The account_reports_audit tour was failing at the "Balances" button step due to a race condition in the preceding steps. In environments with many modules, the "Open the working file" step was triggered prematurely while still on the return checks view, because its selector was too broad. This commit narrows the selector for "Open the working file" to ensure it only triggers once the Kanban view is actually active. [runbot-938920](https://runbot.odoo.com/odoo/runbot.build.error/938920)