Daily updates from Odoo
Monday, June 15, 2026
16 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where attendees received duplicate emails when rescheduling meetings. The fix prevents a nested calendar event write, which was causing the duplicate notifications. This ensures attendees only receive one email notification for meeting date changes.
Original PR description
Steps to reproduce: 1. Install CRM, Calendar, and Contacts. 2. Create a contact with an email address you can receive emails on. 3. Configure an outgoing email server. 4. Open a CRM lead and create a…
Steps to reproduce: 1. Install CRM, Calendar, and Contacts. 2. Create a contact with an email address you can receive emails on. 3. Configure an outgoing email server. 4. Open a CRM lead and create a meeting activity using the calendar. 5. Add the created contact as an attendee of the meeting. 6. Return to the lead and click the Reschedule button on the activity. 7. Select the same meeting and change its start date to a future date. Issue: - Attendees receive the meeting date-change email twice. Root cause: - When a calendar event linked to an activity is rescheduled, the event write syncs the new start date to the related activity through `_sync_activities`. That activity write was not marked as calendar-originated after commit https://github.com/odoo/odoo/commit/bc090486bd7810b1b0af1bae398255a2d6615f09, so `mail.activity.write` treated the updated deadline as an activity-originated change and wrote back to the same calendar event. https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/calendar_event.py#L779 https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/mail_activity.py#L24-L33 - This created a nested calendar event write. Both the nested write and the original write then triggered attendee date-change notifications, resulting in duplicate emails. Solution: - Pass the existing `calendar_event_meeting_update` context flag when syncing calendar event changes to linked activities. This prevents the activity sync from writing back to the event while preserving activity-to-event rescheduling. opw-6209956 Forward-Port-Of: odoo/odoo#266675
This update addresses a misleading message appearing in self-order takeout/delivery emails. Due to recent code changes, emails were being sent before payment processing, leading to the incorrect 'Attached you will find you receipt' mention. To avoid confusion, this fix removes the mention until the receipt can be reliably rendered.
Original PR description
Currently, when takeout and delivery mails are sent out to clients the mention "Attached you will find you receipt" can be seen. Since this commit https://github.com/odoo/odoo/commit/a0b567508ffeb572a3c36bf28ae085d766d95f18 we now send the email only from the backend but the receipt cannot be rendered from the backend so we're never able to send it. We were aware of this limitation at the time and decided to go forward with it. It was better than havin no mail sent. At that time the mail was sent prior to the order being paid so we wouldn't see the "Attached you will find you receipt" message anyway. Recently the code has been update to send the mail after the payment was processed so the mention appears. Since it can be misleading we'll remove the mention for now. opw-6197985 Forward-Port-Of: odoo/odoo#266004
This update ensures that prettified links in portal chatter messages remain functional after a page refresh. Previously, a refresh would break these links. The fix involves sending the correct thread name to ensure the links are properly formatted and displayed to users.
Original PR description
Before this commit, a message link posted on a portal chatter would lose it's prettified link (introduced in [1]) upon page refresh. This happens because `prepareMessageBody` needs the thread's `displayName` to create the prettified message link, which is not sent on portal chatter init. This commit fixes the issue by sending the thread's `display_name`. [1] https://github.com/odoo/odoo/pull/221069 task-6204819 Forward-Port-Of: odoo/odoo#263488
This update resolves an issue where the 'Download' button for EDI documents was failing to provide the correct XML file when Carvajal encountered an error. The fix adds a necessary callback to generate the XML content, ensuring users can now successfully download the required EDI documents.
Original PR description
When Carvajal returns an error, the EDI document is created with the XML attachment correctly stored in attachment_id. However, the Download button in the EDI Documents tab uses the computed field edi_content, which internally looks for an 'edi_content' callback in _get_move_applicability(). Since l10n_co_edi never provided this key, the computed field always returned empty bytes, resulting in an empty file download. Add the edi_content callback pointing to _l10n_co_edi_generate_xml so the Download button serves the actual generated XML. The "Download" button returns an empty file instead of the generated XML sent to Carvajal. <img width="1376" height="765" alt="Captura de pantalla 2026-06-11 a la(s) 12 21 55 p m" src="https://github.com/user-attachments/assets/ac1b6e85-e67d-4021-8d9c-07a03a390245" /> Forward-Port-Of: odoo/enterprise#120320
This update fixes a bug where the Assistant wasn't displaying suggestion icons for certain activities like 'Working on task'. The fix ensures the Assistant correctly identifies activity types, allowing the icons to appear and provide users with helpful suggestions. This improves the Assistant's usability and functionality.
Original PR description
- When the Assistant detected activities such as 'Working on task', the suggestion icon was not displayed because the event type was not assigned. Unlike `aw.rule` matches, the Odoo URL resolver only set the label and related record information, but did not set the activity type required by `getIcon()`. - Expose the activity type through `get_assistant_data` and assign the activity type when resolving model URLs in extractWatcherActivity. task-6259793
This update corrects a potential issue in the Swiss payroll module where users could incorrectly request refunds on payslips. Swiss payroll regulations limit payments to one per month, so the system now directs users to cancel and re-create the payslip for accurate corrections. This ensures compliance with Swiss tax laws.
Original PR description
Prevent refunds for CH payslips since only one payslip per month is allowed for Swiss payroll. Users should cancel the payslip and create a new one to apply corrections. task-5951981 Forward-Port-Of: odoo/enterprise#107943
This update resolves an issue where bank statement imports were incorrectly multiplying amounts by 100. This was caused by a double-parsing of debit and credit fields when both the bank statement extraction and import modules are active. The fix ensures the correct amount is parsed the first time, preventing this inaccurate result.
Original PR description
Steps to reproduce --- 1. With Accounting installed, import a bank statement CSV that has separate Debit and Credit columns using number separators (e.g. a line with "1.234,56"). 2. Map the columns…
Steps to reproduce --- 1. With Accounting installed, import a bank statement CSV that has separate Debit and Credit columns using number separators (e.g. a line with "1.234,56"). 2. Map the columns to Debit and Credit and import. The imported amounts are multiplied by 100: "1.234,56" is imported as 123,456.00. Issue --- This only happens when both `account_bank_statement_import_csv` and `account_bank_statement_extract` are installed, which is the default in any Accounting database since both modules are auto-installed. `account_bank_statement_extract` turns debit and credit into real Monetary fields on `account.bank.statement.line`: https://github.com/odoo/enterprise/blob/af863c5a53d0ab50fe67cb9ea910391d4a1979dd/account_bank_statement_extract/models/account_bank_statement_line.py#L7-L8 Because they are now real fields, the generic importer already converts those columns to floats: https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/base_import/models/base_import.py#L1281-L1285 The CSV statement wizard then parses the same columns a second time: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L92-L93 The first pass correctly reads "1.234,56" as "1234.56", but the second pass sees a lone dot, mistakes it for the thousands separator, strips it, and produces 123456. The wizard now parses debit and credit only when they are virtual fields, so when they are real fields the values parsed by the generic importer are reused instead of being parsed twice. Without `account_bank_statement_extract`, debit and credit exist only as virtual import fields, so the generic importer skips them and the wizard parses them once. That is why the regression stays hidden until the extract module is present. opw-6227083 --- Forward-Port-Of: odoo/enterprise#118979
This update corrects a visual issue where employee profile images were stretched in the Odoo system. The change adjusts the image display to ensure they fit properly within their designated areas, improving the overall user experience. This fix was implemented as part of a broader redesign effort.
Original PR description
Vertical images were stretched due to changes made during the form view's redesign (a58ed7d) and after adding a fixed size (6d40ab9). We've added an `.object-fit-contain` class to fix this issue and a rounded border to make the image's aligned with other similar views. task-5418517 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268027 Forward-Port-Of: odoo/odoo#262033
This update corrects a bug in how Odoo retrieves products by name, specifically when importing data from UBL invoices. Previously, the system incorrectly associated products based on partial name matches, leading to inaccurate product assignments. This fix ensures correct product identification during import processes.
Original PR description
**PROBLEM** When retrieving a product by name, there is no cache_key for the search_method criteria. This leads to the cache_key frozendict being an frozen dict with None values. This means, once we retrieve a first product with the search_method criteria, all following product will match its cache_key, so we ends up associating a product to all subsequent lines, even if they don't have anything in common. **STEP TO REPRODUCE** 1. Create a product with the name: "CASTELTORRE MERLOT DELLE VENEZIE 75CL 10,5i" (it's important the name is not exactly matching) 2. Import the xml which is attached to the bug fix ticket. 3. Notice the product column on all the lines after a certain point have the CASTELTORRE product, even though the corresponding line in the ubl is for another product. opw-6227280 Forward-Port-Of: odoo/odoo#265987
This update ensures that overtime hours recorded in the system are accurately recognized as additional working time. Previously, these hours weren't being fully accounted for, leading to potential discrepancies in payroll and reporting. This fix improves the accuracy of time tracking and payroll calculations.
Original PR description
make sure that Overtime Hours entries is concidered as extra hours Task: 6279514 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269539
This update resolves a technical issue where the Urbanpiper order information screen incorrectly displayed customer details even after the customer was removed. The fix ensures that customer information is only shown when a customer is actually linked to the order, improving the user experience and preventing error messages.
Original PR description
Steps to reproduce: ==== - Place an order through Urbanpiper. - Edit the order and remove the customer. - Open the ticket screen and click the info button. - A traceback occurs. Cause: ==== - Customer details were rendered even when no customer was linked to the order. Fix: ==== - Display customer details only when a customer is present on the order. task-6233812 Forward-Port-Of: odoo/enterprise#120290 Forward-Port-Of: odoo/enterprise#118147
This update fixes an issue where the tags container overlapped with the header on the sign page due to longer translated strings. The changes automatically adjust the container's position and reduce its height, ensuring a clean and consistent layout regardless of translation lengths. This improves the user experience for all users.
Original PR description
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and…
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings. - Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position. - Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements. - This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations. 19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486 Before fix: <img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" /> After fix: <img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" /> Forward-Port-Of: odoo/enterprise#118937
This update resolves a bug that occurred when grouping financial reports by account code. The issue was caused by comparing numerical and string values, leading to a crash. The fix ensures account codes are treated as numbers during sorting, improving the stability of financial reporting.
Original PR description
If you're grouping by account_code on a line using an account_code
engine, and there's a None value, it will crash.
To get that, you can (with demo data):
- install l10n_be
- set "BE Company COA" as the main, keeping "My Company (San Francisco)"
activated
- go to the profit and loss "Profit and Loss (Abbr) (BE)", set the date
as the current year
- set "Consolidation" filter
- Unfold "60/61 - Goods for Resale,..."
```
Traceback (most recent call last):
...
File "... in _compute_formula_batch_with_engine_account_codes
results_list.sort(key=lambda x: math.inf if x[0] is None else x[0])
TypeError: '<' not supported between instances of 'float' and 'str'
```
Because in case of `None`, we compare with `math.inf` but the account
codes are string.
no-taskThis update ensures website configuration consistently generates necessary snippet templates, particularly when using eCommerce themes. Previously, a configuration error caused a retry, leading to duplicate menu items. Now, templates are created proactively, resolving the issue and improving website build stability.
Original PR description
Steps to reproduce: - Start from a database where the eCommerce app is not installed. - Open the website configurator. - In the first step, choose "I want an eCommerce". - In the Pages and Features…
Steps to reproduce: - Start from a database where the eCommerce app is not installed. - Open the website configurator. - In the first step, choose "I want an eCommerce". - In the Pages and Features step, select all Pages. - Select a theme that adds an eCommerce category snippet, for example "Treehouse". - Build the website. => During the first `configurator_apply`, `website_sale` is installed after the theme and the configured menu items are already created. => The homepage rendering then needs a `website_sale` configurator snippet template requested by the theme, but it was not generated during that first call. => The client retries `configurator_apply`. It now succeeds because `website_sale` is fully installed, but page and menu creation runs again and duplicates the menu items. Before this commit, primary snippet template generation only read the manifest of the module being generated. When `website_sale` was installed from the first `configurator_apply`, it did not see addon snippets declared by the already installed theme. The first call could therefore fail while rendering the homepage after pages and menus were created. After this commit, generation also reads installed theme addon snippets that target the module being generated. The `website_sale` configurator templates requested by the selected theme are created before the first homepage rendering, so `configurator_apply` does not retry after creating menu items. task-5973739 Forward-Port-Of: odoo/odoo#261022
This update resolves an issue where the version timeline widget was causing performance slowdowns by unnecessarily reloading the entire page. The fix replaces a delayed refresh with a more efficient method of triggering a data update, resulting in faster and smoother version tracking. This improves the user experience when managing different versions of data.
Original PR description
A useEffect was added to clear the cache of the versions in case of generation or removal of versions. This is not the best as it waits for everything to be rendered and applied to the DOM to trigger a reload. The alternative is to add a context to the widget and to the orm.searchRead, to trigger a cache miss on version change. task-6289891 Forward-Port-Of: odoo/odoo#269089
This update fixes a visual issue where debit notes generated in Odoo were incorrectly labeled as 'INVOICE DINV...' in downloaded PDFs. Now, the PDF title clearly identifies the document as a 'DEBIT NOTE DINV...', ensuring invoices and debit notes are easily distinguishable. This improves clarity and accuracy for users.
Original PR description
### Steps to reproduce the issue: 1. Download Invoice and Debit Notes 2. Go to an invoice (or create a new one) 3. Create a debit note for that invoice and print it or send it 4. In the PDF the title is 'INVOICE DINV....' instead of 'DEBIT NOTE DINV...' ### Reason to introduce the fix: Differentiate debit notes from invoices. opw-6252239 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268207