Daily updates from Odoo
Thursday, May 28, 2026
45 changes · saas-19.1
New functionality added to Odoo
This update introduces support for Indonesian tax returns within the Odoo Enterprise system. A new module, `l10n_id_reports`, has been created to manage these specific return types, allowing businesses operating in Indonesia to accurately report their tax obligations. This enhancement improves compliance and reporting capabilities for our Indonesian customers.
Original PR description
Create new module l10n_id_reports and add return type for Indonesia. task-6239169 Forward-Port-Of: odoo/enterprise#118304
This update introduces a new report for Hungary, specifically designed to generate EC Sales lists. Unlike the standard report, this version groups sales data by specific tax codes (B, C, K, R & V) for accurate reporting. It also includes the necessary tax return data associated with this report.
Original PR description
This report is a bit different from the main EC Sales list, instead of just grouping the lines on partner_id, we need to group on specifics tax.tags [B, C, K, R & V]. It also adds the tax returns for this same report. [task-4950959](https://www.odoo.com/odoo/project/967/tasks/4950959) Linked:https://github.com/odoo/odoo/pull/253556
Enhancements to existing features
This update introduces a new EC Sales list report specifically for Hungary, providing more detailed sales data. Instead of grouping solely by partner, it now analyzes transactions based on transaction type (B, C, K, R, V) and transaction state (U or T), offering a more accurate view of intra-community sales. This improves reporting capabilities for Hungarian businesses.
Original PR description
This commit implement the EC Sales list for Hungary This report is a bit different from the main EC Sales list, instead of just grouping the lines on partner_id, we need to group on specifics fields on account.move: - l10n_hu_transaction_type: B, C, K, R or V This field represente the type of Intra Community Transaction, it's a selection field with all the legal possible values. We leave the field blank for normal transactions. - l10n_hu_transaction_state: U or T Represent if the transaction is a new one (U) or a correction (T) The grouping of the report works like this: groupby partner_id, l10n_hu_transaction_type, l10n_hu_transaction_state This mean for a single partner, we can have up to 12 different lines. [task-4950959](https://www.odoo.com/odoo/project/967/tasks/4950959) Linked:https://github.com/odoo/enterprise/pull/110448
This update enhances the Balance Sheet report to accurately reflect Generally Accepted Accounting Principles (GAAP) by ensuring individual equity accounts are clearly visible. Previously, equity accounts were grouped, which is now corrected to provide a more precise and compliant financial view. This change improves the accuracy of financial reporting.
Original PR description
*=l10n_us_reports In the Balance Sheet, according to the GAAP rules, all equity accounts should be individually visible. task-6240500 Forward-Port-Of: odoo/enterprise#118149
This update enhances the OBOX order process within Self Order and Point of Sale systems. It now includes a timeout feature, allowing orders to be tracked even when devices aren't on the same network as the OBOX. This improves reliability and order fulfillment for users with disconnected devices.
Original PR description
Is now possible to await OBOX jobs with a specific timeout in PoS ans Self Order. This is usefull when the user device isn't connected on the same network as the OBOX and others hardware. taskId: 6248159
This update enhances the way Odoo handles communication with OBOX devices in Self and Point of Sale environments. It now includes a timeout feature, allowing for reliable operation even when devices aren't on the same network, improving overall system stability and usability.
Original PR description
Is now possible to await OBOX jobs with a specific timeout in PoS ans Self Order. This is usefull when the user device isn't connected on the same network as the OBOX and others hardware. taskId: 6248159
This update clarifies the documentation for how API keys are generated and revoked within Odoo. The changes standardize the documentation for improved clarity and accuracy, ensuring developers can effectively use and manage API keys. This supports better security and maintainability.
Original PR description
Clarify and complete the docstrings of `res.users.apikeys` methods: - document accepted union types for `scope` and `expiration_date` parameters of method `_generate`, and standardize its `:returns:` and `:rtype:` annotations - add missing parameter descriptions for `generate` and `revoke` Forward-Port-Of: odoo/odoo#265488
This update adds logging to the IoT drivers to help our support team quickly diagnose issues related to IoT boxes, specifically when they're stuck using a particular IP address or version. These logs will provide valuable insights for troubleshooting and resolving problems more efficiently. This is an internal improvement to enhance support processes.
Original PR description
This PR adds some minor logs to help identify issues around iot box hanging ip address and version See https://github.com/odoo/enterprise/pull/118377 Forward-Port-Of: odoo/odoo#266410
This update improves support for our IoT devices by adding more detailed logs regarding IP address and version changes, as well as websocket messages sent to the box. A small optimization was also implemented to prevent unnecessary searches, streamlining the process and providing better visibility for troubleshooting.
Original PR description
This PR adds some minor logs around ip/version change and websocket messages sent to the iot box. It also inverts a condition to avoid doing a useless search when sending websocket messages See https://github.com/odoo/odoo/pull/266410 Forward-Port-Of: odoo/enterprise#118377
Resolved issues and error corrections
This update optimizes the performance of our spreadsheet functionality, specifically when working with large tables like Accounting Balances Sheets. By streamlining how the system checks styles, it reduces recalculation times during common actions like resizing windows or sorting data, leading to a smoother user experience.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. Forward-Port-Of: odoo/enterprise#118535
This update corrects a dependency issue within the Italian reporting module (l10n_it_reports). Specifically, a filter was added to properly handle data related to pension funds, which was previously causing errors. This ensures accurate reporting for Italian businesses using Odoo Enterprise.
Original PR description
Commit: 0a5657297f312cb3e5f6c3ab6a281acf71fbee3b added a filter for the field l10n_it_pension_fund_type which is defined in l10n_it_edi_withholding and not l10n_it_reports runbot-242217 Forward-Port-Of: odoo/enterprise#113185
This update removes a redundant step in the timesheet setup process. Previously, users needed to manually start a server each login; this has been resolved by an update to the activity watch installer. This simplifies the onboarding experience for new timesheet users.
Original PR description
Before this commit, the wizard to onboard the user to correctly install activity watch for timesheet assistant, mentioned the user has to start the server each time he logs in on his computer. This step is not longer needed thanks to an update on the odoo activity watch installer. This commit removes the line saying the user has to start the server each time he starts his working day. task-6081636
This update ensures that work entry data exported to the Acerta payroll system adheres to their specific formatting requirements. Specifically, the external reference number and work entry type code are now padded correctly, resolving potential data discrepancies and ensuring accurate payroll processing. This change improves data integrity and compliance with Acerta's system.
Original PR description
We want to adhere to the correct format for the export of work entries to Acerta. There, the number of external reference is padded to 17, not 20, and is followed by 3 spaces, before the date. Also, the code of the work entry type is padded to 4 and followed by 2 spaces. Task: 6168106 Forward-Port-Of: odoo/enterprise#118389 Forward-Port-Of: odoo/enterprise#118124
This update fixes a problem where users weren't notified when an expense authorization status changed (e.g., cancelled). The system now correctly responds to authorization updates, ensuring users are informed about the status of their expenses. This improves transparency and accuracy in expense tracking.
Original PR description
## [FIX] hr_expense_stripe: Fix error messages coherence Fix the incoherent punctuation ## [FIX] hr_expense_stripe: Fix reversed and expired authorizations Before this, when receiving an `issuing_authorization.updated` event, the event would be ignored and the user would never know that the expense had been cancelled opw-6210055 Forward-Port-Of: odoo/enterprise#117257
This update resolves an issue where double-clicking images within the Media Dialog in website editing mode would trigger a technical error. The fix uses a flag to track processing clicks, preventing multiple actions from executing simultaneously. This ensures a smoother and more reliable editing experience.
Original PR description
Steps to reproduce: 1.Open the website in Edit mode. 2.Add a snippet with an image. 3.Replace the image. 4.After replacing image, double-click on it to open the Media Dialog. 5.Inside the Media…
Steps to reproduce: 1.Open the website in Edit mode. 2.Add a snippet with an image. 3.Replace the image. 4.After replacing image, double-click on it to open the Media Dialog. 5.Inside the Media Dialog, double-click on the same or any other image. 6.Traceback occurs. Before this commit: parentElement was becoming null because parentElement is a DOM position check.it requires the element to be physically attached in the DOM tree to find its parent.Since this.props.node is not yet in the DOM at that point, parentElement returns null. After this commit: 1.The issue is fixed using a boolean flag: isProcessingClick. Initially, the flag is set to false. When the first click starts, it is updated to true. If another click occurs during the same flow (e.g during a double click), isProcessingClick is already true, so the function immediately returns and prevents the action from being executed multiple times. 2.we now pass closestSnippetEl directly from replaceMedia() through params.this allows the dialog taken snippet reference using (closestElement(mediaEl , "[data-snippet]")) without depending on the media node being attached to the DOM. task-6033320 Forward-Port-Of: odoo/odoo#266664 Forward-Port-Of: odoo/odoo#254790
This update fixes an issue where generated PDF invoices were missing item references, which could make it difficult to accurately track product lines. The change ensures that all product lines now display the internal item reference, improving invoice clarity and data accuracy. This resolves a problem with vendor bill XML generation.
Original PR description
Some XML vendor bills generated by external ERPs were missing the Description tag, which typically contains both the [ITEM_REF] and ITEM_NAME. As a result, product lines in the generated PDF could appear without the internal item reference. This commit ensures that the item reference is always included in the displayed product line. task-6080328 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259086
This update fixes an issue where multiple lines of text were incorrectly converted into separate code or quote blocks within the HTML editor. Now, selecting multiple lines automatically combines them into a single, correctly formatted block, enhancing the editor's usability. This ensures consistent formatting and a better user experience when working with code or quotes.
Original PR description
Steps to reproduce: - Write multiple lines of text. - Select all lines. - Change block type from Normal to Code (or Quote) via the toolbar. Description of the issue: - Notice that each line is now a separate code block (or quote). Cause: - The `setBlock` method currently converts each selected block individually into the target block type, creating multiple blocks when multiple lines are selected. Solution: - For code and quote blocks, `setBlock` now converts only the first selected block into the target type and merges the content of the other selected blocks into it, ensuring a single code/quote block. task-6068930
This update ensures that invoices generated from Point of Sale orders now correctly include the product's internal reference (like 'E-COM11') alongside the product name. Previously, invoices lacked this key detail. This change improves invoice accuracy and traceability for sales transactions.
Original PR description
Currently invoices generated from pos orders do not show the product referense alongside the product name. Steps to reproduce: ------------------- * Open shop and select Cabinet with doors * Add…
Currently invoices generated from pos orders do not show the product referense alongside the product name. Steps to reproduce: ------------------- * Open shop and select Cabinet with doors * Add customer to order * Pay the order * Wether you selected to invoice or you didn't, does not matter, you can invoice from the backend > Observe on the invoice that the product does not show the internal reference "Cabinet with Doors" * Create a sale order for the same product, deliver and invoice > Observe the invoice, the product shows reference "[E-COM11] Cabinet with Doors" Why the fix: ------------ After this commit: https://github.com/odoo/odoo/commit/aff477805577cb7ed00fb94440dda5cf2f29cb44 we're using `full_product_name` to set the name on move line name. We could simply add the reference when computing the product name but the logiq used to computed the display name is a bit more complex than simply adding it always. Instead we use both display_name and full_product_name to build the final name. This way it has the reference if any and all information about variants are kept as well. opw-5950016 Forward-Port-Of: odoo/odoo#253540
This update prevents the automatic generation of OIOUBL XML files for users who don't have a VAT number when using the Nemhandel payment system. Previously, this resulted in unnecessary XML files being created. This change ensures compliance and simplifies the system for users without VAT registration.
Original PR description
Users with no VAT number shouldn't be able to use Nemhandel and shouldn't have a OIOUBL xml generated. task-6196225 Forward-Port-Of: odoo/odoo#266253 Forward-Port-Of: odoo/odoo#263244
This update fixes an issue where UBL imports with taxes set to 'price_include' were failing to correctly calculate and apply taxes, especially for invoices with multiple items. The fix ensures accurate tax calculations and adjustments, addressing a potential revenue discrepancy during UBL import processes. This improves the reliability of our accounting data.
Original PR description
**PROBLEMS** 1. On a company with taxes with price_include = True, we fail to retrieve a tax when importing a ubl. 2. The price_unit adjustement for when importing price-included taxes doesn't account for quantity. **STEP TO REPRODUCE** 1. Have a setup where the tax are only price_include. 2. Import a ubl, the taxes will not be retrieved. 3. Run odoo only with the fix for problem 1, and import the same ubl with some invoice quantity != 1 4. Notice the price unit are messed up for lines with quantity != 1 (odoo tries to correct the untaxed amount with a line, but this doesn't fixes the tax). opw-6159394 Forward-Port-Of: odoo/odoo#266107 Forward-Port-Of: odoo/odoo#262686
This update enhances the website's carousel functionality to be more accessible for all users, particularly those using keyboard navigation. The changes include making focus visible, pausing the carousel when focused, and supporting 'home' and 'end' keys for easy navigation. These improvements align with accessibility standards and provide a better user experience.
Original PR description
[FIX] website: improve carousel accessibility To improve keyboard accessibility on carousels, the indicators container is not focusable anymore, and the indicators themselves now only have one…
[FIX] website: improve carousel accessibility
To improve keyboard accessibility on carousels, the indicators container
is not focusable anymore, and the indicators themselves now only have
one focusable button at a time.
The tab order is thus: previous button > active indicator > next button.
(The previous and next button may both appear before.)
You can still navigate among indicators with the left and right arrows,
which also moves the focus to the newly targetted indicator.
Note that other accessibility improvements remain to be done on the
carousels (add a pause/play button on auto-sliding carousels, place the
buttons before the carousel slide in the tab order, add some aria
attributes (roledescription, live), adaptative labels...).
[FIX] website: make focus visible on carousel arrows
When focusing manually (with tab / shift+tab) the previous/next arrows
in carousels, it is hard to follow where the focus is, because there is
no outline and the contrast is too small.
This commit adds a specific outline if the button is `:focus-visible`
(with both black and white to work on any background).
[IMP] website: pause carousel on focus within
Carousels are paused on hover (or touchstart), but if the focus is
inside one, it won't pause. That can make it hard to navigate within
interactive carousels during the sliding interval (e.g. the dynamic
products, which by default has 4 different products with 3 different
focusable links/buttons).
This commit applies the same behavior on focusin as Bootstrap's default
on mouseover, and on focusout as on mouseout.
[IMP] website: support home/end keys on carousels
When the focus is in a carousel, pressing the "home" key displays the
first slide and pressing the "end" key displays the last slide.
task-5470023
Forward-Port-Of: odoo/odoo#266428
Forward-Port-Of: odoo/odoo#244939This update corrects a bug preventing employees administrators from seeing the attendance smart button for other employees. The issue stemmed from how the system determined button visibility based on group permissions, specifically relating to attendance management. The fix ensures the button appears correctly for users with the necessary 'Employee: Administrator' and 'Officer: Manage attendances' groups.
Original PR description
## Issue When logged in with a user who has the *Employee: Administrator* (`hr.group_hr_manager`) and the *User: Read his own attendances* (`hr_attendance.group_hr_attendance_own_reader`) groups, but…
## Issue
When logged in with a user who has the *Employee: Administrator* (`hr.group_hr_manager`) and the *User: Read his own attendances* (`hr_attendance.group_hr_attendance_own_reader`) groups, but not the *Officer: Manage attendances* (`hr_attendance.group_hr_attendance_officer`) group, the user won't be able to see their own attendance on their own employee's form view.
Additionally, a user without no Employee group but with the *Officer: Manage attendances* group could not see the attendance smart button on other employees form view.
## Steps to reproduce
1. Install *Attendances* (`hr_attendance`)
2. Set Marc Demo's groups:
- *Employees: Administrator*
- *Officer: Manage attendances*: unchecked
- *User: Read his own attendances*: checked (implied by Role / User)
3. Log in as Marc Demo and open his own form in Employees
4. **The attendance smart button is missing, even though Marc Demo has the group to see his own attendance.**
For the second issue:
1. Set Marc Demo's groups:
- *Employees: No*
- *Officer: Manage attendances*: checked
- *User: Read his own attendances*: checked (implied by Role / User)
2. Log in as Marc Demo and open another employee's form
3. **The attendance smart button is missing, even though Marc Demo has
the group to manage other employee's attendance.**
## Cause
There are two employee views defined in `hr_attendance`: `hr_employee_public_view_form` and `view_employee_form_inherit_hr_attendance`. The two views have different conditions under which the attendance smart button is displayed:
- In the public view, which is seen by users who do not have the *Employee: Administrator* group, the button is only displayed if the employee form is the one of the current user.
https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr_attendance/views/hr_employee_public_views.xml#L9-L15
https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr/models/hr_employee_public.py#L119-L123
**This means that a user without the _Employee: Administrator_ group cannot see the attendance button of other employees, even with the _Officer: Manage attendances_ group.** This view should take into account the *Attendance Manager* group.
- In the other view, which is displayed for users with the *Employee: Administrator* group, the button is only displayed for attendance officers.
https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr_attendance/views/hr_employee_view.xml#L24-L29
**This means that if a user is an Employee Administrator, but is not an Attendance Officer, they cannot see their own attendance, even with the "own attendance" group.** This second view should take into account the _User: Read his own attendances_ group.
opw-6167399
Forward-Port-Of: odoo/odoo#263826This update fixes a technical error that prevented refunds in the Colombian Point of Sale (PoS) module. The issue stemmed from outdated code referencing an older function name, which caused a traceback during the refund process. This change ensures seamless refund functionality for Colombian businesses using the PoS.
Original PR description
**Steps to reproduce:** - Setup a columbian company, DIAN should be in demo mode - Go to the PoS and make a sale with a columbian customer - Refund it - A traceback appears **Why the fix:** Some legacy code was left untouched when we changed the old **get_partner()** to the new **getPartner()** so we got a traceback as this function does not exist anymore. We also change the **set_partner(partner)** to **setPartner(partner)** as it was also forgotten. opw-6231856 Forward-Port-Of: odoo/enterprise#118054
This update removes a redundant CSS rule that was slowing down the application's style recalculation process. While the change didn't affect how the Kanban view looks, it significantly improved overall performance by reducing the time browsers spend evaluating styles. This results in a faster and more responsive user experience.
Original PR description
Remove the unused selector `[class*="col-"]:has` from `kanban_color_picker_field.scss`. It no longer affects the view but negatively impacts global CSS performance because the global selector `[class*="col-"]` combined with `:has` is expensive to evaluate. This caused long "Recalculate style" times reported in the selector stats. Even if it no longer affects rendering, browsers still spend time evaluating it during style recalculation, hurting performance. Removing the selector removes that cost. Steps to reproduce: 1. Open the Project app. 2. Go to Configuration > Projects. 3. Switch to Kanban view. 4. Click the "..." button on a Kanban card. 5. Inspect the color picker with the dev tools and remove the rule on a `col-6` node nothing changes, demonstrating the rule is now useless. Forward-Port-Of: odoo/odoo#266382
This update resolves an issue where the 'Info & Tags' button was hidden on the Documents mobile Kanban view. The fix adjusts CSS styling to ensure the chatter section is always visible and accessible, providing users with the necessary functionality on mobile devices. This improves the user experience for accessing document details.
Original PR description
**Steps to reproduce:** - Go to Documents app in mobile - Go to the kanban view - Add some files and select one - Click on `Info & Tags` button in the control panel - Reload the page - Chatter is not…
**Steps to reproduce:** - Go to Documents app in mobile - Go to the kanban view - Add some files and select one - Click on `Info & Tags` button in the control panel - Reload the page - Chatter is not displayed but the button is still enabled - Switching to the list view properly shows it **Issue:** We have two conflicting css styling on mobile: - `overflow-hidden` was added for mobile to avoid multiple scroll bars - `min-height: 100%` which is due to the default `o_kanban_ungrouped` in the controller css This means that the element is present at the bottom of the page, but we can't get to it manually. When re-enabling the action we are properly moved to the existing chatter (but we can't go back to the top). Also the documents panel should have a single scrollbar to display all the records, but we still need a way to scroll the messages of the chatter. **Fix:** Set `min-height: 0;` for documents kanban to ensure the chatter is still visible and accessible on mobile by default. This makes the chatter take the full available height when displayed. original overflow fix: https://github.com/odoo/enterprise/commit/945b9e2b1c6752bd905695aa40b0babcf38c50cd opw-6061993 Forward-Port-Of: odoo/enterprise#118134 Forward-Port-Of: odoo/enterprise#113168
This update fixes a visual issue in the technical settings where new link previews displayed a technical ID instead of a user-friendly 'New' label. The change ensures that new previews show 'New' until saved, and then display the actual URL, providing a cleaner and more intuitive experience for users.
Original PR description
**Problem:** Opening a new `mail.link.preview` record from the technical view shows the internal record reference (e.g. `mail.link.preview,NewId_0x...`) in the breadcrumb instead of the standard…
**Problem:**
Opening a new `mail.link.preview` record from the technical view shows the internal record reference (e.g. `mail.link.preview,NewId_0x...`) in the breadcrumb instead of the standard "New" label.
**Steps to reproduce:**
1. Settings / Technical / Discuss / Link Previews
2. New
3. Observe the breadcrumb
**Current behavior:**
The breadcrumb displays `mail.link.preview,<id>`.
**Expected behavior:**
The breadcrumb should display "New" until the record is saved, and the source URL once saved.
**Cause of the issue:**
The model defines no `name` field and does not set `_rec_name`, so the default `_compute_display_name` falls into its fallback branch and returns `f"{record._name},{record.id}"` — exposing the technical reference in the breadcrumb both for unsaved records (`NewId_...`) and saved ones.
**Fix:**
Setting `_rec_name = 'source_url'` lets the standard display name machinery compute a meaningful label from the existing required field. Unsaved records then surface the standard "New" placeholder via the web client and saved records surface their URL, without introducing a redundant `name` field or overriding the compute.
opw-6095012
Forward-Port-Of: odoo/odoo#263577This update corrects a technical issue where the versions timeline was incorrectly displaying data due to a misunderstanding of how items were being pushed to the system. The fix ensures the correct data is presented, improving the accuracy and usability of the timeline. This change focuses on internal data processing and doesn't directly impact users.
Original PR description
The push function does not take a list of items but items. So when it was pushed into the fieldNames list it would create a list with ['display_name', [...]] which is not wanted. task-6072932 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#256130
This update addresses a technical issue related to how Odoo retrieves VIES identifiers for VAT calculations. Specifically, a potential race condition was fixed, ensuring accurate and reliable VAT processing. The changes also included enhanced testing and updates to align with IAP requirements, improving the stability and performance of the base_vat module.
Original PR description
- Avoid race condition while getting the IAP VIES identifiers - Clarify to which state the Intra-Community value has been updated - Increment validity of the webhook_token while waiting for a push update - Add more tests, especially for the controller and the cron - Remove no-longer-relevant tests task-none Forward-Port-Of: odoo/odoo#266687 Forward-Port-Of: odoo/odoo#260440
This update ensures that all point-of-sale orders, including those that have been invoiced, are now accurately reflected in the periodic sales digest emails. Previously, only un-invoiced orders were counted, leading to an incomplete view of sales performance. This fix corrects this issue, providing a more reliable report.
Original PR description
Currently in the periodic digest sent by mail only the pos orders that are not invoiced are counted. Steps to reproduce: ------------------- * On empty db (no order previously) * Create a pos order of 10$, don't invoice it * Create a pos order of 10$, invoice it * Close session * Generate the periodic digest: * Go to settings * Under Emails, find "Digest Email" * Select "Configure digest emails" * Select "Your Odoo Periodic Digest" * Make sure "Pos Sales" is ticked * Select "Send Now" * In debug: * In the settings, under Technical, select Emails > Emails * Select the Periodic Digest > Observation: In the point of sale tab, it shows only 10$ Why the fix: ------------ Previously pos orders that were invoiced were not taken into account, now they are. opw-6111304 Forward-Port-Of: odoo/odoo#262561
This update corrects an issue where property search filters weren't working as expected. The problem stemmed from a misunderstanding of how boolean values are handled within the Odoo search system. This fix ensures property filters accurately return the intended records.
Original PR description
# How to reproduce - Go to the Form view of a model to which you can Add Properties (e.g. Project > Tasks) - Click on the gear icon > Add Properties - Create a property field with : - Name : X -…
# How to reproduce
- Go to the Form view of a model to which you can Add Properties
(e.g. Project > Tasks)
- Click on the gear icon > Add Properties
- Create a property field with :
- Name : X
- Field Type : Decimal
- Create two records for that model and set the value of the property to 1 & 2
- Go back and Add a custom filter with ('Properties.X', '=', 1)
# The problem
We see both records even tho we should only see one
# Cause of the issue
When doing the search, we transform the domain into the where clause of a
query. This transformation is done with the `condition_to_sql()`
function of the concerned field (`fields_properties` in our case):
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L589
In this function, we manipulate a bit the condition depending on the value,
notably if the value is/contains True. To check it does, we do this :
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L601
The issue is that in python, True in [1] and evaluates to True
because bool is a subset of int. This changes the condition and replaces it in
our case with ('Properties.X', '!=', 'False'), which is obviously not what
was initially asked for.
opw-6224811
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#266231
Forward-Port-Of: odoo/odoo#265835This update strengthens the security of our Point of Sale system by ensuring that the correct access token is being used. The `PosCustomerDisplay` controller now validates incoming access tokens, preventing unauthorized access and improving overall system security. This change was implemented as part of a broader effort to enhance security protocols.
Original PR description
In this commit we adapt the `PosCustomerDisplay` controller such that it checks that the correct `pos.access_token` was sent. Task: 6144690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262287 Forward-Port-Of: odoo/odoo#261545
This update replaces the older PostgreSQL 12 version in the Windows installer with the more current PostgreSQL 16. This change addresses end-of-life support for the previous version and improves security. Additionally, the installer now uses a dedicated Odoo user for database connections, enhancing security and stability.
Original PR description
The Windows installer installs PostgreSQL 12. That version was chosen for its small size, but now in 2026 the size doesn't matter as much anymore. Also, version 12 is no longer supported, so it's time to bump to version 16. While at it, this commit adds an Odoo user for the PostgreSQL connection instead of using the superuser. Forward-Port-Of: odoo/odoo#266059 Forward-Port-Of: odoo/odoo#265134
This update resolves an issue where delivery orders could be completed without recording serial numbers for tracked products, leading to data inconsistencies. The fix ensures that the quantity and serial number information are correctly synchronized during delivery order creation, preventing errors and maintaining accurate inventory tracking.
Original PR description
Writing both `quantity` and `lot_ids` on a tracked move in the same form save leaves `move.quantity` stored at the user value while `_set_lot_ids` unlinks the remaining move line; the picking can then be validated to 'done' with no serial recorded. Force `_compute_quantity` at the end of `_set_lot_ids` so the stored value stays in sync with the move lines. Steps to reproduce: - Serial-tracked product, 6 in stock - Create a delivery order for 6 units of that product - In the delivery form, on the move row: type "1" in Quantity and remove all 6 lots from the Serial Numbers widget. - Save, Validate Before: picking goes to Done with quantity=1 and no serial. After: clear UserError, quantity stays in sync with mls. opw-6192841 Forward-Port-Of: odoo/odoo#266632 Forward-Port-Of: odoo/odoo#266394
This update fixes a potential issue where duplicate Addenda nodes were being created in CFDI invoices. This ensured compliance with Mexican tax regulations (SAT) and the CFDI 4.0 standard, preventing invoice rejection by recipient systems. The fix maintains a clean, valid XML structure even with multiple processing attempts.
Original PR description
Before this commit, if the `_l10n_mx_edi_cfdi_invoice_append_addendas` method was executed more than once on the same invoice, the resulting CFDI would contain multiple `<cfdi:Addenda>` nodes. This…
Before this commit, if the `_l10n_mx_edi_cfdi_invoice_append_addendas` method was executed more than once on the same invoice, the resulting CFDI would contain multiple `<cfdi:Addenda>` nodes.
This occurred because the method manually injects the new Addenda string at the end of the XML without checking if one was already present from a previous execution.
According to the SAT's Anexo 20 and the CFDI 4.0 XSD, the Addenda must be a single node and the last element of the Comprobante. Duplicating root-level nodes like `cfdi:Addenda` is a bad XML formation practice that can cause rejection by the recipient's automated systems.
This fix ensures the CFDI structure remains valid by:
1. Searching for an existing `{*}Addenda` node in the CFDI string.
2. Removing the old node before reconstructing the XML.
3. Preventing the string replacement logic from stacking multiple Addenda blocks.
This ensures that the CFDI remains clean and compliant with the official standard even if the process is triggered multiple times.
Forward-Port-Of: odoo/enterprise#109760This update resolves a compatibility issue with a key library used to handle XML data within Odoo. By upgrading the lxml version, the system now functions correctly and avoids potential errors. This ensures smooth operation of Odoo's core features.
Original PR description
Note: support for version 6+ of lxml has been merged in odoo/odoo@4b1797fccdf1447a8adb817148cc39bc322428a6 runbot-938365 Forward-Port-Of: odoo/odoo#266627
This update resolves a performance issue in the HTML Builder where the shape selector panel was causing significant delays and UI freezes. By delaying the loading of panel content until it's needed, we've dramatically reduced the number of requests and improved the overall responsiveness of the builder. This ensures a smoother and faster experience for users.
Original PR description
The shape selector panel was eagerly compiling and rendering its slot content on builder startup, triggering 200+ concurrent SVG thumbnail requests before the user had opened the panel or selected an image. With browsers limiting parallel connections per domain, this flooded the request queue and caused the main UI to freeze for several seconds. Slot content is now deferred behind a `contentRendered` flag that is set the first time the panel is opened, so no compilation or network activity happens until the user actually needs it. task-5973702
This update corrects a technical issue in the currency settings module. The previous method of retrieving configuration parameters was outdated and has been replaced with a more modern approach. This ensures the currency settings function correctly within the Odoo Enterprise SaaS environment.
Original PR description
Since saas-19.1, get_param has been removed from ir.config_parameter and replaced by typed helpers such as get_int, get_float, and get_bool, etc. This commit replaces the deprecated get_param call with get_int to prevent an AttributeError.
This update resolves an issue where custom text attributes on products weren't correctly displayed when settling website orders through the POS system. Previously, the POS would show a placeholder instead of the customer's entered text. The fix ensures that custom attribute data is accurately transferred and displayed in the POS order lines.
Original PR description
When a sale order containing a product with a custom (free text) attribute was settled in POS, the order line displayed the placeholder attribute value name (e.g. "Custom") instead of the actual text…
When a sale order containing a product with a custom (free text) attribute was settled in POS, the order line displayed the placeholder attribute value name (e.g. "Custom") instead of the actual text entered by the customer. Steps to reproduce: ------------------- * Create a product with a free text attribute (create_variant='no_variant', is_custom=True) * Go to the website's shop (works best in a new private tab) * Fill the free text attribute and add the product to the cart * Click on checkout * In POS, open Quotation/Order and settle the order > Observation: the order line shows "Custom" instead of the text Why the fix: ------------ `SaleOrderLine._load_pos_data_fields` was not exposing `product_no_variant_attribute_value_ids` nor `product_custom_attribute_value_ids`, so the JS `settleSO` function received no attribute data on the `line` object. As a result, the new POS order line was created with empty `attribute_value_ids` and `custom_attribute_value_ids`, leaving `constructFullProductName` unable to find the custom text. The fix adds both fields to `_load_pos_data_fields` and updates `settleSO` to use them when building the new POS order line. The dynamic fetch path (`_getSaleOrder`) is also updated to explicitly read the `product.attribute.custom.value` records so the data is available for orders loaded at runtime. opw-5958678 Forward-Port-Of: odoo/odoo#265491 Forward-Port-Of: odoo/odoo#251993
This update fixes a potential issue where invalid characters in work addresses could cause errors during the generation of the DMFA report PDF. By adding a validation check, the system now prevents these errors, ensuring the report can be created reliably. This improves the overall stability and accuracy of the report.
Original PR description
Added a validation error in the _get_code function in case the code contains non-numerical characters. This prevents non-numerical characters input from breaking the DMFA report PDF generation. Task: 6231125 Forward-Port-Of: odoo/enterprise#117889
This update fixes a crash that occurred when purchase matching attempted to convert vendor bills with only a description and UoM, without a linked product. The change ensures purchase matching is robust when importing bills based on description, maintaining consistency with existing UoM conversion rules. This improves the reliability of importing purchase invoices.
Original PR description
### Issue before this commit: Opening the Purchase Matching wizard would crash if the vendor bill contained lines with a description and a Unit of Measure (UoM), but no product selected. ### Steps to…
### Issue before this commit: Opening the Purchase Matching wizard would crash if the vendor bill contained lines with a description and a Unit of Measure (UoM), but no product selected. ### Steps to reproduce the issue: 1. Enable Units of Measure in Settings 2. Create and confirm a Vendor Bill setting a description and a UoM, but leave the Product field empty. 3. Click on "Purchase matching" smart button 4. The system throws a traceback with the error: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure False defined on the product." ### Cause of the issue: In the purchase.bill.line.match model, the field product_uom_qty was computed by calling _compute_quantity using line.product_uom_id. Since product_uom_id is a related field on product_id.uom_id, it returns False when no product is set. The UoM conversion logic cannot handle a False destination category, leading to the crash. ### Reason to introduce the fix: Make purchase matching robust when imported vendor bills contain lines identified only by their description and not by a product. Note that for `purchase.bill.line.match` corresponding to an account.move.line but not related to any product, the `product_uom_qty` should match the quantity of the `aml_id` instead of attempting a UoM conversion based on a missing product UoM for the behavior to be consistent with the inverse method: https://github.com/odoo/odoo/blob/59d6232979b8499fde6cb700df1870e2e38d0d3e/addons/purchase/models/purchase_bill_line_match.py#L45-L54 opw-5911526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266269 Forward-Port-Of: odoo/odoo#257827
This update resolves an issue preventing Belgian employees on flexible work schedules from requesting multi-day leave. The fix ensures that the system correctly handles flexible schedules by skipping attendance checks, which was previously causing errors. This enhancement ensures accurate leave calculations and functionality for our Belgian clients.
Original PR description
## Steps to reproduce: - Install l10n_be_hr_payroll module - Create a flexible working schedule and set the company to the Belgian company - Create an employee and assign the created schedule to him - Try to take a multi-day leave for this employee - Notice number of days is 0 - Try to validate the leave - An exception is raised 'The following employees are not supposed to work during that period' ## Cause: When fetching the work intervals for a belgian flexible employee we first fetch the normal work intervals then we call the same method but to filter the time credit attendance and since for the flexible employee there are not specific attendances we return the same normal work intervals and it will subtract those from the main work intervals which will result in an empty intervals to be returned ## Fix: Check if the working schedule is flexible and if so we don't check the time credit attendances at all. opw-6237642 Forward-Port-Of: odoo/enterprise#118528
This update fixes an issue where order names weren't correctly updated when a customer was changed on an order, particularly in scenarios like Delivery/Eat In. The change ensures order names accurately reflect the current customer, improving order clarity and data consistency.
Original PR description
When a partner is changed on an order that was previously named after another partner (e.g. in a Delivery/Eat In preset scenario), the order name was not updated. This was because once `floating_order_name` is set, the order is no longer considered a "direct sale", and the logic to update the name from the partner was bypassed. This commit updates `setPartner` to check if the current name matches the name of the previous partner. If so, it updates the name to the new partner's name. task-id: 6000287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251811
This update optimizes the account report sheet by streamlining CSS styling to reduce performance bottlenecks. By using CSS variables and direct selectors, the system avoids unnecessary DOM traversal, resulting in smoother and faster loading times, especially for large reports. This improves the user experience and reduces potential lag.
Original PR description
Forward-Port-Of: odoo/enterprise#118490
This update fixes an issue where expected working hours displayed in the Attendances Gantt view were inaccurate for employees with flexible schedules, particularly when viewed through browsers using local timezones. The change ensures accurate hour calculations based on the user's timezone, improving the reliability of attendance tracking.
Original PR description
Steps to reproduce: 1. Ensure your browser is in a non-UTC timezone (e.g. Europe/Zurich) 2. Set an employee to have a flexible working schedule 3. Enter the Attendances app 4. When hovering over the employee in the gantt view, the expected hours do not match their working schedule When we calculate the expected hours for the Gantt view in attendances, we calculate this based on an incorrect number of attendance intervals given from _attendance_intervals_batch(). To ensure that we recieve accurate intervals, we need to ensure that we calculate intervals based on the correct date range with respect to the browsers timezone, instead of the UTC date range. [opw-6175441](https://www.odoo.com/odoo/my-tasks/6175441?debug=assets) Forward-Port-Of: odoo/enterprise#116807
Code cleanup and technical improvements
This update simplifies how plugins manage submit buttons within the website builder. Previously, a single, hardcoded list required developers to modify core code for each plugin. Now, plugins can easily register their own submit button selectors, making the system more flexible and easier to maintain. This reduces development time and improves the overall stability of the website builder.
Original PR description
\* = website, website_payment Previously submit button selectors were defined in a single hardcoded string in the save snippet logic. This made the list harder to maintain and required modifying the base code whenever a new plugin needed to exclude its submit button from being saved as a snippet. Introduce a resource allowing plugins to register their own submit button selectors. Plugins can now extend this list directly from their code without modifying the base implementation. This makes the logic easier to maintain and provides a reusable extension point for other submit-button related behaviors in plugins. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263045 Forward-Port-Of: odoo/odoo#252679