Daily updates from Odoo
Friday, March 13, 2026
274 changes
14 changes
Resolved issues and error corrections
This update resolves an issue where the HTML editor wasn't accurately reflecting changes made by users. Previously, multiple edits within the same field could lead to incorrect status indicators. Now, the system reliably tracks changes within the HTML editor, ensuring users receive accurate feedback and can correctly update content.
Original PR description
Prior to this commit, it was possible to: - make change A inside a html_field - save/commitChanges - make change B inside the html_field, before the end of the save/commitChanges - the field ends up incorrectly marked as "not dirty" (user can't use the FormStatusIndicator) even though change B was not committed yet. Solution: Give an id to the dirtiness, and associate that id with an extracted value from the editor. When the record update is done, mark the field as not dirty ONLY IF the current dirty id is the same as the id previously associated with the extracted value, else the field stays dirty. task-5976348 Forward-Port-Of: odoo/odoo#253280 Forward-Port-Of: odoo/odoo#252655
This update fixes an issue where social media posts weren't correctly displaying blog post cover images. The change ensures the correct image format is used when generating social media content, resolving a problem caused by a recent code update. This improves the visual consistency of blog posts shared on social media.
Original PR description
Scenario:
- set cover image of a blog post
- post blog post on social media (or check og:image/twitter:image tags)
Result: the social media is a dead image like:
http://site/blog/1/"/web/image/3198-3915f222/cover%20image.webp"
Cause: the code setting social image expected it to be in the
cover_properties background-image in url('{image}') or url({image})
format, but since 1b0852948c070d4d936bd00b3dd1c0e5501a1300 the format is
url("{image}") so it was gotten incorrectly.
Fix: also strip doubles quote and have the code working with
cover_properties background image with:
- no quote: for cover_properties before 18.4
- single quote: not sure in what situation this can happen
- double quote: for cover_properties since 18.4
opw-5471804
Forward-Port-Of: odoo/odoo#253206
Forward-Port-Of: odoo/odoo#252028This update resolves intermittent test failures in the sign-up process by using dedicated, consistent test users instead of the default 'admin' and 'demo' accounts. This ensures test results are reliable and predictable, improving the quality and stability of our sign-up feature.
Original PR description
Relying on the default `admin` and `demo` users caused random runbot failures, as their access rights can be altered by other modules. This commit replaces them with freshly created test users to strictly simulate the presence or absence of the `sign.group_sign_user` group, ensuring the test remains deterministic. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/241216 Forward-Port-Of: odoo/enterprise#110454
This update fixes a potential security vulnerability by properly escaping HTML within API request error messages. Previously, unescaped HTML could have been exploited. Additionally, a clipboard button has been added for easy copying of these error messages.
Original PR description
Before this commit: Request errors were unescaped. After this commit: Request errors are properly escaped. A clipboard and a collapse button were added for ease of use. Forward-Port-Of: odoo/odoo#253069 Forward-Port-Of: odoo/odoo#252767
This update corrects a bug where users weren't seeing all their ratings in helpdesk average rating views. The fix ensures that users associated with helpdesk teams, even if not directly listed in the team's member list, accurately reflect their ratings in these views. This improves the accuracy of customer feedback data.
Original PR description
Steps to reproduce: - Configure a helpdesk team to be viewable by the test user - Remove test user from member_ids of helpdesk team - With that team selected, create a helpdesk ticket assigned to test user - Submit a rating for the ticket as the customer - As the test user in the helpdesk app overview, click on today average rating or last 7 days average rating Current behavior: - In both views, the test user won't see ratings for tickets attached to helpdesk teams where they are not listed in member_ids Expected behavior: - In both views, the test user should see all ratings of assigned tickets regardless if they are included in a helpdesk team's member_ids Note: member_ids in helpdesk.team appear to be only used for auto assigning new helpdesk tickets, so checking member_ids doesn't account for all potential users working in a team opw-5949917 Forward-Port-Of: odoo/enterprise#109470 Forward-Port-Of: odoo/enterprise#109136
This update resolves an issue where image shape transformations (rotations and flips) were not being properly cleared when changing image shapes. A new button has been added to manually reset these transformations, ensuring consistent behavior and a better user experience when working with image snippets.
Original PR description
Image shape transformations (flip and rotate) were never reset when changing or removing a shape; the dataset persisted indefinitely. Additionally, there was no way to manually reset a transformation, without undoing each operation manually. This commit ensures the dataset is cleaned when SetImageShapeAction is called and introduces a new button to manually reset transformations. Steps to reproduce: - Drop a snippet with image - Apply `solid_blob_4` shape on image (supports transformation) - Rotate or flip the shape - Change to `solid_blob_2` (does not support transformation) - Switch back to `solid_blob_4`, the first transformation is still there, it should have been reset task-5972945 Forward-Port-Of: odoo/odoo#253279 Forward-Port-Of: odoo/odoo#250875
This update fixes a missing 'Reset' button for specific Spanish informational reports. A recent configuration change made the standard reset button invisible. This fix adds a dedicated reset button that appears when the reports are completed, ensuring data can be cleared correctly.
Original PR description
- The `Reset` button was missing from the dropdown menu for Spanish informational reports (Mod 130, 347, 349, 390). - This occurred because these reports were recently configured with `is_tax_return_type = False` in this [commit](https://github.com/odoo/enterprise/commit/d2b1d29542c0350c267fecffd70d3e288364d8ab). However, the standard reset button (`action_reset_tax_return_common`) is configured to be invisible when `is_tax_return` is false. - This fix adds a reset button specifically for these Spanish reports that appears when the report is completed. task-5214023 Forward-Port-Of: odoo/enterprise#110271 Forward-Port-Of: odoo/enterprise#104739
This update increases the time allowed for payment processing requests, addressing potential issues caused by network delays and device timeouts. Additionally, a unique identifier has been added to transaction logs, providing better traceability and helping us track payments more effectively.
Original PR description
Reason: = - Network Connectivity: Terminal devices send continuous heartbeat checks to the API. Network fluctuations can cause heartbeat failures. - Configuration Discrepancy: Devices have a 60-second processing limit, while the server timeout was set to 30 seconds. In this commit: = - Increased Request timeout from 35s to 60s to prevent premature failures due to device/server timeout mismatch and network delays. - Added SourceID to system logs for improved end-to-end transaction traceability. task-6012679 Forward-Port-Of: odoo/odoo#252420
This update fixes a server error that occurred when merging tables in the restaurant POS system. Specifically, the system now waits for order synchronization before completing the merge process, ensuring a smoother and more reliable experience for restaurant staff. This prevents errors and improves table management functionality.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs during table merge Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related: https://github.com/odoo/enterprise/pull/104577 Forward-Port-Of: odoo/odoo#252942 Forward-Port-Of: odoo/odoo#245162
This update fixes a server error that occurred when merging tables in the Point of Sale system, specifically when a table had no associated order. The fix ensures the system waits for order synchronization before merging, preventing the error and improving table management functionality. This enhances the reliability of the POS experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs while merging the tables Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related PR - https://github.com/odoo/odoo/pull/245162 Forward-Port-Of: odoo/enterprise#110052 Forward-Port-Of: odoo/enterprise#104577
This update ensures accurate subline totals in barcode scanning by requiring the 'stock.group_production_lot' setting to be active. Without this setting, the system fails to group lines correctly, leading to incorrect calculations. This fix was introduced to address an issue originating from a previous version update.
Original PR description
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the…
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings. https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498 ### Observation The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total. Without the production lot group active, the conditional checks will bypass the grouping process: https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187) ### Impact When stock.group_production_lot is disabled: - Lines remain ungrouped. - The total sum of the grouped line is never generated. - The test fails as it cannot find or validate the expected sub-line totals. This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) runbot-241109 Forward-Port-Of: odoo/enterprise#108908
This update fixes a technical problem that could prevent the Odoo Enterprise payroll module from being uninstalled correctly. Removing work entries previously caused lingering references, leading to an error. This ensures a smoother and more reliable uninstall process.
Original PR description
Purpose: After work entries removal, some references weren't removed from payroll `uninstall_hook` so a traceback happens when trying to uninstall the module. task-id: 5955553
This update ensures that taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't initially provided by the UrbanPiper system. Previously, taxes weren't applied if UrbanPiper didn't send tax information, and it was limited to India. Now, taxes are calculated using standard product tax rules, ensuring accurate pricing for all orders.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#110166 Forward-Port-Of: odoo/enterprise#106686
This update resolves an issue impacting the PnL and Balance Sheet reports specifically for French association companies. The changes address minor data discrepancies within the reports, ensuring accurate financial reporting without requiring a major system overhaul. This improves the reliability of financial data for our French association clients.
Original PR description
The aim of this commit is fixing the Pnl & Balance Sheet report in France for association company. This commit ensures that we don't have any duplicate errors in the PnL & Balance Sheet. We kept some errors in the Balance Sheet (especially about the brut - amort - net) as we can't use aggregation with groupby but the data are not really duplicated. no task id Forward-Port-Of: odoo/enterprise#110163
41 changes
Resolved issues and error corrections
This update optimizes the process of installing demo data in Odoo, preventing unnecessary API calls and email notifications. By avoiding these actions during installation on existing databases, the process runs faster and more efficiently. This improves the overall user experience and reduces server load.
Original PR description
Followup on https://github.com/odoo/odoo/pull/25086 to avoid making api calls, sending emails when installing demo data on an existing database Forward-Port-Of: odoo/odoo#252912
This update fixes a bug preventing payment methods from appearing in the customer portal. The issue stemmed from a misconfigured ID and a missing setting, which were corrected to ensure all payment options are displayed. This improvement ensures customers can easily see and select their preferred payment methods within the portal.
Original PR description
Versions: --- saas-19.1+ Issue -- Payment methods are not shown in portal page. Cause: --- In #212880 two issues were overlooked: 1. The payment portal entry ID is `payment_methods_portal_entry`, but the `should_show_portal_card` override was using the wrong external ID: `portal_payment_orders`. 2. The payment card should have `is_config_card=True`, which was missed. Because of this, the superclass implementation (which checks `is_config_card`) returns False and hides the card. Setting `is_config_card=True` would normally fix the issue, but it would require updating views for already existing databases. To avoid this, the override is adjusted to not `&` with the parent implementation. In master we can restore the `&` superclass. This change should have no negative impact since the issue only affects versions saas-19.1, saas-19.2 and there should be no custom overrides in saas versions. opw-6013786
This update resolves errors in the P&L and Balance Sheet reports specifically designed for French associations within Odoo Enterprise. The changes address inconsistencies in financial calculations, particularly related to 'brut - amort - net' figures, while maintaining existing data accuracy.
Original PR description
The aim of this commit is fixing the Pnl & Balance Sheet report in France for association company. This commit ensures that we don't have any duplicate errors in the PnL & Balance Sheet. We kept some errors in the Balance Sheet (especially about the brut - amort - net) as we can't use aggregation with groupby but the data are not really duplicated. no task id
This update guarantees that the 'To-Do' feature functions properly within Odoo Enterprise. Previously, uninstalling the 'To-Do' module could cause issues due to a dependency not being enforced. This change ensures the necessary components are installed, preventing these problems.
Original PR description
This commit backports the `project_enterprise_hr_todo` bridge module that ensures that `project-todo` is correctly installed in order to use the todo mail alias feature. Before, this requirement was not enforced so anyone uninstalling To-Do could experience some issue, as the feature would still be part the `project_enterprise_hr` module, even without `project_todo` installed.
This update fixes a bug that prevented users from seeing subtasks within the Kanban mobile view of tasks. The issue stemmed from a missing configuration element, now resolved. This enhancement improves the usability of the mobile task management experience.
Original PR description
Example of steps: - Install `industry_fsm` - Create a task with a subtask - Enable mobile view with devtools - Open a task - Navigate to sub-tasks tab - Traceback ``` TypeError: undefined is not an object (evaluating 'ctx['record'].parent_id.raw_value') ``` parent_id was missing from "view_task_kanban" opw-5981990
This update fixes an issue where average daily and weekly hours weren't calculated correctly when using the 'Define Amount of Hours per Day' option in employee schedules. The fix ensures accurate hour calculations based on duration, addressing a discrepancy in how the system processes schedule data.
Original PR description
## Short functional explanation of the error When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per…
## Short functional explanation of the error When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per week fields aren't computed correctly. ## Reproduction Steps 1. Go to Employee > configuration > Working Schedules. 2. Create a working schedule. Check the box Define Amount of Hours per day and in the Working Hours tab, remove all intendances. 3. Add a line for Monday, set the day period to Full Day and the duration in hours to 4. 4. Repeat the operation for tuesday and wednesday. ### Expected behavior As we have 3 days during which we work 4 hours, the average hours per day should be 4, and the total hours per week should be 12. ### Unexpected behavior The average hours per day and hours per week don't show the correct numbers. ## Origin of the issue We compute the hours per week with this method: https://github.com/odoo/odoo/blob/ae9fd7cc7d434d4b222c81aa58515c57d7426b65/addons/resource/models/resource_calendar.py#L690-L696 However, when we check the box `Define Amount of Hours per Day`, we don't set the attendances starting and ending hours. Instead, we work with duration hours. Therefore, when the box is checked, we have to compute the weekly hours with the field `duration_hours`, and not `hour_from` / `hour_to`. __ opw-5885571 Forward-Port-Of: odoo/odoo#248627
This update fixes an issue where the phone number input field on mobile devices was difficult to use due to overlapping buttons. The fix hides the button labels and adjusts the input width to ensure a clear and easy editing experience. This enhances usability for mobile users.
Original PR description
Steps to reproduce: 1. Install `contacts` 2. Create an individual contact with a phone number 3. Try to edit the phone number on the mobile Issue: - Unable to edit in mobile view Cause: - On mobile…
Steps to reproduce:
1. Install `contacts`
2. Create an individual contact with a phone number
3. Try to edit the phone number on the mobile
Issue:
- Unable to edit in mobile view
Cause:
- On mobile devices, the utility buttons (Call, SMS, WhatsApp) inside the phone widget consume significant horizontal space. Due to the flex layout, this forces the actual phone input field to shrink too much, making it hard/impossible to view or edit the number.
Solution:
- Hide the text labels of the utility buttons to save space, showing only the icons
- make input's width 100% on mobile screens in partner form
<table>
<thead>
<tr>
<th>Before</th>
<th>After</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">
<img
src="https://github.com/user-attachments/assets/a620d417-119e-4e28-a62b-f63031e72598"
alt="Before"
width="500"
/>
</td>
<td align="center">
<img width="500" height="354" alt="image" src="https://github.com/user-attachments/assets/6adc4c77-767d-491d-a468-8463c0f77666" />
</td>
</tr>
</tbody>
</table>
opw-5489021
Forward-Port-Of: odoo/odoo#246295This update corrects a calculation error in the HRA (House Rent Allowance) rules for employees in India. The change ensures that HRA percentages are accurately applied, aligning with standard India payroll practices and preventing incorrect payments. This update maintains consistent behavior for all Indian employees.
Original PR description
… fields - compute HRAMN from categories['BASIC'] with result_rate = l10n_in_hra_percentage * 100 - add python condition to skip the rule when HRA percentage is zero - keeps ind_emp behavior consistent with regular India payroll rules task-5964270 Forward-Port-Of: odoo/enterprise#108507
This update fixes an error in how outstanding amounts are calculated when a down payment is reversed with a credit note. Previously, the system incorrectly produced negative amounts, leading to inaccurate settlement calculations. The fix ensures the correct outstanding balance is displayed and processed, improving financial accuracy.
Original PR description
When having a down payment that is reversed by a credit note, the amount unpaid is wrongly computed. This is because we take the sum of invoice lines price total, regardless they come from invoice or credit note. Therefore we end up with negative value. Steps: - Have a SO for 500 - Make a downpayment for 300, confirm - Make a credit note for the downpayment invoice, confirm -> SO's amount unpaid is -100, it should be 500. If you now settle the SO, the amount unpaid will be -300 instead of 0. opw-5175562 Forward-Port-Of: odoo/odoo#253135 Forward-Port-Of: odoo/odoo#233248
This update resolves an issue where expense reports created from incoming emails weren't being generated due to a company mismatch. The fix ensures the system always uses the employee's company affiliation when creating the expense, regardless of the user's default company setting. This prevents errors and allows for seamless expense reporting from email.
Original PR description
**Steps to reproduce:** - Install Expenses - Activate "Incoming Emails" in the settings - Configure the expense Alias - Configure an "Incoming Mail Server" - Create a Branch for a company - Create a…
**Steps to reproduce:** - Install Expenses - Activate "Incoming Emails" in the settings - Configure the expense Alias - Configure an "Incoming Mail Server" - Create a Branch for a company - Create a User: * Email Address: [an existing email address] * Allowed Companies: [the parent company + the branch company] * Default Company: [the branch company] * User Types: Internal User - Create an employee for the user in the parent company - From the email address, send a PDF to the expense alias **Issue:** The expense is not created in the database due to a UserError: "Incompatible companies on records". **Cause:** When the email is received and treated, the system tries to create an expense. From the email address, it retrieves an employee that is linked to the expense. For the company of the expense, if a user is linked to the employee, it takes the default company of the user. Otherwise, it takes the company of the employee. In this case, the company set on the expense is the default company of the user (i.e. the branch company) and the employee set on the expense belongs to the parent company ; which triggers the UserError during the company check. **Solution:** Always use the company of the employee, even if there is a user linked to the employee. opw-5346809 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253313 Forward-Port-Of: odoo/odoo#249415
This update corrects a validation error that occurred when sending invoices to Peppol. The system previously used an outdated unit code ('QT') which is no longer compliant with UN/ECE standards. This fix ensures invoices meet current regulatory requirements for international exchange.
Original PR description
Currently, the Odoo UoM 'qt (US)' is converted to 'QT', which is not valid anymore. Based on investigation, this was originally set to QT following this link: https://unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_rev3_Annex2e.pdf But this document seems dated from 2005. Step to reproduce: - Create an invoice with a line with 'qt (US)' as UoM - Try to send the invoice to Peppol - You will get a validation error: "[BR-CL-23]-Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21" Also removed the link to unece.org since the link is no longer valid. opw-5961476 Forward-Port-Of: odoo/odoo#252803 Forward-Port-Of: odoo/odoo#252174
This update fixes an issue where the report editor in Studio was unintentionally influenced by default theme colors. The change prevents the report editor from using these colors, ensuring consistent styling and preventing conflicts with customizations. This improves the stability and predictability of report design.
Original PR description
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form `o-color-[n]` with n some integer) Those colors are a bit special (see…
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form `o-color-[n]` with n some integer) Those colors are a bit special (see full discussion on the opw) - Their existence is described in module `web` - Their CSS definition is implemented in module `html_editor` - Reports don't use them at all We probably don't want reports' style to be influenced by the presence or lack thereof of the html_editor module, which was originally made to customize the interface. Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo. This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them. After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor. 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#251446
This update resolves an issue where the Odoo Report Editor in Studio was unintentionally influenced by default theme colors. The change prevents users from customizing report styles with these colors, ensuring consistency and preventing potential styling conflicts. This improves the stability and predictability of report design within Studio.
Original PR description
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer) Those colors are a bit special (see full…
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)
Those colors are a bit special (see full discussion on the opw)
Their existence is described in module web
Their CSS definition is implemented in module html_editor
Reports don't use them at all We probably don't want reports' style to be influenced by the presence or lack thereof of the html_editor module, which was originally made to customize the interface.
Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.
This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.
After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.
see odoo/odoo#251446
opw-5892573
Forward-Port-Of: odoo/enterprise#109206This update fixes an issue where customers could inadvertently set subscription start dates to 'false,' leading to incorrect invoicing. The change prevents users from removing the start date, ensuring subscriptions are properly billed according to their agreed-upon terms. This maintains accurate subscription tracking and invoicing.
Original PR description
**Issue** Some customers were removing the `start_date` of subscriptions, leading to the subscription being considered free on the next invoicing. While there are legitimate use cases to edit the `start_date` of a running subscription, it should probably not be removed. opw-5325303 Forward-Port-Of: odoo/enterprise#104925
This update fixes a potential issue with Instagram polls by ensuring the system only requests the poll's ID after it's successfully published. This prevents errors from the Instagram API and improves the overall reliability of the poll creation process. The change includes updated tests to simulate API restrictions and ensure proper error handling.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325 Forward-Port-Of: odoo/enterprise#110094
This update resolves an issue where purchase events weren't sending the correct data to Google Analytics. The fix converts a JSON string received from the website into a proper object, ensuring all purchase details (like transaction ID and value) are accurately tracked. This improves the reliability of our e-commerce analytics.
Original PR description
## Description The `Tracking` interaction's `setup()` method reads order tracking info from the HTML `data-order-tracking-info` attribute and passes it directly to `_trackGa()` → `gtag()`. Since the…
## Description The `Tracking` interaction's `setup()` method reads order tracking info from the HTML `data-order-tracking-info` attribute and passes it directly to `_trackGa()` → `gtag()`. Since the DOM `dataset` API always returns strings, `gtag()` receives a JSON string instead of an object, causing GA4 to silently drop all purchase event parameters (`transaction_id`, `value`, `items`, etc.). Compare with `onAddToCart()` in the same file, which receives its data via `CustomEvent.detail` (already a JS object) and works correctly. **Impacted versions:** - 19.0 **Steps to reproduce:** 1. Configure a Google Analytics key in Website > Settings 2. Add a product to cart and complete checkout 3. On `/shop/confirmation`, inspect the dataLayer or GA4 debug view **Current behavior:** - `add_to_cart` event fires with correct ecommerce parameters (object) - `purchase` event fires with a JSON **string** instead of an object — GA4 silently drops the parameters **Expected behavior:** - `purchase` event fires with a parsed object containing `transaction_id`, `value`, `currency`, `tax`, `items` **Fix:** Add `JSON.parse()` to convert the data attribute string back to an object before passing it to `gtag()`. --- I hereby confirm I have signed the Odoo CLA (included in this PR as `doc/cla/corporate/comma.md`). Forward-Port-Of: odoo/odoo#253074
This update enhances the reliability of our automated tests by fixing a problem where temporary browser files weren't being properly removed. The changes use a more robust system to ensure cleanup happens consistently, regardless of test success. This improves test stability and reduces potential issues.
Original PR description
Trying to find out why I kept having a bunch of leftover `tmpsomethingsomethign_chrome_odoo` leftovers I realised #203412 had a bit of an error in the location of the `atexit.callback(browser.stop)`:…
Trying to find out why I kept having a bunch of leftover `tmpsomethingsomethign_chrome_odoo` leftovers I realised #203412 had a bit of an error in the location of the `atexit.callback(browser.stop)`: the temporary directory for the user data dir is created as soon as the browser is instantiated, but the cleanup is only recorded after a successful `navigate_to`, so if that (or a previous step e.g. authentication) fails then the tempdir is never cleaned up. Rather than just move the call up the body and re-introduce conditionals to `stop` to handle more partial initializations though, use the magic of ~~buying two of them~~ `ExitStack` to record cleanup requirements dynamically as the `ChromeBrowser` initialises. This initially used a bunch of `ExitStack.callback` calls with ad-hoc cleanup, but turns out most of these cases are better as CMs: - replace `mkdtemp` / `rmtree` by `TemporaryDirectory`, which Just Works as a CM - add context-manager methods to the screencaster classes (also remove `stop` which is redundant with `__exit__`) so they Just Work as CMs - convert `_chrome_start` and `_open_websocket` to `@contextmanager`... for obvious reasons This makes the relation between setup and cleanup clearer, as well as more self-contained in case we want to move stuff to a submodule eventually. It also ensures cleanups run in the correct order, and avoids having to deal with partial initializations. Keep `ChromeBrowser.stop` because it seems unnecessary to edit those out for now, but have it just `close` the exitstack (which runs all the registered cleanups). NOTE: it might make sense for `browser_js` to just use `ChromeBrowser.cleanup` instead of having its own exitstack, not entirely sure... Alternatively it might make sense for ChromeBrowser to *take* a CM as parameter... and / or for ChromeBrowser to *be* a CM? Forward-Port-Of: odoo/odoo#253035
This update fixes a technical issue causing excessive warnings within Odoo due to how we use the Werkzeug library. The fix ensures warnings are properly deduplicated, preventing unintended and duplicated notifications. This resolves a problem exacerbated by our worker processes.
Original PR description
Every manipulation of the warnings list flushes the warnings registry, which prevents `warnings.warn` from deduplicating `default`, `module`, and `once` actions, instead they all behave as if `always`. Because werkzeug.urls is used *a lot* in odoo, this causes warnings to be emitted continuously even if that's not intentional, something which is already an issue due to workers (every new worker has an empty warnings registry triggering duplicate warnings). Upstream fixed this issue in pallets/werkzeug#2692 which was merged in 2.3.4, but apparently we vendored 2.3.0 which didn't have these fixes. Forward-Port-Of: odoo/odoo#252427 Forward-Port-Of: odoo/odoo#252193
This update ensures invoices are generated correctly by only using bank accounts authorized for outgoing payments. The system now prioritizes customer and payment journal banks, preventing errors and improving the overall stability of the point-of-sale invoicing process.
Original PR description
Before this commit: --- - Invoice generation could fail when the selected partner or company bank did not allow outgoing payments. - The first available bank account was used without checking whether it was valid for out payments. After this commit: --- - Select only bank accounts that allow outgoing payments. - Prioritize customer banks for refunds, then payment journal banks, and finally company banks as fallback. - Prevent errors caused by untrusted or unsupported bank accounts. task-5954530 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253158 Forward-Port-Of: odoo/odoo#250062
This update resolves an issue in the Danish Nemhandel integration by adding a required attribute (`schemeID`) to the XML format. This ensures compliance with OIOUBL 2.1 standards, accurately representing buyer identifiers for Danish VAT reporting. The change improves data accuracy and avoids potential processing errors.
Original PR description
Nemhandel follows the OIOUBL 2.1 XML format. To specify the Buyer identifier, we use the <cac:PartyIdentification> node. But we are missing the `schemeID` attribute, which should be for DK "DK:CVR". This commit adds this attribute. opw-5232123 Forward-Port-Of: odoo/odoo#253132 Forward-Port-Of: odoo/odoo#250942
This update resolves an issue where button colors were being inconsistently adjusted for readability. The fix ensures that manual button colors selected through the Theme tab are used as intended, aligning with standard button styles. This improves the overall visual appearance and user experience.
Original PR description
Previously, we created a contrast-adjusted color for the `btn-outline` classes to ensure readability. This was also applied to manual colors selected via Theme tab, which made some inconsistencies…
Previously, we created a contrast-adjusted color for the `btn-outline` classes to ensure readability. This was also applied to manual colors selected via Theme tab, which made some inconsistencies with standard `btn`. This commit fixes that by providing the contrast-adjusted color only on default palettes, and use the manual color as is when selected in the Theme tab. task-5392258 | State | Before | After | |--------|--------|--------| | Normal | <img width="261" height="122" alt="image" src="https://github.com/user-attachments/assets/482ed97f-303c-4332-a748-1130a9ee5db7" /> | <img width="261" height="124" alt="image" src="https://github.com/user-attachments/assets/5e0b14ba-677a-480e-8aad-85c13f3a5f6e" /> | | Hover | <img width="261" height="124" alt="image" src="https://github.com/user-attachments/assets/87cec4fc-521c-4b36-84d3-81460cefa68c" /> | <img width="259" height="123" alt="image" src="https://github.com/user-attachments/assets/b17c309d-2b64-4dc2-a33b-e576831647e0" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239584
This update fixes a technical issue in the Odoo Studio view editor that was causing a crash when switching between fields. The fix ensures the sidebar correctly updates with the latest field information, preventing errors and improving the user experience. This resolves a previous instability in the Studio interface.
Original PR description
In studio, form editor: click on a field and check the sidebr is correct Click on another field, one that has the widget many2many_tags. Before this commit, there was a crash because the internals of the sidebar were computed with the wrong props (the old ones instead of the new ones) After this commit, there is no crash opw-6004776 Forward-Port-Of: odoo/enterprise#110284
This update resolves a display issue where the 'Threads' and 'Invite People' popovers in the Discuss app were excessively wide. The fix ensures these popovers have a fixed width, preventing them from expanding to fill the browser window, and also allows scrollable content within the popovers.
Original PR description
Before this commit, the "Threads" action in Discuss app had its popover width that would take the browser width. This happens because, althought there's a classname to limit its size…
Before this commit, the "Threads" action in Discuss app had its popover width that would take the browser width. This happens because, althought there's a classname to limit its size (`o-mail-Discuss-threadActionPopover`), this was applied on a part of popover and was ignored due to `mw-100 w-100`. This commit fixes the issue by replacing the classname `.o-mail-Discuss-threadActionPopover` with 2 CSS rules for all action panels in popover: ``` .popover:has(ActionPanel) => max-width .popover .ActionPanel-content => max-height ``` These 2 rules handle popover sizing as desired: fixed width for all these popovers, and max-height on the content part of the action panel. This fixes the problem of limited width for both 'Threads' and 'Invite People' popovers, in addition to handle scrollable content thanks to max-height. Before / After <img width="911" height="384" alt="Screenshot 2026-03-10 at 16 12 23" src="https://github.com/user-attachments/assets/f4b77fdb-f946-4d71-904a-d0b273fbe955" /> <img width="915" height="398" alt="Screenshot 2026-03-10 at 16 12 10" src="https://github.com/user-attachments/assets/b2e461e7-a39a-4698-bae0-421d9d87eccb" /> Forward-Port-Of: odoo/odoo#253100
This update fixes a visual inconsistency in the mega menu on mobile devices. Changing the navbar font style caused the back arrow to display with an incorrect font. The fix ensures the back arrow uses the standard Odoo UI icon font, maintaining a consistent and professional appearance.
Original PR description
Steps to reproduce: =================== 1. Go to webstie and add a mega menu 2. Change Navbar font (e.g. to "Arvo") 3. Switch to mobile view and open the mega menu -> the back arrow will have unexpected style. Cause: ====== The selector `.navbar .nav-link` applies the custom navbar font-family (e.g., "Arvo") to all `.nav-link` elements inside the navbar. The mega menu back button has classes `btn nav-link oi oi-chevron-left`, so it matches this selector. Since `.navbar .nav-link` has higher specificity than the base `.oi` class, the custom font overrides `font-family: 'odoo_ui_icons'`. Solution: ========= force the .oi font-family. opw-5949405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251394
This update ensures accurate sub-line total calculations in the stock barcode module. The change requires the ‘stock.group_production_lot’ setting to be active, which was missing in previous versions, causing test failures. This fix ensures correct aggregation of line totals when processing stock movements.
Original PR description
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the…
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings. https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498 ### Observation The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total. Without the production lot group active, the conditional checks will bypass the grouping process: https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187) ### Impact When stock.group_production_lot is disabled: - Lines remain ungrouped. - The total sum of the grouped line is never generated. - The test fails as it cannot find or validate the expected sub-line totals. This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) runbot-241109 Forward-Port-Of: odoo/enterprise#108908
This update resolves an issue where dashboard loading would fail if a user lacked read access to certain data models. The fix now checks data models with `sudo()` for those without user permissions, ensuring dashboards consistently load for all users. This improves the overall user experience and prevents unexpected dashboard failures.
Original PR description
## Description When opening a dashboard, `_dashboard_is_empty()` may call `search_count()` on one of the dashboard's main data models to decide whether sample data should be loaded. If the current user does not have read access to one of these models, `search_count()` raises an access error and the dashboard loading can fail, even though the user has access to the dashboard itself. To avoid this, only unreadable models are checked with `sudo()`, while readable models are still evaluated with the current user rights. This prevents the access error in `_dashboard_is_empty()` and allows the dashboard to open instead of failing early. Task: [5905166](https://www.odoo.com/odoo/project/2328/tasks/5905166) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252885 Forward-Port-Of: odoo/odoo#249784
This update ensures that stock availability notifications sent through the website's sales channels work reliably during automated testing. Previously, tests would fail because the website's associated partner lacked an email address. The fix provides a default email for test scenarios and prevents errors when the current user's email isn't available, ensuring consistent notification delivery.
Original PR description
This commit (https://github.com/odoo/odoo/pull/249299/changes) backported some changes concerning stock availability mails. The mail is now sent from the partner associated to the website. However, in nightly runbots, the partner associated to the website does not have any email, so an error is thrown This fix does two things : - Make sure the website's partner has an email when running the tests - Prevent the mails being sent with the current user's email as a last ressort, and let an error be thrown instead runbot-102934954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252968 Forward-Port-Of: odoo/odoo#251951
This update corrects a minor issue where the styling of popups wasn't always reflecting the most current state. The fix ensures that popup displays are always based on the current target, preventing inconsistencies and improving the overall user experience. This ensures popups appear correctly across different history steps.
Original PR description
The attribute change processor supposed to avoid changing the `display` property of the `style` attribute of the popup element when an history step is replayed (added in cce4527c85e3240ff50fa573b141bc5973a46c2e) was mistakenly using the old display value from the history instead of the current value of the target. This was usually not an issue because in the cases where those value differed, the popup was about to be revealed (or hidden) anyway to show the target at that history step. This commit keeps the value of the property `display` of the `style` attribute as it is currently on the target, instead of the value of what it should have been as registered by the history. task-5149984 Forward-Port-Of: odoo/odoo#253106
This update ensures that the Website Studio XML editor only translates views for the currently selected website, preventing unintended translations across all websites. The change modifies how the Studio editor retrieves related views, improving the user experience and aligning with website-specific translation settings. This resolves an issue where the default website's language was incorrectly used.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/odoo#252063 Forward-Port-Of: odoo/odoo#237000
This update ensures that Website Studio's translation features only apply to views within the Website module, preventing incorrect translations from being used in other parts of the system. The change corrects a bug where the default website's language was always used when editing Website Studio views, improving the accuracy of translations for Website-related content.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/enterprise#109572 Forward-Port-Of: odoo/enterprise#107459
This update fixes an issue where cancelled stock moves were incorrectly impacting the calculation of kit costs in sales orders. The fix ensures that only completed, finished stock moves are used when determining the value of kits, leading to more accurate sales reporting. This improves the reliability of sales order pricing.
Original PR description
Currently cancelled moves are also being used when getting the value. This is already done in the main method: https://github.com/odoo/odoo/blob/049321aa5e0d4271050b406477bac5fb788b410b/addons/stock_account/models/account_move_line.py#L67 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253028
This update resolves a potential memory issue in the Point of Sale (POS) system. Previously, the system retrieved all product unit of measure records, regardless of the products being used. This change now only retrieves the necessary records, optimizing performance and preventing potential memory errors, especially with large product catalogs.
Original PR description
Before this commit, while opening a session in the POS, all the `product.uom` records were retrieved regardeless of what products were loaded. This might cause a memory error in cases where a lot of records are being retrieved. A solution for this is to retreive the records **only related to the `product.product` records being retrieved**. opw-5408586 ___ I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240613
This update resolves a technical error that was causing tests for the Replenish Wizard to fail. The fix ensures the wizard functions correctly and prevents disruptions to purchase order processes. This improves the stability and reliability of the Odoo system.
Original PR description
Runbot error 241249 Forward-Port-Of: odoo/odoo#252727
This update addresses a memory issue that occurred when calculating depreciation, particularly with large numbers of asset records. The fix utilizes a more efficient method to process the data, preventing the system from running out of memory and ensuring stable performance. This resolves a problem previously seen in the 16.0 version.
Original PR description
The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the…
The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the calculation using sql and reduce memory usage.
Note: the issue is faced during 16.0 version too but as 16.0 is no more supported for bug fix. So, doing it from 17.0 version.
```
Traceback (most recent call last):
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 657, in mock_view_tree
self.mock_web_search_read(model, view, [domain], fields_list)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 691, in mock_web_search_read
data = model.search_read(domain=domain, fields=fields_list, limit=80, order=filter_order(model))
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5074, in search_read
result = records.read(fields, **read_kwargs)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3038, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3219, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 98, in determine
return needle(*args)
File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in _compute_value_residual
posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in <lambda>
posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1187, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3245, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3351, in _read
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/16.0/odoo/api.py", line 1123, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```
opw-5921410
upg-3891767
Forward-Port-Of: odoo/enterprise#109008This update fixes a technical issue related to how the system maps CPV codes for Romanian invoices (CIUSRO). The incorrect code 'CPV' was previously used, while the correct code 'STI' aligns with European regulations and PEPPOL standards. This ensures accurate invoice processing and compliance.
Original PR description
The value of `ItemClassificationCode/listID` that corresponds to `CPV` classification is `STI` not `CPV`. See https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/ task-5416833 Forward-Port-Of: odoo/odoo#251311 Forward-Port-Of: odoo/odoo#250045
This update ensures that our UY e-invoicing process can correctly validate invoices by granting necessary permissions to access company data. Previously, users without specific group access would encounter validation errors. This change resolves a technical issue preventing proper invoice processing for Uruguay.
Original PR description
This pull request makes a small update to the `_ucfe_inbox` method in `l10n_uy_edi_document.py` to ensure that company-specific fields are always accessed with the appropriate permissions. This is achieved by using the `sudo()` method when retrieving the `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields from the `company` record. * Ensured that `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields are accessed with elevated permissions by calling `company.sudo()` in the `_ucfe_inbox` method (`l10n_uy_edi_document.py`). Without this fix, if the user doesn't belong to group "base system", it won't be able to validate CFEs, receiving the following message: <img width="1272" height="400" alt="image" src="https://github.com/user-attachments/assets/ec4223fb-5b96-4a3e-babf-2f6a35ecd123" /> Forward-Port-Of: odoo/enterprise#105918
This update fixes a technical issue where archiving a product linked to an open restaurant order caused a 'TB' error in the Point of Sale (POS). Previously, archiving a product associated with a future order also triggered this error. This change ensures a smoother POS experience by correctly handling archived product synchronization.
Original PR description
When we archived a product which was in a open order not already synced with the backend, when we went back to the POS, a TB appeared. In the same way, if we had an order in the future with a product and we closed the POS, archive the product and went back to the POS, the same TB appeared. task: 6002762 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252211
This update resolves latency issues experienced on iOS devices when interacting with the Point of Sale system. The fix involves adjusting how the system responds to touch input, specifically addressing differences between iOS and Android devices. Additionally, pinch-zoom functionality has been disabled to ensure a smoother user experience.
Original PR description
On IOS devices, there was a latency issue when hitting different elements in the POS and self. Actually, the issue is because IOS devices don't react in the same way as Android devices. IOS adds a delay of +/-300ms when the element is not considered as a button. Instead of replacing a lot of elements with a button element we can add the parameter role="button". I also disabled the pinch zoom in the POS, self and preparation display. It's mandatory to add the parameter touch-action: pan-x pan-y to the * selector. task: 5976364 enterprise pr : https://github.com/odoo/enterprise/pull/109483 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251198
This update resolves latency issues experienced by users on iOS devices when interacting with the Point of Sale system. The fix addresses differences in how iOS and Android devices respond to user input, specifically by adding a 'role="button"' parameter to elements. Additionally, pinch-zoom functionality has been disabled to ensure a smoother user experience.
Original PR description
On IOS devices, there was a latency issue when hitting different elements in the POS and self. Actually, the issue is because IOS devices don't react in the same way as Android devices. IOS adds a delay of +/-300ms when the element is not considered as a button. Instead of replacing a lot of elements with a button element we can add the parameter role="button". I also disabled the pinch zoom in the POS, self and preparation display. It's mandatory to add the parameter touch-action: pan-x pan-y to the * selector. task: 5976364 community pr : https://github.com/odoo/odoo/pull/251198 Forward-Port-Of: odoo/enterprise#109483
This update resolves an issue preventing users with multiple companies from successfully setting up their Amazon accounts. The fix allows access to all company data during the onboarding process, ensuring compatibility with connected Amazon accounts. This improves the onboarding experience for all Odoo Enterprise users.
Original PR description
The onboarding return route is a website route with access restricted to the website company only. This causes an error when the company doesn't match the Amazon account being connected. This commit allows users to access all their companies during Amazon account setup to avoid this mismatch error. opw-5944078 Forward-Port-Of: odoo/enterprise#109882 Forward-Port-Of: odoo/enterprise#109590
This update resolves a problem where the media dialog in the product editor would sometimes hang indefinitely. The fix ensures that the UI is always released after an action, regardless of its outcome, and improves the loading process for media assets. This prevents frustrating delays for users adding images to product pages.
Original PR description
*: website_sale Commit [1] added a UI block when doing a reloadable operation, and unblocked it once the action finished. However, if the action didn't complete, `ui.unblock` would never be called,…
*: website_sale Commit [1] added a UI block when doing a reloadable operation, and unblocked it once the action finished. However, if the action didn't complete, `ui.unblock` would never be called, leaving the UI blocked indefinitely. To reproduce the issue in website_sale: - Install Website & eCommerce - Go to /shop page - Open a product page - Open the editor - Click on the main product image - In the "Images" section > Click on "Add more" in the Extra media field - Popup shows up but it loads indefinitely Fix this by always calling `ui.unblock` regardless of the reload outcome. Also move the media dialog opening to `load`, which runs before the UI is blocked, passing the selected media as `loadResult` to `apply`. [1]: https://github.com/odoo/odoo/commit/453b7eb8e038ee8e8a54de16fc1a45fb2fab573a Co-authored by: Robin Lejeune (role) <role@odoo.com> opw-6003505, opw-6006393, opw-6016898, opw-6013484, opw-6014383 Forward-Port-Of: odoo/odoo#253025 Forward-Port-Of: odoo/odoo#252755
4 changes
Resolved issues and error corrections
This update fixes an issue where equity reports were incorrectly using outdated currency rates for certain accounts. The change reordered a key statement within the report calculation, ensuring that the correct, current rate conversion is applied. This ensures accurate reporting of equity values.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update clarifies potential errors (specifically code 9004) that users might encounter when using the Instagram integration within Odoo. By providing clearer explanations, this helps users troubleshoot issues themselves and reduces the need to contact support. This improves the overall user experience and stability of the Odoo Enterprise platform.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#110456 Forward-Port-Of: odoo/enterprise#109319
This update resolves an issue preventing certain report customizations within Odoo’s Studio. Specifically, a configuration change was made to ensure Studio correctly recognizes and utilizes necessary elements for table layouts, allowing for more flexible report design. This also addressed a previous bug where power buttons weren't appearing in Studio reports.
Original PR description
Description of the issue: Commit [1] replaces `overlay` with `localOverlay` for the table menu. However, studio uses its own `wysiwyg` instance and config, which does not define `localOverlayContainers`, causing a traceback when `table_menu` accesses `this.config.localOverlayContainers.key`. Solution: - Define `localOverlayContainers` and its corresponding key in studio’s `wysiwyg` config. - Additionally, adjust the table menu position calculation when the table cell is inside an iframe. - Also Before `localOverlayContainers` was not defined in studio, so power buttons did not appear in studio reports. Now that `localOverlayContainers` is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250645 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Forward-Port-Of: odoo/enterprise#108874 Forward-Port-Of: odoo/enterprise#108724
This update resolves an issue where changing the 'Kitchen Note' on a food item after an initial order update would cause an error. The fix ensures that the note can be updated successfully, regardless of previous quantity changes, improving the reliability of the POS system. This prevents order disruptions and ensures accurate order information.
Original PR description
**Steps to Reproduce:** - Install `pos_restaurant_preparation_display`. - Open Register for POS "**Restaurant**" Shop. - Choose table > select food-item > send the order. - Update food-item quantity > send the updated order. - Update food-item '**Kitchen Note**' > send the note. **Error:** `TypeError - 'NoneType' object is not subscriptable` **Cause:** When the food quantity is updated, a new preparation entry is created for the increased quantity. During the first iteration, the display and order quantities are already merged correctly. However, in a subsequent iteration, the original key no longer exists in `quantity_data`. As a result, accessing a None value leads to a traceback. **Fix:** This commit skips the merge step when the original quantity entry has already been merged. sentry-7197024946 Forward-Port-Of: odoo/enterprise#110184 Forward-Port-Of: odoo/enterprise#104889
6 changes
Resolved issues and error corrections
This update fixes a calculation error in the equity reports. Previously, `equity_unaffected` accounts were incorrectly using 'historical' currency rates. The change reorders the CASE statement to ensure these accounts use the correct, current rate conversion, leading to more accurate financial reporting.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update addresses a common error (code 9004) users were encountering with the Instagram integration in Odoo. The fix provides clearer, more helpful messaging to guide users in troubleshooting potential network or file-related issues, reducing the need to contact support. This improves the overall user experience and stability of the Odoo Enterprise platform.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#110456 Forward-Port-Of: odoo/enterprise#109319
This update resolves an issue preventing Argentinian companies with 'IVA Sujeto Exento' (VAT exempt) AFIP responsibility types from creating 'Export Invoices' documents. Previously, the system restricted this functionality. This change ensures compliance and allows businesses to properly generate export invoices as required by Argentinian tax regulations.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Create a Argentinian company with "AFIP Responsibility Type" set to "IVA Sujeto Exento" (VAT exempt) - Switch to the created company - In Accounting settings, set up "AFIP Web Services" - Create a journal for export invoices - Create a customer with "AFIP Responsibility Type" set to "Cliente del Exterior" - Create an invoice - Select the created customer - Try to set the document type for export invoices **Issue:** It is not possible to select "(19) EXPORT INVOICES" as "Document Type" for companies having "AFIP Responsibility Type" set to "IVA Sujeto Exento". It is not because the company is "VAT exempt" that it should not be able to create an export invoice. opw-5974268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252232
This update corrects a naming error in the ZUGFeRD eInvoice XML file generated by our accounting module. Previously, the file was named incorrectly, causing validation issues with several key e-invoice validators. Now, the file name aligns with accepted standards, ensuring proper processing and compliance with German regulations.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252681
This update fixes a minor issue where closing the emoji or GIF picker wouldn't always allow it to reopen immediately. The fix ensures the picker state is correctly reset, providing a smoother and more reliable user experience when selecting emojis or GIFs. This improves usability for all users.
Original PR description
**Current behavior before PR:** When the GIF or emoji picker is dismissed by clicking outside, the component state remains out of sync because `props.onClose` isn't triggered. This causes the next attempt to open the picker to fail, requiring an extra click from the user. **Desired behavior after PR is merged:** Closing the picker now correctly triggers the `props.onClose`. This ensures the component state is always reset, allowing the picker to reopen immediately on the next click. task-[5953015](https://www.odoo.com/odoo/project/1519/tasks/5953015) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250630
During migration, the `l10n_pl` end-migrate script was loading for every company using the `pl` chart template, including child companies. However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies. Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration. To prevent this, restrict chart loading to root
Original PR description
During migration, the `l10n_pl` end-migrate script was loading for every company using the `pl` chart template, including child companies. However, account codes must be…
During migration, the `l10n_pl` end-migrate script was loading
for every company using the `pl` chart template, including child companies.
However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies.
Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration.
To prevent this, restrict chart loading to root companies only, which is consistent with how account code uniqueness is enforced.
**Steps to reproduce:**
1. Create a database in 17.0
2. Install `account_accountant` and `l10n_pl`
3. Create a child (branch) for the company using the `pl` chart template
4. Migrate the database to 18.0
5. Migration fails with duplicate account code validation errors
**Traceback**
```py
Traceback (most recent call last):
File "/home/odoo/odoo18/community/odoo/service/server.py", line 1366, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/odoo18/community/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/odoo18/community/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/odoo18/community/odoo/modules/loading.py", line 523, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 222, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 259, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/odoo18/community/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
Template._load_data({'account.account': Template._get_account_account('pl')})
File "/home/odoo/odoo18/upgrade/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
return super()._load_data(data, *args, **kwargs)
File "/home/odoo/odoo18/community/addons/account/models/chart_template.py", line 677, in _load_data
created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals, ignore_duplicates=ignore_duplicates)
File "/home/odoo/odoo18/community/odoo/models.py", line 5531, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
File "/home/odoo/odoo18/community/odoo/models.py", line 5435, in _load_records_create
records = self.create(vals_list)
File "<decorator-gen-196>", line 2, in create
File "/home/odoo/odoo18/community/odoo/api.py", line 498, in _model_create_multi
return create(self, arg)
File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 987, in create
records._ensure_code_is_unique()
File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 1064, in _ensure_code_is_unique
raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 01.000.100, 01.000.200, 01.000.400, 01.000.900, 02.000.100, 02.000.200, 02.000.300, 02.000.900, 03.000.100, 03.000.200, 03.000.300, 03.000.400, 03.000.500, 03.000.600, 03.000.700, 03.000.800, 03.000.900, 03.050.100, 03.050.200, 03.050.300, 03.050.900, 07.010.200, 07.010.300, 07.010.400, 07.010.500, 07.010.600, 07.020.100, 07.020.200, 07.020.300, 07.030.100, 07.030.200, 08.000.100, 08.000.200, 08.000.300, 08.000.400, 08.000.500, 10.000.100, 10.000.200, 10.000.900, 13.000.100, 13.000.200, 13.000.900, 14.000.100, 14.000.200, 14.000.900, 14.050.100, 20.000.100, 20.000.200, 20.000.300, 21.000.100, 22.000.100, 22.010.100, 22.010.200, 22.010.300, 22.020.100, 22.020.200, 22.020.300, 22.030.100, 22.030.200, 22.030.300, 22.030.400, 22.030.500, 22.030.600, 23.000.100, 23.000.200, 23.000.900, 24.010.100, 24.010.200, 24.020.100, 24.020.200, 24.030.100, 24.030.200, 24.030.300, 24.030.400, 24.050.100, 24.090.100, 24.090.200, 24.090.300, 24.090.900, 28.000.100, 29.000.100, 29.010.100, 29.020.100, 30.000.100, 30.000.200, 30.000.300, 30.000.400, 30.000.500, 30.000.600, 30.000.700, 30.000.800, 30.000.900, 31.010.100, 31.060.100, 31.090.100, 33.000.100, 33.000.200, 33.000.300, 33.000.400, 33.000.500, 33.000.600, 34.010.100, 34.020.100, 34.020.200, 34.020.300, 34.020.400, 34.060.100, 34.070.100, 39.000.100, 40.000.100, 40.010.100, 40.010.200, 40.010.300, 40.010.400, 40.010.900, 40.020.100, 40.020.200, 40.020.300, 40.020.400, 40.020.500, 40.020.600, 40.020.700, 40.020.900, 40.030.100, 40.030.200, 40.030.300, 40.030.400, 40.030.500, 40.030.600, 40.030.700, 40.030.800, 40.030.900, 40.040.100, 40.040.200, 40.050.100, 40.050.200, 40.050.300, 40.050.900, 40.090.100, 49.000.100, 49.000.200, 49.000.300, 49.000.400, 50.000.100, 50.000.200, 50.010.100, 50.010.200, 52.010.100, 52.070.100, 53.000.100, 53.000.200, 55.000.100, 55.000.200, 58.000.100, 60.000.100, 60.010.100, 60.020.100, 62.000.100, 62.010.100, 64.000.100, 64.010.100, 65.000.100, 65.010.100, 70.000.100, 70.000.200, 70.000.300, 70.000.400, 70.010.100, 70.010.200, 70.010.300, 70.010.400, 73.000.100, 73.000.200, 73.000.300, 73.000.400, 73.010.100, 73.010.200, 73.010.300, 73.010.400, 74.000.100, 74.000.200, 74.000.300, 74.010.100, 74.010.200, 74.010.300, 75.000.100, 75.000.200, 75.000.300, 75.000.400, 75.000.500, 75.000.600, 75.000.700, 75.000.900, 75.010.100, 75.010.200, 75.010.300, 75.010.400, 75.010.500, 75.010.900, 76.000.100, 76.000.200, 76.000.300, 76.000.400, 76.000.900, 76.010.100, 76.010.200, 76.010.300, 76.010.900, 79.000.100, 79.000.200, 79.000.300, 79.000.400, 79.000.500, 80.000.100, 80.000.200, 80.000.300, 80.000.400, 81.010.100, 81.020.100, 81.030.100, 81.040.100, 82.000.100, 83.000.100, 83.000.200, 83.010.000, 83.010.100, 83.010.200, 84.010.000, 84.020.100, 84.020.200, 85.010.100, 85.020.100, 85.020.200, 85.020.300, 86.000.100, 87.000.100, 87.000.900
```
**Fix:**
- Load `account.account` records only for root companies during When the chart template loads for `pl` localization.
opw-5932421
upg-3895331
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#2506549 changes
Resolved issues and error corrections
This update fixes an issue where customers could inadvertently set subscription start dates to 'false', leading to incorrect invoicing. The change prevents this action, ensuring subscriptions are properly tracked and billed accurately. This resolves a potential revenue discrepancy.
Original PR description
**Issue** Some customers were removing the `start_date` of subscriptions, leading to the subscription being considered free on the next invoicing. While there are legitimate use cases to edit the `start_date` of a running subscription, it should probably not be removed. opw-5325303 Forward-Port-Of: odoo/enterprise#104925
This update fixes a potential issue with Instagram polls by ensuring the system only requests the unique ID ('ig_id') after a poll has been successfully published. This prevents errors from the Instagram API and improves the overall reliability of the poll creation process. Updated tests now accurately simulate API behavior, ensuring consistent results.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325 Forward-Port-Of: odoo/enterprise#110094
This update ensures Odoo invoices sent to the AFIP web service (ARCA) comply with their strict requirements for numeric fields like price and quantity. By limiting precision to 3 decimal places, we prevent invoice rejections and maintain accurate accounting data. This change aligns with AFIP's specifications and ensures consistent rounding across all monetary values within Odoo.
Original PR description
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects…
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects the invoice with errors like: `Code 1814: Campo Cmp.Items.Pro_precio_uni invalido. El valor debe tener 12 enteros y 6 decimales como máximo.` To ensure compliance, values are formatted before sending the request to ARCA. **Precision rationale** ARCA WS documentation mentions 4 decimal places, while the WS error message itself refers to 6 decimals, and in practice the service accepts up to 6 decimals without rejection. In this implementation, we intentionally use 2 decimal places. The reason is consistency with the rest of the monetary amounts in the invoice: line totals, invoice total, taxes, and related amounts are all rounded to 2 decimals, even in cases where the documentation allows higher precision (e.g., 3 decimals). Before the changes in rounding precision, the stable version already rounded values according to line rounding. In real-world accounting scenarios, the vast majority of use cases operate with 2 decimal places. Keeping this behavior ensures consistency across calculations and avoids discrepancies caused by mixed rounding strategies. For a stable release, this was considered the safest and most predictable option, even though the WS technically allows higher precision. Stable version changes are covered in the following commits: https://github.com/odoo/odoo/pull/243987/changes/8a21ec45f9d72a7c80d9c1f8398fe01e298ae775 https://github.com/odoo/odoo/pull/246347/changes/79ceeed707ef274f19a04e741f6cb8ac60c44321 <img width="780" height="435" alt="image" src="https://github.com/user-attachments/assets/9f25a0e8-b9d2-4ad2-bbcf-e988c7f8a4c9" /> [WSFEX - Manual de desarrollador](https://www.afip.gob.ar/ws/WSFEX/WSFEX-Manualparaeldesarrollador.pdf) Forward-Port-Of: odoo/enterprise#106509
This update resolves an issue preventing access to fiscal data within the Point of Sale (POS) system. By loading a necessary module, the POS now correctly supports features related to fiscal data processing. This ensures accurate reporting and compliance.
Original PR description
Before this commit, the field iface_fiscal_data_module was not loaded in the pos_self_data, which caused it to be unavailable in the js side of the pos. This commit adds the field to the list of loaded fields, making it available for use in the js code. opw-6034196
This update addresses a memory issue that was causing slowdowns when calculating depreciation for large customer records. The fix uses a more efficient method to process depreciation data, improving performance and stability. This resolves a previous issue impacting version 16.0.
Original PR description
The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the…
The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the calculation using sql and reduce memory usage.
Note: the issue is faced during 16.0 version too but as 16.0 is no more supported for bug fix. So, doing it from 17.0 version.
```
Traceback (most recent call last):
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 657, in mock_view_tree
self.mock_web_search_read(model, view, [domain], fields_list)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 691, in mock_web_search_read
data = model.search_read(domain=domain, fields=fields_list, limit=80, order=filter_order(model))
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5074, in search_read
result = records.read(fields, **read_kwargs)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3038, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3219, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 98, in determine
return needle(*args)
File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in _compute_value_residual
posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in <lambda>
posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1187, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3245, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3351, in _read
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/16.0/odoo/api.py", line 1123, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```
opw-5921410
upg-3891767
Forward-Port-Of: odoo/enterprise#109008This update resolves an issue where users couldn't properly validate UY CFEs due to permission restrictions on company data. The change adds `sudo()` access to retrieve necessary company information, guaranteeing correct validation and preventing errors. This ensures accurate processing of UY-related documents.
Original PR description
This pull request makes a small update to the `_ucfe_inbox` method in `l10n_uy_edi_document.py` to ensure that company-specific fields are always accessed with the appropriate permissions. This is achieved by using the `sudo()` method when retrieving the `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields from the `company` record. * Ensured that `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields are accessed with elevated permissions by calling `company.sudo()` in the `_ucfe_inbox` method (`l10n_uy_edi_document.py`). Without this fix, if the user doesn't belong to group "base system", it won't be able to validate CFEs, receiving the following message: <img width="1272" height="400" alt="image" src="https://github.com/user-attachments/assets/ec4223fb-5b96-4a3e-babf-2f6a35ecd123" /> Forward-Port-Of: odoo/enterprise#105918
This update resolves an issue where employees were incorrectly appearing in payslip generation wizard results due to a misinterpretation of contract status. The fix ensures that employees are only included if they have a valid, active contract matching the selected salary structure type, improving the accuracy of payslip calculations.
Original PR description
**Steps to reproduce** - Create an employee - Have a first contract in "New" state covering some period of the month with "Salary Structure Type" A. - Have a second contract in "Running" state covering some other period of the month with "Salary Structure Type" B. - Go to the payslip batch for the current month and click on "Generate payslips". - In the wizard, select "Salary Structure Type" B: employee appears in the list as expected. - In the wizard, select "Salary Structure Type" A. - Unexpected: employee appears in the list, although the contract using that structure type is not in an open or closed state. **Cause** Employees were displayed if they had a contract in open/close state AND a contract with the matching structure type, but we need to check if there's some contract matching both conditions (correct state AND matching structure type). A new function is added to be able to inject an extra domain. opw-5443624 Forward-Port-Of: odoo/enterprise#104016
This update fixes an issue where equity reports were incorrectly using historical currency rates for certain accounts. By reordering the CASE statement, the system now accurately applies the appropriate rate conversion, ensuring more precise reporting of equity values. This improves the reliability of financial data.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update resolves a technical issue causing Odoo servers to display error code 9004 when Instagram integration encounters network or file-related problems. By providing clearer explanations for this error, users can now self-diagnose and troubleshoot Instagram issues without needing to contact support. This improves the overall user experience and reduces support requests.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#110456 Forward-Port-Of: odoo/enterprise#109319
4 changes
Resolved issues and error corrections
This update adds a warning to the system when a customer manually changes payroll rules defined in data files. This prevents accidental overrides of standard rules and ensures customers always have access to the latest, approved settings. Users can then reset the rule to re-apply the current data files.
Original PR description
Usually, rules that are defined in the data of modules are automatically updates on the customers database even if they modified those rules manually. To prevent overriding the modifications by the customers, we add a warning when a rule from data has been modified by the user. The user can then choose to reset the rule, thus upgrading it again from the current data files. Task: 5917278
A recent update resolved an error preventing demo users without payroll permissions from accessing the attendance app. The fix involved adding a check to prevent unnecessary data requests, ensuring the app functions correctly for all users. This improves the user experience and prevents disruptions to payroll processes.
Original PR description
Steps : - Settings -> Users -> Manage Users -> marc demo - make sure the demo user has no rights over HR apps - go into debug mode -> check "User: Read his own attendances" - Connect using the demo…
Steps : - Settings -> Users -> Manage Users -> marc demo - make sure the demo user has no rights over HR apps - go into debug mode -> check "User: Read his own attendances" - Connect using the demo user. - Try to access the attendance app or to click the monthly hours smart button from it's own employee form view. - you'll get an access error. Reason : - The `PayRunMixin` patches Attendance views globally and injects the `PayRunLayout`. Upon mounting, `PayRunLayout` unconditionally fetch the Kanban architecture for `hr.payslip.run`. This triggered a `get_views` RPC call that the backend rejected for users without Payroll rights. Solution : - Added an asynchronous ACL check inside the `onWillStart` hook of `PayRunLayout`. If the user does not have the `hr_payroll.group_hr_payroll_user` group, or if there is no active `payrun_id` in the context, the component aborts the `loadViews` request early, preventing the RPC call and the resulting crash. Task - 5965727
This update resolves a security vulnerability by preventing the use of public partner information within the Enterprise POS module. This change ensures data privacy and strengthens the overall security posture of the Odoo Enterprise platform. It corrects a potential risk related to data exposure.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/251472
This update ensures accurate subline totals in stock barcode transactions. The system now requires the 'stock.group_production_lot' setting to be active, which was introduced in the 18.3 release. Without this setting, the test fails to calculate the correct totals.
Original PR description
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the…
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings. https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498 ### Observation The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total. Without the production lot group active, the conditional checks will bypass the grouping process: https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187) ### Impact When stock.group_production_lot is disabled: - Lines remain ungrouped. - The total sum of the grouped line is never generated. - The test fails as it cannot find or validate the expected sub-line totals. This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) runbot-241109 Forward-Port-Of: odoo/enterprise#108908
7 changes
Resolved issues and error corrections
This update fixes an issue where certain salary deductions weren't being properly accounted for in payroll calculations. Specifically, the system now correctly incorporates 'ATTACH_SALARY' rules, ensuring accurate net pay figures for employees. This improves payroll accuracy and compliance.
Original PR description
**Behavior before this commit** Some salary rules (e.g. `ATTACH_SALARY`) were ignored in the NET calculation. **Behavior after this commit** - Four rules are now added to the "Total deductions" line: their sequence and category has been changed. - The sign of these lines has also been switched: an attachment of salary of a positive amount should be added to the amount of total deductions, which is then deducted from the net.  opw-5894647 Forward-Port-Of: odoo/enterprise#110071 Forward-Port-Of: odoo/enterprise#107033
This update resolves an issue where users were unable to correctly set start and end dates simultaneously within the Web Studio design tool. The fix prevents both date fields from being active at the same time, ensuring the date range field functions as intended and avoids invalid field markings. This improves the usability of the Web Studio interface for creating date-based forms and reports.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update ensures Odoo invoices sent to the AFIP (Argentina tax authority) comply with their strict requirements for numeric fields like price and quantity. By limiting these values to a maximum of 3 decimal places, we prevent invoice rejections and maintain accurate financial reporting. This change aligns with the AFIP's specifications and ensures consistent data formatting.
Original PR description
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects…
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects the invoice with errors like: `Code 1814: Campo Cmp.Items.Pro_precio_uni invalido. El valor debe tener 12 enteros y 6 decimales como máximo.` To ensure compliance, values are formatted before sending the request to ARCA. **Precision rationale** ARCA WS documentation mentions 4 decimal places, while the WS error message itself refers to 6 decimals, and in practice the service accepts up to 6 decimals without rejection. In this implementation, we intentionally use 2 decimal places. The reason is consistency with the rest of the monetary amounts in the invoice: line totals, invoice total, taxes, and related amounts are all rounded to 2 decimals, even in cases where the documentation allows higher precision (e.g., 3 decimals). Before the changes in rounding precision, the stable version already rounded values according to line rounding. In real-world accounting scenarios, the vast majority of use cases operate with 2 decimal places. Keeping this behavior ensures consistency across calculations and avoids discrepancies caused by mixed rounding strategies. For a stable release, this was considered the safest and most predictable option, even though the WS technically allows higher precision. Stable version changes are covered in the following commits: https://github.com/odoo/odoo/pull/243987/changes/8a21ec45f9d72a7c80d9c1f8398fe01e298ae775 https://github.com/odoo/odoo/pull/246347/changes/79ceeed707ef274f19a04e741f6cb8ac60c44321 <img width="780" height="435" alt="image" src="https://github.com/user-attachments/assets/9f25a0e8-b9d2-4ad2-bbcf-e988c7f8a4c9" /> [WSFEX - Manual de desarrollador](https://www.afip.gob.ar/ws/WSFEX/WSFEX-Manualparaeldesarrollador.pdf) Forward-Port-Of: odoo/enterprise#106509
This update fixes an issue where equity reports were incorrectly using outdated currency rates for certain accounts. The change reordered a key statement within the report calculation to ensure the correct, most recent rate type ('current') is applied, leading to more accurate financial reporting. This improves the reliability of equity-related financial data.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update fixes a bug where employee skills weren't automatically added to appraisals created by the system's automated scheduling process. The fix ensures that skills are correctly copied to all appraisals, regardless of how they're initially created, improving appraisal accuracy and data consistency. This prevents manual data entry for skills in these appraisals.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date…
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date to today 4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually 5. Open the newly created appraisal for the employee Observation: ------------------------------------- In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage Issue: ------------------------------------- When the cron `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via `create()`. The skill-copying logic only lived in the `write()` override, which triggers on state transitions from 'new' to 'pending'. Since `create()` bypasses `write()`, Employee skills were never copied to cron-created appraisals https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15 Solution: ------------------------------------- Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied. opw-5491433 Forward-Port-Of: odoo/enterprise#110170 Forward-Port-Of: odoo/enterprise#107760
This update ensures accurate subline total calculations in the barcode picking process. The fix addresses an issue where totals weren't being generated correctly when a specific setting (stock.group_production_lot) was inactive. This setting is now required for proper grouping and total calculation, particularly when using demo data.
Original PR description
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the…
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings. https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498 ### Observation The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total. Without the production lot group active, the conditional checks will bypass the grouping process: https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187) ### Impact When stock.group_production_lot is disabled: - Lines remain ungrouped. - The total sum of the grouped line is never generated. - The test fails as it cannot find or validate the expected sub-line totals. This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) runbot-241109 Forward-Port-Of: odoo/enterprise#108908
This update resolves an issue where changing the 'Kitchen Note' on a POS order after a quantity update would cause an error. The fix ensures that the note update works reliably, regardless of previous quantity adjustments, improving the user experience for order modifications.
Original PR description
**Steps to Reproduce:** - Install `pos_restaurant_preparation_display`. - Open Register for POS "**Restaurant**" Shop. - Choose table > select food-item > send the order. - Update food-item quantity > send the updated order. - Update food-item '**Kitchen Note**' > send the note. **Error:** `TypeError - 'NoneType' object is not subscriptable` **Cause:** When the food quantity is updated, a new preparation entry is created for the increased quantity. During the first iteration, the display and order quantities are already merged correctly. However, in a subsequent iteration, the original key no longer exists in `quantity_data`. As a result, accessing a None value leads to a traceback. **Fix:** This commit skips the merge step when the original quantity entry has already been merged. sentry-7197024946 Forward-Port-Of: odoo/enterprise#110184 Forward-Port-Of: odoo/enterprise#104889
7 changes
Resolved issues and error corrections
This update resolves an issue where credit notes were causing an infinite loop in a background process. The fix restricts the process to only monitor invoices, preventing unnecessary polling and ensuring efficient claim status updates. This improves system performance and stability.
Original PR description
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de…
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de documento no corresponde". Since the response never contains event data, l10n_cl_claim is never set, the record permanently matches the cron domain, and polling repeats every 4 hours forever. Root cause: the cron domain included out_refund move types, but the SII endpoint used to fetch claim events does not support credit note document types. There is no point querying the SII for claim details on credit notes through this endpoint. Fix: restrict the cron domain to out_invoice only Before: claimed credit notes matched the cron domain, _get_dte_claim was called on every run, SII returned codResp 3, l10n_cl_claim stayed False, record never exited the domain. After: credit notes are excluded from the cron domain entirely and are never polled, stopping the infinite loop. opw-5933833
This update resolves an issue preventing Argentinian companies with 'IVA Sujeto Exento' (VAT exempt) status from creating 'Export Invoices'. The fix ensures that these companies can properly generate export invoices, aligning with AFIP regulations and improving business functionality. This change corrects a restriction that shouldn't have been in place.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Create a Argentinian company with "AFIP Responsibility Type" set to "IVA Sujeto Exento" (VAT exempt) - Switch to the created company - In Accounting settings, set up "AFIP Web Services" - Create a journal for export invoices - Create a customer with "AFIP Responsibility Type" set to "Cliente del Exterior" - Create an invoice - Select the created customer - Try to set the document type for export invoices **Issue:** It is not possible to select "(19) EXPORT INVOICES" as "Document Type" for companies having "AFIP Responsibility Type" set to "IVA Sujeto Exento". It is not because the company is "VAT exempt" that it should not be able to create an export invoice. opw-5974268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252232
This update corrects a naming issue with the ZUGFeRD e-invoice XML file, ensuring compatibility with various validation tools. Previously, the incorrect filename caused validation errors. Now, the file passes validation across multiple recognized e-invoice validators, improving the accuracy of invoice processing.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252681
This update fixes an issue where taxes weren't being assigned correctly to the right companies within Point of Sale sessions. The change ensures that taxes are sorted by company ID before grouping, preventing taxes from the same company from being split into multiple groups and ensuring accurate tax calculations.
Original PR description
itertools.groupby only groups consecutive elements. When taxes from different companies are interleaved in loaded_data, taxes from the same company get split into multiple groups, causing incorrect tax assignment per company. Sort the tax list by company_id before calling groupby to ensure all taxes per company are contiguous. opw-5931261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252954
This update resolves an issue where validating a delivery record would fail if the associated sale order was created without any order lines. The fix ensures a default sequence value of zero is used in these scenarios, preventing the 'max() arg is an empty sequence' error and allowing deliveries to be successfully validated. This improves the reliability of the sales order fulfillment process.
Original PR description
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and…
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and `confirm` it. - Go to `Inventory > Operations > Deliveries` and create a `picking record by adding a move line` with a `quantity` greater than `zero`. - In the `Additional tab`, select the `sale order (the one without order lines)`. - Now `validate` this delivery. **Error:** `ValueError: max() arg is an empty sequence` This error occurs because, during validation of the delivery record, the system attempts to `create a sale order line` for the product. If the sale order does not have any `existing order lines`, the system tries to determine the `sequence` from existing sale order lines. Since `no lines exist`, the `sequence list is empty` [1], raising the error. This commit ensures that when a sale order has no existing order lines, a default sequence value of zero is used. [1]- https://github.com/odoo/odoo/blob/9e404b52e8c9375a6534a67cfb0fcc0df523402b/addons/sale_stock/models/stock.py#L164 sentry-7089149997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that each self-order transaction receives a unique tracking number. Previously, all self-order orders displayed the same number, making it difficult to track individual orders. This fix resolves an accidental removal of a key line of code, restoring the correct tracking number generation.
Original PR description
Currently, all self order orders are showing the same tracking number. Steps to reproduce: ------------------- * Open restaurant config and enable self ordering * Open self in a first private navigator, place an order > Tracking number shows 500 * Close navigator and open a new one * Open self, place an order > Tracking number shows 500 Why the fix: ------------ The line re-introduced was removed here https://github.com/odoo/odoo/commit/f6e94c794c1ac685f1229835279ded5ea686cfad by accident, as the upper versions of the commit are still using it. opw-6022132
This update corrects a bug where loyalty programs weren't accurately tracking points when the pricelist feature was disabled. Previously, the system retained old pricelist configurations, leading to incorrect point accumulation. This fix ensures loyalty programs function correctly regardless of whether pricelists are enabled.
Original PR description
When `use_pricelist` is disabled, `available_pricelist_ids` retains previously configured pricelists. This caused loyalty programs restricted to a specific pricelist to still match and accumulate points incorrectly. opw-5952960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
8 changes
Resolved issues and error corrections
This update fixes an issue where sales order margins were incorrectly calculated due to a misunderstanding of the product's cost method. The fix ensures margins are accurately determined based on the company associated with the sales order line, regardless of the user's default company setting. This improves margin reporting accuracy.
Original PR description
Steps to reproduce: - Have 2 companies: - Company A with a property_cost_method 'average' - Company B with a property_cost_method 'standard' - Create a sales order in B - Set the default company of the user to A. - Under certain scenarios, when we confirm the sales order, there will be a `flush_all`. - When that's the case, margins are recomputed with `line.product_id.categ_id.property_cost_method` as `average` instead of `standard`. In other words, it will take the property_cost_method from the `user.company_id` (A), instead of the property_cost_method from the `line.company_id` (B). This fix ensures the `property_cost_method` considered is the one related to the company of the sale order line. A similar issue was fixed on https://github.com/odoo/odoo/pull/192890 OPW-5939464
This update resolves a minor typographical error in the help text associated with the 'Country State' field within the Odoo system. The misspelling of 'Departement' has been corrected, ensuring accurate and consistent user guidance. This change improves the overall user experience and data integrity.
Original PR description
Fixes #202198 Split from #249963 per reviewer feedback. **CLA sign-off:** Individual CLA signed (doc/cla/individual/vedantmadane.md)
This update resolves an issue where the copyright background color wouldn't display correctly on the website footer when no specific background color was set. The change adds a fallback value to ensure the copyright color is always visible, regardless of the footer's background color. This improves the website's appearance and consistency.
Original PR description
Before this commit, a css error would happen when the user tried to change the copyright background color if the footer had no background color.
This was due to $-footer-color not having a fallback value when neither o-color('footer-custom') nor o-color('footer') was defined.
This commit adds a fallback value to fix the issue.
task-5452457This update optimizes the validation process for purchase orders with many associated stock moves. By batching operations, the system reduces unnecessary database trips and improves performance, particularly for large deliveries. This results in faster order processing and a better user experience.
Original PR description
Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids. This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings. Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the `purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s). Benchmarks: | No. move lines in delivery | Before | After | | -------------------------- | ------- | ----- | | 7579 | Timeout | < 200 s | opw-5826905
This update corrects a bug where cancelled vendor bills were incorrectly included in the Sweden (l10n_se) SIE export file. The fix ensures that cancelled transactions are properly excluded, aligning the export data with the general ledger. This prevents inaccurate reporting and ensures data consistency.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999
This update addresses a technical issue within Odoo's Instagram integration that could cause error code 9004. The fix provides clearer explanations for this error, helping users troubleshoot problems on their Odoo servers without needing to contact support. This improves the overall user experience and reduces support requests.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#109319
This update resolves an issue where portal users assigned to individual contacts within a company couldn't post messages on related opportunities. The fix ensures that users always have the correct access rights by using the company's record instead of the contact's record, allowing them to perform actions like posting messages.
Original PR description
When a portal user is set on an individual contact belonging to a company, posting a message on an opportunity assigned to that company fails with an access error. ### Cause Before creating a…
When a portal user is set on an individual contact belonging to a company, posting a message on an opportunity assigned to that company fails with an access error.
### Cause
Before creating a mail.message, `_get_mail_message_access` is called to determine the ORM access level the user must hold on the document. The override for `crm.lead` returns `'read'` (sufficient for portal users) when the user is the assigned partner, checking:
lead.partner_assigned_id == self.env.user.partner_id
`partner_assigned_id` is the company set as the assigned partner. `user.partner_id` is the contact record of the logged-in user. When the portal user is an individual contact whose parent is the assigned company, the two records differ, the condition is False, `'write'` is required, and the portal user does not have it.
### Fix
Replace `user.partner_id` with `user.commercial_partner_id`, which always resolves to the top-level company regardless of whether the user is the company contact or one of its child contacts. This is consistent with `_assert_portal_write_access` in the same file, which already uses `commercial_partner_id` for the same reason.
opw-5913214This update fixes an issue where tax calculations in Point of Sale sessions were incorrect due to how taxes were grouped. The code now sorts taxes by company ID before grouping, ensuring that all taxes for a specific company are processed together and assigned accurately. This improves the reliability of tax calculations during sales transactions.
Original PR description
itertools.groupby only groups consecutive elements. When taxes from different companies are interleaved in loaded_data, taxes from the same company get split into multiple groups, causing incorrect tax assignment per company. Sort the tax list by company_id before calling groupby to ensure all taxes per company are contiguous. opw-5931261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr