Daily updates from Odoo
Thursday, May 21, 2026
65 changes · saas-19.3
New functionality added to Odoo
This update introduces a new module, 'obox,' designed to connect Odoo to hardware devices similar to the existing Odoo FDM system. The initial step allows the system to recognize and record the IP address and available services of an Obox device, paving the way for future device interaction.
Original PR description
The Obox (same platform as the Odoo FDM for Belgium) will allow interfacing with hardware devices, and is intended to replace the functionality of the IoT box. This commit only adds the ability to pair an Obox to the database, and see its IP and available services. Enterprise https://github.com/odoo/enterprise/pull/110834 Forward-Port-Of: odoo/odoo#254208
This update introduces a new module, 'obox,' designed to connect with Obox devices – similar to the Odoo FDM for Belgium. The initial phase focuses on allowing users to register and view basic information about their Obox, including its IP address and available services, laying the groundwork for future device interaction.
Original PR description
The Obox (same platform as the Odoo FDM for Belgium) will allow interfacing with hardware devices, and is intended to replace the functionality of the IoT box. This commit only adds the ability to pair an Obox to the database, and see its IP and available services. Community: https://github.com/odoo/odoo/pull/254208 Forward-Port-Of: odoo/enterprise#110834
Enhancements to existing features
This update simplifies the calculations for 'Retained Earnings' and 'Result for the Year' on the French Balance Sheet report. This change ensures the financial reporting is more accurate and reliable for French-speaking businesses using Odoo Enterprise. It's a routine improvement to maintain the integrity of financial data.
Original PR description
Simplify the formulas of 'Retained earnings' and 'Result for the year' in the french Balance Sheet. task-6087994 Forward-Port-Of: odoo/enterprise#113988 Forward-Port-Of: odoo/enterprise#112731
This update adjusts the categorization of certain French accounting accounts (110000, 119000, 120000, 129000) to better align with reporting requirements for 'Current Year Earnings'. This change ensures accurate financial reporting in France and improves compliance with local accounting standards.
Original PR description
Change the type of french accounts 110000, 119000, 120000, 129000 for 'Current Year Earnings'. task-6087994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259374 Forward-Port-Of: odoo/odoo#257094
This update enables users to reset statement lines directly within the Kanban view, mirroring functionality from previous versions. This prevents the need to manually delete multiple reconciliations from a single line, streamlining the accounting process and improving efficiency.
Original PR description
This commit adds the possibility to reset a statement line in kanban view like in the previous versions. Function is still there but no UI button was tied to it. This is a problem if you have many reconciliations on one statement line, we do not want to delete them one by one. opw-6015838 Forward-Port-Of: odoo/enterprise#111107
This update simplifies email notifications in Odoo by making the subject field optional when sending emails from comment mode. Previously, a subject was always included, but this change streamlines the process for simpler notifications. This improves the user experience and reduces unnecessary complexity.
Original PR description
In comment mode we use the regular message post flow rather than the optimized batch email creation of the composer. This notably means a fallback subject will normally be set. The subject is made optional in that context, and only mandatory in batch mode where the emails would otherwise truly not have a subject. task-5944635 Forward-Port-Of: odoo/odoo#261918
This update enhances the user experience for warehouse staff who frequently use tablets to view transfer lists. The changes improve the visibility of key information like reference IDs and contact details, ensuring they are easily readable on medium-sized screens. This addresses a usability issue for a common workflow.
Original PR description
Devices with medium screen sizes such as tablets are often used in warehouses. However, when we check a transfer list view, we can not read clearly important info such as reference or contacts because fields are not entirely displayed. Task-id: 6030156
Resolved issues and error corrections
This update corrects a problem where the ABA file generated for Australian payroll wasn't being created correctly. The fix ensures the payslip batch is assigned before payment validation, guaranteeing the ABA file contains accurate payment information. This resolves a previous issue and improves the reliability of payroll reporting.
Original PR description
Payslip batch needs to be assgned before the payment batch is validated, otherwise the ABA file will be blank. This commit ensures that flow and the test ensure both aba flows generate the same file content. task-6123029 Forward-Port-Of: odoo/enterprise#116907 Forward-Port-Of: odoo/enterprise#114970
This update resolves an issue where users could trigger an error when entering spaces in the 'Forecasted Demand' or 'Forecasted Stock' cells within the Master Production Schedule. The fix ensures that blank input is handled correctly, preventing the error and maintaining data integrity.
Original PR description
## Steps to Reproduce:
1. Install `mrp_mps` module.
2. Manufacturing > Planning > Master Production Schedule
3. Click on "Forecasted Demand" or "Forecasted Stock" of any product.
4. Click `<SPACE>` and then `<ENTER>`.
## Error:
`ValueError: could not convert string to float: ' '`
## Cause:
When a user enters whitespace(' ') in a **Forecasted Demand** or **Forecasted Stock** cell, the string bypasses the existing `isNaN/empty` checks at [1]. Then the raw whitespace string passes to the ORM call, where `float(' ')` raised a ValueError.
## Fix:
This commit trims the value so that blank input is treated the same as an empty string, and the cell reverts to its original value.
[1] - https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/mrp_mps/static/src/components/line.js#L128
sentry-7473062917
Forward-Port-Of: odoo/enterprise#117052This update corrects a bug where attendance records were disappearing after a public holiday was added. The issue stemmed from a mismatch between how attendance dates were stored (in UTC) and how they were compared against local timezones. The fix ensures attendance dates are correctly converted to the employee's timezone for accurate reporting.
Original PR description
**Steps to reproduce in runbot:** 1. Install hr_holidays_attendance. 2. Create an employee with a contract start date (e.g., April 1st). 3. Set the timezone(for both user and emp working schedule) to…
**Steps to reproduce in runbot:** 1. Install hr_holidays_attendance. 2. Create an employee with a contract start date (e.g., April 1st). 3. Set the timezone(for both user and emp working schedule) to Europe/Brussels. 4. Create an attendance record (e.g., April 15th). 5. Go to Reporting > Time Off Ledger and remove all filters. -> Attendance is correctly shown for all dates from April 1st 6. Create a public holiday on April 16th starting at 00:00. 7. Check the Time Off Ledger again. **Issue:** The attendance entry for April 15th disappears after adding the public holiday. **Cause:** Calendar leave datetime fields (date_from/date_to) are stored in UTC but compared against attendance dates without converting to the employee's resource calendar timezone, causing date boundaries to shift and records to be incorrectly excluded. https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L133-L144 **Solution:** Convert calendar leave datetimes to the employee timezone before casting to date, ensuring comparisons reflect the correct local boundaries. **NOTE:** This issue is mainly reproducible on runbot since its server timezone is GMT. On local machines configured with UTC, the stored datetime values already align with the expected conversions, so the date shift does not occur. opw-6118043 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265129 Forward-Port-Of: odoo/odoo#262179
This update fixes an error that prevented users from creating new helpdesk teams. The issue occurred when the system attempted to use a default email template after clearing all helpdesk stages. The fix ensures the template exists before attempting to use it, preventing a 'NoneType' error.
Original PR description
Currently, an error occurs when a user tries to create a helpdesk team record. **Steps to Reproduce:** - Install the `helpdesk` module without demo data. - Go to `Settings` > `Technical` > `Email` >…
Currently, an error occurs when a user tries to create a helpdesk team record. **Steps to Reproduce:** - Install the `helpdesk` module without demo data. - Go to `Settings` > `Technical` > `Email` > `Email Templates` and delete the `Helpdesk: Ticket Received` template record. - Go to `Helpdesk` > `Configuration` > `Stages` and remove all records. - Go to `Helpdesk` > `Configuration` > `Helpdesk Teams` and click `New` to create a record. `AttributeError: 'NoneType' object has no attribute 'id'` When the user deletes all stages, the system attempts to create a new stage and assign the "Helpdesk: Ticket Received" mail template to it [1]. However, if this template record does not exist, accessing its id raises the error. This commit ensures that the template record exists before accessing its id, otherwise, None is passed as the default value. [1]: https://github.com/odoo/enterprise/blob/32187f79fb0a595497a5e77db4b22b417b03b8dd/helpdesk/models/helpdesk_team.py#L34 sentry-7482994877 Forward-Port-Of: odoo/enterprise#117446
This update resolves an issue where order synchronization with Lazada was failing due to missing package information. The fix ensures that the system gracefully skips package synchronization when package data is incomplete, preventing errors and maintaining reliable order updates. This improves the stability of the Lazada integration.
Original PR description
orders can omit package data in the API payload if the package id doesn't match. When a picking still had a package_extern_id, filtering order_items by that id produced an empty list, and max() on the resulting timestamps raised ValueError and blocked order sync. Return early when no matching package lines exist so sync can continue. taskId - 6195507 Forward-Port-Of: odoo/enterprise#117194
This update resolves a problem where the Brazilian localization module (`l10n_br`) was incorrectly referencing a field that had moved in a recent upgrade. The change ensures the module correctly pulls data from the updated address form fields, maintaining accurate address information for Brazilian users. This update is a critical fix to prevent potential data inconsistencies.
Original PR description
Issue: ------ `l10n_br.address_form_fields` inherits from `portal.address_form_fields` but targets a `<select>` element that was moved to `portal_address_extended.address_extended_form_fields` in…
Issue: ------ `l10n_br.address_form_fields` inherits from `portal.address_form_fields` but targets a `<select>` element that was moved to `portal_address_extended.address_extended_form_fields` in [saas~19.2]. Traceback: ---------- ```py Error while parsing or validating view: Element '<xpath expr="//select[@name='city_id']/option[not(@value='')]">' cannot be located in parent view ``` Steps to reproduce: ------------------- 1. Install `l10n_br` in v19 2. Upgrade to v19.2 3. Upgrade the `l10n_br` module → Traceback Root cause: ----------- The view is adapting an element owned by a sibling view, making the inheritance hierarchy conceptually wrong and fragile. Solution: --------- Update the `inherit_id` of `l10n_br.address_form_fields` to `portal_address_extended.address_extended_form_fields` so it correctly inherits from the view that owns the targeted element. opw: [6125901] [saas~19.2]: https://github.com/odoo/odoo/commit/026c6f9f2a388ee509a135c53e38f5bb3d08ff73 [6125901]: https://www.odoo.com/odoo/70/tasks/6125901?debug=1 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#264045
This update fixes a minor issue in the demo order system for point-of-sale and restaurant POS. Previously, demo orders used a default '/' reference, which is now replaced with sequential order numbers for clarity. This ensures demo orders are more easily identifiable and consistent.
Original PR description
Before this commit: =================== - For demo orders, no proper Order Reference is displayed, by default, it is set to '/'. After this commit: =================== - All default '/' values are replaced with a sequential Order Reference, except for orders in the 'new' state . Task-6004716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264971 Forward-Port-Of: odoo/odoo#253272
This update resolves an issue where users couldn't edit dates within the blog section due to a missing plugin configuration. The fix ensures the `DateTimeFieldPlugin` is correctly included in the necessary Odoo lists, allowing for proper date field editing and preventing potential save errors. This improves the user experience for blog content management.
Original PR description
The plugin `DateTimeFieldPlugin` was only added in registry `builder-plugins`. But it should also be included in the lists `CORE_PLUGINS` of `html_builder` and `TRANSLATION_PLUGINS` of `website` (the same as `MonetaryFieldPlugin` and similar plugins) Steps to reproduce: - Open `/blog` in translate mode - Click on a date - Bug: you can edit the text (and it will likely cause an error on save) task-6226376 Forward-Port-Of: odoo/odoo#265400 Forward-Port-Of: odoo/odoo#264943
This update optimizes how Odoo records information from bank statements, making the process faster and more efficient. By using a batch logging function, the system now handles transactions more quickly, reducing potential delays and improving overall performance. This change was driven by a performance optimization.
Original PR description
There is no need for a full message post to get the details of the transaction. We can use the batched function instead `_message_log_batch`. Forward-Port-Of: odoo/enterprise#117923 Forward-Port-Of: odoo/enterprise#117742
This update resolves a crash issue that occurred when opening dropdown menus on certain pages (like the `/r` page). The fix ensures the menu is fully loaded before attempting to observe it, preventing a technical error that previously caused the dropdown to fail. This improves the overall stability and usability of the system.
Original PR description
Steps to reproduce: - Go to the `/r` page. - Click a dropdown. => traceback Before this commit, `Dropdown.onOpened()` always observed `menuRef.el` as soon as the popover reported it was open. In frontend pages such as `/r`, the menu can still be rendering at that moment. The menu appears just after, but `MutationObserver.observe()` already received `undefined` and raised a `TypeError`. After this commit, `Dropdown.onOpened()` only starts the observer when the menu element exists. The dropdown can finish opening normally, so the menu is shown without traceback. Introduced by [1]. [1]: 7aed5b141f06 Forward-Port-Of: odoo/odoo#265224
This update fixes an error in the WPS payroll report generation process. Specifically, it ensures the report accurately reflects payment dates and values, preventing potential discrepancies when generating the WPS file. This improves the reliability of payroll reporting for Saudi Arabia.
Original PR description
In this commit, we: - corrected the tooltip description of `l10n_sa_wps_value_date`; - added back the Debit Date to the WPS file and assigned it the value of the `effective_date`; - added back the user error in case the Payment Date is greater than or equal to the Value Date. TaskID-6130969 Forward-Port-Of: odoo/enterprise#115762
This update resolves an issue where the skill addition form in Odoo 19.3 would freeze when using 'Save & New'. The fix ensures the form correctly retrieves and updates data, preventing this freezing behavior and guaranteeing the badges many2one field functions reliably.
Original PR description
Issue: - Since 19.3, using "Save & New" while adding skills could freeze the subsection in forms using the badges many2one field. - The component was relying on `record` and `field` values captured during setup, which became stale after the form state was recreated. Fix: - Updated the special data hook to read `record`, `name`, and related field values directly from hook props instead of setup-scoped values. - Updated `useSelectCreate` to dynamically retrieve the relation from current props. Impact: - Prevents the skill subsection from freezing after using "Save & New". - Ensures the badges many2one field always works with the latest record state. Task: 6147646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a formatting issue in the account view, ensuring descriptions are displayed in a dedicated section. Previously, the descriptions were incorrectly adjusted, leading to a less organized view. This change improves the clarity and usability of account information.
Original PR description
Description in account view was incorrectly adjusted in https://github.com/odoo/odoo/commit/d940f3719c09bf1cc21de20f72968e1a34a8a9ac Fixing it to be a dedicated section. task-5376190 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash on the payroll dashboard when users attempted to hide in-memory payrun warnings. The issue stemmed from incorrect data being passed to database functions, leading to an error. The fix ensures warnings are handled correctly, preventing the crash and improving dashboard stability.
Original PR description
Closing date payrun warnings are created as in-memory records (.new()), giving them a NewId instead of a real integer DB id. When the user clicked the hide button, this NewId string was passed to action_snooze/action_archive, causing a psycopg2.errors.InvalidTextRepresentation SQL error. Fix by sending False as the id for in-memory warnings in get_payroll_dashboard_warning_cards, and suppressing the hide button on the dashboard when warning.id is falsy. task-6205849
A previous error prevented users from searching for links within email click tracking. This update resolves the issue by correcting how the system handles link searches, ensuring accurate results when searching by short URL. This improves the reliability of our email marketing analytics.
Original PR description
Overview ------ When searching based on the `Link (short_url)` field in the search bar, in the `link.tracker.click` list view, an error fires up. How to Reproduce ------ 1. Open the Email Marketing…
Overview ------ When searching based on the `Link (short_url)` field in the search bar, in the `link.tracker.click` list view, an error fires up. How to Reproduce ------ 1. Open the Email Marketing app 2. Create a new mailing (or you can use an existing one that has some clicks) and send it 3. Make a click in the email from the recipient's side 4. Open the link tracker `click` related to that mailing (select the mailing → `Link Trackers` stat button → click on a link → `Clicks` stat button) 5. Make a search based on the Link (short_url) field Expected Behavior ------ Return the list of links that matches the entered search query. Current Behavior ------ Odoo Server Error. Cause & Solution ------ The cause of this error is that the `shor_url` field is a computed, non-stored, field, and hence, we cannot directly make a search on it. So, either we make the `short_url` a stored field, which is not so efficient, or we create our own custom `_search_..` method. Task-6131693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265293 Forward-Port-Of: odoo/odoo#260146
This update fixes an issue where certain Italian taxes (INPS and Pension Fund) weren't properly imported from CSV files. The fix ensures these taxes are correctly configured within Odoo, allowing for accurate processing of vendor bills and compliance with Italian tax regulations. This improves the reliability of tax calculations and reporting.
Original PR description
### Issue before this commit: In the previous implementation, several Italian taxes, specifically the 4% INPS and the 4% Pension Fund (F.Pens), were not correctly initialized. Although the relevant…
### Issue before this commit: In the previous implementation, several Italian taxes, specifically the 4% INPS and the 4% Pension Fund (F.Pens), were not correctly initialized. Although the relevant EDI data was present in the source CSV templates, it was missing from the actual tax records in the database. ### Steps to reproduce the issue: 1. Download Accounting and l10n_it_edi 2. Go to Accounting -> Taxes 3. Open 4% INPS tax and 4% F.Pens and go to Advanced Options tab and see that no Pension Fund Type is associated by default ### Cause of the issue: While moving the witholding data from l10n_it_edi to l10n_it in this commit https://github.com/odoo/odoo/commit/40e09ca01242 the templates were not correcly rendered and set up. ### Reason to introduce the fix: For a tax to be correctly recognized from the XML, it is essential that we have the corresponding tax already configured in Odoo, including the specific type. We should have at least these two taxes fully configured so the system can elaborate them correctly when imported from vendor bills. opw-6093221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258947
This update ensures that the customer reference field from invoices is correctly included in the fa3 XML files sent to the Polish tax authority (KSEF). Previously, this information was missing, which could cause processing delays. This fix improves invoice accuracy and compliance with Polish tax regulations.
Original PR description
**STEP TO REPRODUCE** 1. Create an invoice and fill the customer reference field (other info tab). 2. send the invoice to ksef. 3. Open the generated fa3 file, and notice there is no mention of the customer reference. Ticket [link](https://www.odoo.com/odoo/project.task/6150812) opw-6150812 Forward-Port-Of: odoo/odoo#263797
This update resolves an issue where planning tour tests were failing due to a recent change removing a template saving step. The fix also addresses a dependency on the 'planning_field_service' app, which wasn't correctly integrated into the sale planning tour, causing broader test failures. This ensures the planning tours run reliably.
Original PR description
Since fc7b3c2, the "save as template" step of the planning tour was removed, making the test checking for templates in project_forcast fail. The commit also adds a condition checking if planning_field_service is installed before running the planning_test_tour but didn't add it for the sale_planning_test_tour, which extends the planning_test_tour and fails as well if the 3 apps are installed. opw-6176441 runbot-230670 Forward-Port-Of: odoo/enterprise#117882
This update fixes an issue where URLs with mixed or uppercase characters weren't automatically converted to clickable links within the HTML editor. The fix ensures that all URLs, including single-character domains like 'x.com', are correctly recognized and linked. This improves the user experience and allows for more reliable link creation.
Original PR description
### Description of the issue/feature this PR addresses: - URL_REGEX was constructed with the "i" flag, but passing a RegExp object to new RegExp(regex, "g") silently drops the original flags, leaving only "g". This caused uppercase (ODOO.COM) and mixed-case (Odoo.Com) URLs to not be converted to links when pressing space. ### Desired behavior after PR is merged: - URL_REGEX.source with explicit "gi" flags to preserve case-insensitive matching in `prepareConvertToLink`. - Allow automatic URL detection for single-character domains such as `x.com`, `t.co`, and `a.io` by relaxing the minimum domain label length in the URL regex from 2 to 1 characters. task-6199269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265409 Forward-Port-Of: odoo/odoo#263255
This update ensures that the bottom sheet appears consistently on all touch devices, including larger tablets, instead of a less desirable dropdown menu. Previously, the bottom sheet was only displayed on small touch screens. This change provides a more reliable and user-friendly experience for users accessing Odoo through touch interfaces.
Original PR description
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#264973 Forward-Port-Of: odoo/odoo#264705
This update resolves an issue where the Send & Print wizard would fail when proforma PDFs weren't automatically created for invoices. The change ensures the system handles cases where these PDFs aren't generated gracefully, preventing errors and improving the reliability of invoice sending. This primarily affects scenarios involving specific localization modules.
Original PR description
`_generate_and_send_invoices` raises `KeyError: 'proforma_pdf_attachment'` when `_get_invoice_extra_attachments` returns an empty recordset for a move in the `success` dict. The…
`_generate_and_send_invoices` raises `KeyError: 'proforma_pdf_attachment'` when `_get_invoice_extra_attachments` returns an empty recordset for a move in the `success` dict.
The `proforma_pdf_attachment` key is only populated in `_generate_invoice_fallback_documents`, which is called exclusively when `allow_fallback_pdf=True`. However, the code at the return step also triggers when `allow_fallback_pdf=False` (normal wizard path), where the key is never set.
Replace the bare dict access `move_data['proforma_pdf_attachment']` with `move_data.get('proforma_pdf_attachment', self.env['ir.attachment'])` so the flow returns an empty attachment recordset instead of raising a `KeyError` when no fallback proforma PDF was generated.
Fixes: KeyError: 'proforma_pdf_attachment' in account.move.send.wizard Steps to reproduce:
1. Use the Send & Print wizard on a posted invoice
2. Trigger a condition where _get_invoice_extra_attachments returns an empty recordset (e.g. via l10n_vn_edi_viettel with sinvoice files not yet fetched) despite no error being raised
Forward-Port-Of: odoo/odoo#264564This update fixes an issue where updating a manufacturing order (MO) with a multi-level BOM would only create MOs for the immediate child components, missing the next level. The fix ensures that all necessary MOs are created during the BOM update process, preventing incomplete manufacturing operations. This improves the reliability of production planning.
Original PR description
When updating a mo, if the new component has a multilvl bom, it will only create a mo for the direct child and not the next Steps to reproduce: ------------------- * Create a products "Main",…
When updating a mo, if the new component has a multilvl bom, it will only create a mo for the direct child and not the next Steps to reproduce: ------------------- * Create a products "Main", "Final", "Semi", "Raw" * Create a Bom for "Final" with "Semi" as component * Create a Bom for "Semi" with "Raw as component * Add MTO on Final and Semi * Create a MO for Main with no components and confirm it * Add "Final" to the mo as component as save. -> The MO for "Final" is correctly created with "Semi" as component but there is no MO for "Semi" with "Raw" as component. Observation: ------------- When updating de MO, it will write the new SM (Final) to the production, and we will call ```_autoconfirm_production``` with ```no_procurement```: https://github.com/odoo/odoo/blob/6fb69b5640743d3bc7bb52c73cb27da428f2451c/addons/mrp/models/mrp_production.py#L1051 Where we will directly confirm the sm (```_action_confirm```). From the SM ```_action_confirm``` we will create and run a procurement (manufacture in our case). From the manufacture we will create the new move line for Semi and go through ```action_confirm``` on the manufacturing order: https://github.com/odoo/odoo/blob/9ef76a4d6010191ab7ab1a0d1085972901280dda/addons/mrp/models/stock_rule.py#L116-L118 In the MO ```action_confirm```, we will confirm the move and should create new procurement for the moves that need them, but, since in our case we have ```no_procurement``` in the context, we will set ```create_proc``` to false: https://github.com/odoo/odoo/blob/9ef76a4d6010191ab7ab1a0d1085972901280dda/addons/mrp/models/mrp_production.py#L1635 Since ```create_proc``` is false we will not create a procurement for those move lines: https://github.com/odoo/odoo/blob/6fb69b5640743d3bc7bb52c73cb27da428f2451c/addons/stock/models/stock_move.py#L1557-L1558 https://github.com/odoo/odoo/blob/6fb69b5640743d3bc7bb52c73cb27da428f2451c/addons/stock/models/stock_move.py#L1571-L1580 opw-6005675 Forward-Port-Of: odoo/odoo#258153
This update fixes a regression where the color picker in Odoo was not recognizing colors defined using the `color()` function. Following a recent website update, this change restores full functionality, ensuring users can correctly set background colors within the HTML Builder and Editor. This resolves an issue impacting visual customization.
Original PR description
Following the website refactoring (commit 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2) `BuilderColorPicker` no longer recognizes colors defined using `color()`, introducing a regression. This commit restores support for `color()` values. Steps to reproduce: 1. Add the snippet `s_text_image`. 2. Manually, in the DOM, set the style of the first column to "background-color: color(srgb 0.4 0.2 0.8 / 0.4);". 3. In edit mode, click on the column to observe that the colorpicker does not recognize the background color. The same behavior can also be observed in the custom tab. Task: [5453922](https://www.odoo.com/odoo/project/974/tasks/5453922) Forward-Port-Of: odoo/odoo#265443 Forward-Port-Of: odoo/odoo#255331
This update fixes an issue where service products didn't consistently apply user-defined default units of measure. Previously, the default unit was overridden when a product was marked as a service. Now, the system correctly applies the user's preferred unit of measure for all products, including services, ensuring accurate time tracking and invoicing.
Original PR description
A user-defined default on `product.template` Unit is not applied when the product is of type Service 1. Install Sales and Sales Timesheet 2. Go to Settings > Sales > Product Catalog and enable Units of Measure & Packagings 3. Enable debug mode 4. Go to Sales > Products, open a new product form and set unit to Days 5. In the debug menu (bug icon in the top right), select Set Default Values for Unit = Days and save 6. Reload the page 7. Set the type to Service 8. Unit changes from Days to Hours Same issue happens for `product.product` Issue: User default values are overwritten when certain conditions are met by https://github.com/odoo/odoo/blob/6955370fd2d62c83f0ea24247abf7a9e4b4ebed3/addons/sale_timesheet/models/product_template.py#L55-L57 Solution: Use the user defined default on `uom_id` except for service products that are invoiced with timesheets as they need a time unit of measure opw-6139603 Forward-Port-Of: odoo/odoo#262597
This update fixes an issue where Fedex labels were missing a crucial 'REF' field, which is required by the shipping carrier. The fix ensures that all Fedex labels now correctly include this reference, preventing potential delivery delays or errors. This improves the accuracy and reliability of our shipping process.
Original PR description
Issue ----- `REF` field of Fedex labels is missing. Steps to reproduce ----- - Setup Fedex - Create a product (set weight) - Create a delivery for the product - Set carrier as Fedex - Validate…
Issue
-----
`REF` field of Fedex labels is missing.
Steps to reproduce
-----
- Setup Fedex
- Create a product (set weight)
- Create a delivery for the product
- Set carrier as Fedex
- Validate delivery
- Opend the label
> REF field is empty
Cause
-----
When filling the `CustomerReferences`, we only specify the SO
https://github.com/odoo/enterprise/blob/aae680f5b86fa87193ba6616e8431eed985b2ee7/delivery_fedex_rest/models/fedex_request.py#L309-L313
The `REF` field is populated using `CUSTOMER_REFERENCE` references, which is not present in this case.
Excerpt of the API DOC
-----
```
"CustomerReference": {
"type": "object",
"properties": {
"customerReferenceType": {
"type": "string",
"description": [...],
"example": "DEPARTMENT_NUMBER",
"enum": [
"CUSTOMER_REFERENCE",
"DEPARTMENT_NUMBER",
"INVOICE_NUMBER",
"P_O_NUMBER",
"INTRACOUNTRY_REGULATORY_REFERENCE",
"RMA_ASSOCIATION"
]
},
"value": {
"type": "string",
"description": [...],
"example": "3686"
}
}
},
```
[...] replaces long description strings, refer to API for full documentation.
Result after fix
-----
<img width="477" height="738" alt="image" src="https://github.com/user-attachments/assets/0d3a0786-5b7d-41cc-8548-2dc7b0f379ab" />
-----
Ticket:
opw-6101620
Forward-Port-Of: odoo/enterprise#116870This update significantly speeds up the process of finding BOMs for product records, particularly when dealing with large numbers of products. The change optimizes how the system identifies relevant BOMs, reducing processing time and improving overall MRP performance. This results in faster product configuration and order fulfillment.
Original PR description
Before this commit, finding a bom for a recordset of `products` involved looping over all the boms and it will loop over all the `product_variant_ids` of `bom.product_tmpl_id` if the bom's…
Before this commit, finding a bom for a recordset of `products` involved looping over all the boms and it will loop over all the `product_variant_ids` of `bom.product_tmpl_id` if the bom's `product_id` is NULL. This approach might loop over variants which we are not trying to find a bom for. In additon to that, due to the fact that multiple boms might have the same `product_tmpl_id`, this approach might consider the same variants in the inner loop redundantly even though we matched the variant with a bom in a previous itration.
Worst case, this might result in a time complexity of $O(N * M)$ where N is the number of boms and M is the number of variants.
To improve the performance, I only considered the variants given in the paramater `products` and in addition to that, I created a new dictionary mapping a `product_tmpl_id` to its bom if the bom doesn't have a variant set. By doing this, I can loop over the `products` given and if it doesn't have a bom set then it will be set to the one its template had taken from the previos loop.
In a method call with the following constraints
- **2** products the method was finding a bom for
- The 2 products had the same template and the template contained **550** active variants
- The boms were only related to the template rather than the variants themselves.
| Input Size | Before | After |
| :--- | :--- | :--- |
| 100 | 0.78s | 0.03s |
| 1000 | 8.53s | 0.11s |
| 10000 | 80.99s | 0.73s |
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#247465This update resolves an issue that prevented users from successfully duplicating sale orders when the order's company differed from the website's company. The fix ensures that the duplication process handles company discrepancies gracefully, preventing a traceback error and improving the user experience. This ensures sales operations can continue without interruption.
Original PR description
When duplicating a sale order whose company differs from the website's company, a traceback is raised. Steps to reproduce the error: - Install ``website_sale`` module with demo data - Create a new Company A - Select both the companies your company and Company A - Go to Website > eCommerce > Order > Open any order > Other info, change the company from your company to Company A > Save - Actions > Duplicate Traceback: ```py ValueError: The company of the website you are trying to sell from (Hune Specialized International Co LLC) is different than the one you want to use (My Company (San Francisco)) ``` https://github.com/odoo/odoo/blob/ea56382f804e494a86a72dab02a26134ef358c50/addons/website_sale/models/sale_order.py#L165-L171 Here, when the website's company and sale order's company is different, The above traceback will generate. sentry-7465306461 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adjusts the styling of numeric values in account reports to align with the column formatting, creating a more consistent and visually appealing presentation. The change ensures that numeric data within reports is displayed with appropriate padding, enhancing readability and user experience. No new functionality was added.
Original PR description
the following commit slightly modified the styling of reports header by alligning the text on the right for numeric values to match the styling of the values in the column. However, the forward port in 19.3 didn't notice that a small padding was now present in the version. https://github.com/odoo/enterprise/commit/196aa04b301499fdb2ea0769f7f07ff504a46b2b In addition, no class is needed for budget columns since no names are provided. **BEFORE** <img width="776" height="252" alt="image" src="https://github.com/user-attachments/assets/02c9dbb2-ab68-4b81-abb4-08db7f663794" /> **AFTER** <img width="518" height="276" alt="image" src="https://github.com/user-attachments/assets/3fb86584-6699-4b49-b2b9-87685bad0c16" />
This update resolves an issue where long URLs in the CopyClipboardURLField widget would overlap with the associated copy icon, creating a confusing user experience. The fix applies text truncation and adjusts spacing to ensure the full URL is visible while maintaining a clean and functional design.
Original PR description
Currently, when using the CopyClipboardURLField widget, long URL text overflows and overlaps with the adjacent copy/link icon. This commit fixes the issue by applying standard text truncation (`text-truncate`) to the `.o_form_uri` element and restricting its width to account for the adjacent icon. We also take advantage of unused white space to display the most of the link text before the ellipsis. task~6159185
This update resolves an issue where the Odoo tour feature was repeatedly rendering, causing performance slowdowns. The fix prevents an infinite loop by carefully managing state updates, ensuring the tour pointer renders efficiently. This results in a smoother and faster user experience.
Original PR description
Before this commit, the tour pointer entered an infinite loop of rendering because one change in its state triggered DOM mutations on which the tour listen to update the pointer, triggering the rendering of the pointer. This was because of a reactive's state being update too early. After this commit, the number of renderings is limited to a reasonable minimum. 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#265498
This update fixes an issue where recurring plans weren't appearing in quotation reports when using the DIN5008 template for Swiss companies. The fix ensures that recurring plans are always visible in the generated reports, improving accuracy and providing a complete view of subscription details. This resolves a previous reporting discrepancy.
Original PR description
When generating a quotation for a recurring plan, if the quotation uses the DIN5008 template, the recurring plan is not shown in the report. Steps to reproduce: ------------------- * Make sure…
When generating a quotation for a recurring plan, if the quotation uses the DIN5008 template, the recurring plan is not shown in the report. Steps to reproduce: ------------------- * Make sure l10n_din5008 is installed * Create a Swiss company * Go to the subscription app and create an order with a recurring plan * Print the quotation > Observation: The recurring plan is not shown in the report. Why the fix: ------------ We add a new scss rule to make sure the recurring plan is always shown in the report. https://github.com/odoo/enterprise/blob/fb2eb6cfdc4527e102dd22321975ab3f0d24b88b/sale_subscription/views/subscription_templates.xml#L7-L23 Before: <img width="790" height="677" alt="image" src="https://github.com/user-attachments/assets/342753fa-9655-41ac-a958-f94f6ae2b6c7" /> After: <img width="808" height="756" alt="image" src="https://github.com/user-attachments/assets/4ed726c5-0702-48ee-8578-8b0d2c0f4e55" /> opw-5960219 Forward-Port-Of: odoo/odoo#261727
This update fixes a problem where adding rental products to the cart would fail due to mismatched date calculations. The fix ensures that rental product durations are correctly handled, preventing errors when mixing different rental periods. This improves the reliability of the rental product checkout process.
Original PR description
Steps to reproduce: =================== 1. Go to the shop page and use the rental date picker to select a start and end date with hours. 2. Find a rental product configured with "Days" pricing. 3.…
Steps to reproduce: =================== 1. Go to the shop page and use the rental date picker to select a start and end date with hours. 2. Find a rental product configured with "Days" pricing. 3. Add to card directly from the product card 4. Add a rental product from product image that has date type value date 5. Go to that product details page. 6. Click add to cart -> Invalid operation, You cannot mix different rental periods... Cause: ====== When adding a product from the shop list view, the system uses the default start/end dates (from the rental period) exactly as first added. However, the "Add to Cart" logic on the product details page attempts to adapt the selected dates to the product's specific rental unit (e.g., normalizing the time component for 'Day' pricing). This re-calculation creates a timestamp mismatch between the item already in the cart (from the shop view) and the new item being added (from the details page). Solution: ========= The add-to-cart flow has been updated to correctly utilize the default duration values (the globally selected dates) if they exist. opw-5450576 Forward-Port-Of: odoo/enterprise#117058 Forward-Port-Of: odoo/enterprise#103373
This update removes clickable elements from account and unit fields on invoices. This change simplifies the invoice view, making it easier for users to read and understand, and improving the overall user experience. It's a small but important enhancement for usability.
Original PR description
This commit changes the account id and unit fields to be unclickable on the invoice lines to avoid having many clickable items on the invoice for better UX. task-6218115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where French tax reports (2033 A and B) were incorrectly available to all companies in a multi-company setup. Previously, the reports were tied to the French localization, leading to potential reporting errors. This change ensures the correct reports are generated for French businesses.
Original PR description
When installing the French localisation in a multi-company, multi-coa environment, the 2033 A report was available for every company, instead of just the French ones.
This update fixes a problem where combo prices were incorrectly doubling when multiple items were ordered during pricelist changes. The update ensures that free items are scaled correctly and that parent unit prices are accurately updated, resulting in more reliable combo pricing in the Point of Sale system. This improves the accuracy of sales calculations and prevents overcharging customers.
Original PR description
Fix combo prices doubling when quantity > 1 during pricelist changes. Correctly scale free items in 'getFreeAndExtraChildLines' and ensure parent unit prices are updated in 'setPricelist'. task-id: 5971935 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250666
This update ensures that PDF attachments sent through the Odoo portal are now correctly displayed in the related chatters. Previously, previews were missing due to a technical issue preventing the necessary data from being sent. This improvement enhances the user experience by allowing users to quickly view attached documents within the portal.
Original PR description
Before this commit, previews of pdf attachments (introduced in [1]) would not be displayed in portal chatters. This happens due to `_portal_message_format` not returning the data necessary to display pdf previews (i.e. `has_thumbnail` and `thumbnail_access_token`). This commit fixes the issue by returning said data. [1] https://github.com/odoo/odoo/pull/221006 task-6204747 Forward-Port-Of: odoo/odoo#263806 Forward-Port-Of: odoo/odoo#263481
This update resolves an issue preventing normal users from canceling approval requests they created. The fix utilizes 'sudo' to allow creators to successfully cancel their own requests, streamlining the approval process and improving user experience. This change ensures consistent functionality for all users.
Original PR description
Issue: - A user who created an approval request could cancel it. But a rights error appeared during the cancellation. Steps to Reproduce: - Create an approval being a normal user. - Try to cancel the approval. - A ValidationError is raised eventhough the approvals can be cancelled by creator of it. Fix: - Changed the cancel action to use the sudo for the user who created the task and can cancel it Impact: - Users can cancel their own approval requests without errors. Task: 6123104 Forward-Port-Of: odoo/enterprise#114189
This update corrects a visual issue where the project sharing notebook was using dark themes, causing conflicts with the standard light mode interface. The team removed a specific style file to ensure consistent and correct display of the notebook within the Odoo Enterprise application.
Original PR description
The project sharing notebook previously used dark-themed styles, which conflicted with the light mode .Removing the notebook.dark.scss file from the imported files in the manifest. task-4922564 Forward-Port-Of: odoo/enterprise#99161
This update allows users to re-submit invoices that were previously rejected by the tax authorities (SPV). Previously, rejected invoices were deleted and recreated, losing important tracking information. Now, rejected invoices are preserved, providing a history of attempts and improving traceability for Romanian VAT compliance.
Original PR description
Allow users to re-send invoices that were rejected by the SPV. Previously, EDI documents were deleted and recreated on every interaction, losing history in the process. This commit updates existing EDI documents in place instead, preserving failed documents as history for traceability. task-[5976612](https://www.odoo.com/odoo/project/967/tasks/5976612) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254882
This update allows Invoicing Administrators to delete or modify reconciled lines in the accounting system, resolving a previous restriction. The change ensures consistent access control based on the line's review status, aligning with existing accounting rules and improving administrative flexibility. This update addresses a technical issue related to privilege checks.
Original PR description
Deleting or editing a reconciled line raised "Validated entries can only be changed by your accountant." for Invoicing Administrators because the check only tested `group_account_user`, which is not granted by the Invoicing privilege chain. Delegate to `AccountMove._check_review_state_access()` to apply the same rules as `account.move`: - `'supervised'` → requires `group_account_manager` - `'reviewed'` → requires `group_account_user` or `group_account_manager` - `'todo'` / `'anomaly'` → no restriction opw-6128792 Forward-Port-Of: odoo/enterprise#114833
This update ensures payments to Viva.com are reliably confirmed, even if the connection is temporarily lost. Previously, a dropped connection would halt payment processing, leading to potential issues with Viva.com. Now, the system automatically retries payment confirmation until successful, providing a smoother and more accurate payment experience.
Original PR description
When a payment was sent to Viva.com and the connection dropped before receiving confirmation, the polling loop in waitForPaymentConfirmation would stop because _handleOdooConnectionFailure set the payment status to "retry" and rejected the promise. This left the payment debited on Viva's side but unconfirmed in the POS. Now the polling uses a direct silent ORM call instead of _call_viva_com to avoid triggering _handleOdooConnectionFailure. On connection failure, the poll silently retries on the next interval until a definitive success/failure response is received. A one-time warning notification informs the user that connectivity was lost. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259746 Forward-Port-Of: odoo/odoo#259564
This update fixes a display issue in Odoo's list views, ensuring group values now correctly reflect the formatting options of the associated field widgets. The fix resolves a discrepancy between the default formatter and widget behavior, resulting in consistent and accurate group values displayed in lists.
Original PR description
Before this commit, the values of groups in list view didn't get the options of the widget. Now, the groups extract the options of the column. The fact that the groups use the formatter of the widget now, show that there was an issue between the widget percentage and his formatter. The formatter, by default, show the trailing zero, but the widget, by default, doesn't. So, formatter has been fixed to be like the widget behavior. TASK-6226377 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265209
This update resolves a problem where category snippets on the website were displaying blank images. The change in how image data is stored within Odoo caused a mismatch, rendering the images unusable. The fix restores the original image URL format to ensure correct display.
Original PR description
Scenario: - install odoo and website_sale with --without-demo=True - go to website and drop a category snippet Result: the images appear dead Cause: the sample image_512 of dynamic category and product snippet were just containing the image URL. But with 41fe2ebdb9cc37341362d7af829c087a5f72f9f1 (march 2026) change of binary fields, they were changed to contain the file binary instead which are not valid URL (without data:image/* prefix). Fix: save the image as URL string as it was the case before. Note: issue found when testing 7f87bbaf16e6093271e767019b3322f1e87580f1 for opw-6118004.
This update fixes a bug that prevented users from validating multiple draft receipts with zero quantity. The issue stemmed from an error in the validation process that assumed a single picking. The fix ensures all picking IDs are passed to the wizard, allowing for successful validation regardless of the number of zero-quantity receipts.
Original PR description
## Steps to Reproduce: - install stock module. - Create 2 draft receipts with 0 quantity of the produce. - From the list view, select both receipts. - Gear icon > click on "Validate". ## Error: `ValueError - Expected singleton: stock.picking(7, 8)` ## Cause: The zero demand confirmation wizard initialized with `default_picking_ids`, which assumes self is a singleton. However, during batch validation, self can contain multiple pickings, causing the singleton error. ## Fix: This commit passes all picking IDs to the wizard instead of a single ID. sentry-7493958052
This update resolves an issue preventing users from adding extra images to product pages within the AI website builder. The fix corrects a technical error related to how image loading was handled, ensuring users can now successfully upload and manage additional media assets. This enhancement improves the visual presentation of products.
Original PR description
Steps to reproduce: =================== 1. Install ai_website_sale 2. Go to a product page and enter edit mode 3. In the right panel => Images => click "Add More" (Extra Media) 4. Select a PNG or JPG image and click Add => TypeError: loadPromiseResolveFunction is not a function Cause: ====== The `ai_website_sale` patch for `ProductAddExtraImageAction.getMediaDialogProps` destructures the argument with key `loadResolveFunction` (renamed to `loadPromiseResolveFunction` locally), but the caller in `load()` passes `loadPromiseResolveFunction` as the key. The key mismatch means the local variable is always `undefined`, and the `save` closure in the parent's `getMediaDialogProps` closes over `undefined` instead of the Promise's `resolve` function. Fix: ==== align the parameter key. It's a backport of this commit https://github.com/odoo/enterprise/commit/e5b89df328601af881af115c6083a648af0cc1a1 opw-6215476
This update fixes a potential issue where the website incorrectly displayed unavailable unit of measure (UOM) information for products. This change ensures that users receive accurate UOM details, preventing confusion and improving the overall sales experience. The fix was implemented as part of the ongoing maintenance and enhancement of our website sales functionality.
Original PR description
In some case, the requested uom might not be available (anymore) depending on the product latest changes. Followup on 4ac31e3545f009d0f96462f6a9098d5163ad521b --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265231
This update fixes an issue where newly created projects weren't automatically inheriting the stage selected in their project templates. The fix ensures that projects created from templates now correctly utilize the specified stage, streamlining project setup and improving consistency. This prevents manual stage adjustments after project creation.
Original PR description
Steps to reproduce: - 1. Enable "Project Stages" in Project settings. 2. Create a project template and move it to a stage other than the first one (e.g., "Stage 2"). 3. Create a project from this template (manually or via a Sales Order). Issue: - The newly created project is always placed in the first stage instead of inheriting the stage defined in the template. Cause: - The `stage_id` field on the `project.project` model is defined with `copy=False` When a project is created from a template, this field is excluded from the copied values, causing the new project to fall back to the default first stage. Fix: - Override `copy_data` to explicitly include `stage_id` from the source project template. task-6019852 Forward-Port-Of: odoo/odoo#265429 Forward-Port-Of: odoo/odoo#253864
This update resolves an error that prevented users from viewing historical payslip details in the Indonesian payroll system. The fix ensures that the system correctly handles the retrieval of payslip information, allowing users to access the necessary data. This improves the usability of the payroll reporting feature.
Original PR description
Currently, an error occurs when users click on View GROSS/PPH21/JHT/JP History to see historical payslip line values. Steps to Reproduce: - Install the `l10n_id_hr_payroll` module with demo data. -…
Currently, an error occurs when users click on View GROSS/PPH21/JHT/JP History to see historical payslip line values. Steps to Reproduce: - Install the `l10n_id_hr_payroll` module with demo data. - Switch to the `Indonesian` company. - Go to `Employees` and open an `existing record or create a new one`. - Click on `GROSS/PPH21/JHT/JP History` button. `ValueError: External ID not found in the system: hr_payroll.act_contribution_reg_payslip_lines` The issue occurs because, in [this commit], the act_contribution_reg_payslip_lines window action was removed. However, when viewing historical lines, and it still tries to retrieve this action using its XML ID [1] and then updates its domain, context, and views. As a result, it raises an error due to the missing XML ID. This commit ensures that the method returns a standalone window action dictionary instead of relying on the removed window action record. [this commit]: http://github.com/odoo/enterprise/pull/112571/changes/7094cdc033591258cae7c7df46888c29eaae6248 [1]- https://github.com/odoo/enterprise/blob/103500a805d1ffc1185ed639d613c2d1ede492cb/l10n_id_hr_payroll/models/hr_employee.py#L17-L24 sentry-7489148694
This update ensures that canteen costs are accurately calculated for monthly payrolls, even when an employee has multiple workdays with the same canteen code on a single payslip. Previously, the system didn't account for this common scenario, leading to potential inaccuracies in employee compensation. This fix guarantees correct canteen expense reporting.
Original PR description
Before this commit, canteen costs for the monthly pay did not take into account that multiple worked day lines with the same code can be present on the same payslip. no related task
This update resolves an error that occurred when automatically checking out employees with no defined check-out date, specifically when using the hr_attendance and hr_work_entry_attendance modules. The fix ensures accurate overtime calculations by correctly handling timezones, preventing the creation of duplicate overtime entries.
Original PR description
__ ## Short functional explanation of the error While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and hr_work_entry_attendance are both…
__ ## Short functional explanation of the error While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and hr_work_entry_attendance are both installed. When setting an attendance for an employee that has a check-in date but no check-out date, and running the scheduled action `Automatically check-out employees`, an `expected singleton` error occurs. ## Reproduction Steps 1. Install hr_work_entry_attendance. 2. Create an Employee. In the Payroll tab, set a start date for the contract. In the Settings tab, make sure their timezone is set to Brussels, and set the Overtime Ruleset field to Default Ruleset. 3. In Settings, check the Automatic Check-out box. 4. Go to Attendances. Create an attendance for the employee you just created. Set a Check-in date to 8 am on April 17th, for example, and leave the check-out field empty. 5. Open Scheduled Actions. Search the action Automatically check-out employees and click Run Manually. ### Expected behavior The attendance check-out should be set at the end of April 17th. ### Unexpected behavior An error occurs: `Expected singleton: hr.attendance.overtime.line(39, 40)` ## Origin of the issue When the attendance goes over several days, we set the check-out date to: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L618 This is a Naive date. However, it will later be considered as a UTC date. Because the employee's timezone is Brussels, this time will be transformed to 2 am next day when we retrieve attendance intervals. This will result in the creation of overtime entries for both days, causing the Expected Singleton error. https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L687 https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L667-L672 In our case, `self.check_in` = April 17th at 06:00:00 and `self.check_out` = April 17th at 23:59:59. Converted, we will obtain April 17th at 08:00:00 and April 18th at 1:59:59. Because of that, at the return: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L706-L709 We will return a dict containing 2 intervals: one for 17th April and one for 18th April. We will then create overtime entries with such attendances: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L333 leading to the creation of 2 different overtimes for the same attendance. So, when we retrieve the overtime for that attendance: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L185, We get the 2. Thus when trying to access their status with: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L191 An Expected Singleton Occurs. __ opw-6036064 Forward-Port-Of: odoo/odoo#262257
This update resolves an error that occurred when automatically checking out employees with no defined check-out date, particularly when the hr_attendance and hr_work_entry_attendance modules are used. The fix corrects a timezone calculation issue that was creating duplicate overtime entries, preventing the scheduled checkout action from functioning correctly. This ensures accurate overtime calculations for employees.
Original PR description
__ ## Short functional explanation of the error While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and hr_work_entry_attendance are both…
__ ## Short functional explanation of the error While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and hr_work_entry_attendance are both installed. When setting an attendance for an employee that has a check-in date but no check-out date, and running the scheduled action `Automatically check-out employees`, an `expected singleton` error occurs. ## Reproduction Steps 1. Install hr_work_entry_attendance. 2. Create an Employee. In the Payroll tab, set a start date for the contract. In the Settings tab, make sure their timezone is set to Brussels, and set the Overtime Ruleset field to Default Ruleset. 3. In Settings, check the Automatic Check-out box. 4. Go to Attendances. Create an attendance for the employee you just created. Set a Check-in date to 8 am on April 17th, for example, and leave the check-out field empty. 5. Open Scheduled Actions. Search the action Automatically check-out employees and click Run Manually. ### Expected behavior The attendance check-out should be set at the end of April 17th. ### Unexpected behavior An error occurs: `Expected singleton: hr.attendance.overtime.line(39, 40)` ## Origin of the issue When the attendance goes over several days, we set the check-out date to: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L618 This is a Naive date. However, it will later be considered as a UTC date. Because the employee's timezone is Brussels, this time will be transformed to 2 am next day when we retrieve attendance intervals. This will result in the creation of overtime entries for both days, causing the Expected Singleton error. https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L687 https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L667-L672 In our case, `self.check_in` = April 17th at 06:02:00 and `self.check_out` = April 17th at 23:59:59. Converted, we will obtain April 17th at 08:02:00 and April 18th at 1:59:59. Because of that, at the return: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L706 We will return a dict containing 2 intervals: one for 17th April and one for 18th April. We will then create overtime entries with such attendances: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L333 leading to the creation of 2 different overtimes for the same attendance. So, when we retrieve the overtime for that attendance: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L185, We get the 2. Thus when trying to access their status with: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L191 An Expected Singleton Occurs. __ opw-6036064 Forward-Port-Of: odoo/enterprise#115828
This update fixes an issue where multiple attachments to invoices (like timesheets) sometimes used the same filename, leading to attachment confusion. The change ensures that additional reports use unique filenames, preventing duplicate attachments and improving email reliability. This resolves a previous bug reported in related tickets.
Original PR description
Problem: When adding additional dynamic reports to the “Invoice: Send by Email” template, reports without a configured `print_report_name` incorrectly use the invoice filename. This is an issue because multiple attachments can have the same exact filename. Example from related ticket: the user attached timesheets to their template and both the invoice PDF and timesheet attachment used the same filename. Expected: The additional report should use its own fallback filename (ex: `timesheets_INV_XXX.pdf`) or its configured `print_report_name`. Actual: The additional report uses the invoice filename instead. To fix this, reports without `print_report_name` now fallback to: `<report name>_<invoice name>.pdf` as done in v18.0 Related Ticket: 6207518 and 6175376 Forward-Port-Of: odoo/odoo#264841
This update enhances the working files feature within the account reports, making it safer and more user-friendly. Specifically, a confirmation dialog has been added when deleting a working file, and the button is now hidden for non-accountant users to prevent accidental deletions. This ensures data integrity and simplifies the reporting process.
Original PR description
contains: [FIX] account_reports: Working files delete button: - hide it for non-accountant - add confirmation dialog [FIX] account_reports: Working file should always open in cycle view [FIX] account_reports: Always show embedded actions in Working files task-5880319 Forward-Port-Of: odoo/enterprise#115596
This update fixes a bug that caused duplicate vendor creation during EDI import of Swiss VAT documents. The change ensures Odoo correctly matches VAT numbers, regardless of format (flat or formatted), preventing unnecessary partner duplication. This improves data accuracy and streamlines import processes.
Original PR description
### Issue: When importing EDI documents such as Peppol files, Swiss VAT numbers are often provided in a flat format (e.g., CHE530781296TVA), while existing Odoo partners usually store them in the…
### Issue: When importing EDI documents such as Peppol files, Swiss VAT numbers are often provided in a flat format (e.g., CHE530781296TVA), while existing Odoo partners usually store them in the official formatted version (e.g., CHE-530.781.296 TVA) This mismatch prevents proper partner matching and may create duplicate partners during import ### Cause: `_retrieve_partner` lacks Swiss-specific VAT normalization logic in `_import_retrieve_customer_from_vat()` As a result, the matching process fails to: - match formatted and unformatted Swiss VAT numbers - properly handle language suffixes such as `TVA`, `MWST`, or `IVA` If `base_vat` is installed, and the imported XML VAT is `CHE530781296TVA`, a new partner will be created with the structure format `CHE-530.781.296 TVA` As the match won't be made new partner will be created at each import ### Steps to reproduce: - Install `account` - Create a Vendor (Name: Test CH Vendor, Country: Switzerland, Tax ID: CHE-530.781.296 TVA) - Import the bill [CH_bill_to_import.xml](https://github.com/user-attachments/files/27202997/CH_bill_to_import.xml) from the ticket Before the fix, the existing partner is not matched and a duplicate partner is created opw-6072239 Forward-Port-Of: odoo/odoo#262011
This update resolves an issue where the Odoo Agent would time out when updating records without the specific 'natural language query' topic. By adding available menus and models to the context, the Agent now correctly identifies and interacts with records, significantly improving stability and reliability during update operations.
Original PR description
Purpose: -------- The update and create tools can generate a link to show a preview of the created/updated record. However, the list of available menus is only added when the agent has the natural language query topic. Therefore, when using the Odoo Agent (that does not have that topic) to update a record, the LLM loops on the update record tool guessing random menu ids and eventually times out because the tool calls fail since the menu ids guesses do not match the model of the updated record. The list of available menus is now added in the context if the create or update records topics are available on the agent. The list of available models has also been added in this case. Task-6236642
This update resolves an issue where UBL invoices were failing to import due to extra spaces in the 'EndpointID' field. The change automatically removes these spaces, ensuring invoices are correctly processed. This improves the reliability of our UBL invoice import functionality.
Original PR description
**PROBLEM** When importing a ubl that, for some reason, have trailing space on the text of the EndpointID node, we refuse it. This PR strips the trailing spaces on the import. **STEP TO REPRODUCE** 1. Import a ubl as a bill, with a trailing space in the EndpointID of the other party. 2. Notice the import fail, with the error: The Peppol endpoint (50238597645 ) is not valid. It should contain only letters and digit. opw-6227395 Forward-Port-Of: odoo/odoo#265266
This update optimizes how product wishlists are loaded on the Odoo website’s shop page. Previously, the system was inefficiently retrieving wishlist data for each product, leading to slower loading times. This change reintroduces a previous optimization to batch the retrieval, resulting in a faster and more responsive shopping experience for users.
Original PR description
Was done in the past but lost through f427f795c24ee37ee02302642b77bfc314a9ea43. This commit makes sure the rendering value is still considered when available, to avoid fetching the wishlist content once for each displayed product on the /shop page. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This update streamlines the process of checking user access rights within review workflows. By creating helper functions, the system now more efficiently determines if a user has the necessary permissions to modify records based on their review state (supervised, reviewed, etc.), improving reliability and reducing code duplication.
Original PR description
Introduce two small helpers on `AccountMove`: * `_get_review_state_access_groups()` – returns the `(is_user_able_to_review, is_user_able_to_supervise)` booleans so the two `has_group` calls are not repeated across methods. * `_check_review_state_access(review_state)` – raises an `AccessError` with a state-specific message when the current user lacks the required role to modify a record in the given `review_state`: - `'supervised'` → requires `account.group_account_manager` - `'reviewed'` / `'no_review'` /falsy → requires `account.group_account_user` - `'todo'`, `'anomaly'` → unrestricted opw-6128792 Forward-Port-Of: odoo/odoo#262531