Daily updates from Odoo
Friday, March 13, 2026
184 changes
21 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 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 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 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 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
This update adds a test to ensure the `_prepare_payment_data` method in the account online payment module functions correctly. The previous implementation relied on a field that was removed during a recent update, and this fix prevents potential issues with payment processing. It's a proactive measure to maintain system stability.
Original PR description
This commit safeguards the `_prepare_payment_data` method. Reason: We were using a field that no longer exists due to an oversight during a FW and having no tests to catch it. Fix here https://github.com/odoo/enterprise/pull/110266 No task ID
This update corrects a technical issue that previously caused export errors when working with worksheet templates in Odoo Enterprise. By removing outdated references to fields no longer present in the template, the export process now functions correctly and reliably.
Original PR description
Before this commit when exporting records from the `worksheet.template` model , it raises a traceback regarding the `model_id`, `action_id` which are not present on the `worksheet.template` anymore* In this commit we are updating the export logic by removing the custom logic for the `worksheet.template` model. *https://github.com/odoo/enterprise/pull/104754
A bug was preventing users from loading sample recruitment data. This fix updates the sample data to correctly reference the `recruiter_id` field, resolving a data parsing error. This ensures the recruitment scenario data can be properly loaded and used.
Original PR description
Currently an error occurs when user tries to load scenario data for recruitment. Steps to replicate: - Install `hr_recruitment`. - Open Recruitment and Click `Load sample Data`. Error: ```py…
Currently an error occurs when user tries to load scenario data for recruitment.
Steps to replicate:
- Install `hr_recruitment`.
- Open Recruitment and Click `Load sample Data`.
Error:
```py
ValueError: Invalid field 'user_id' in 'hr.applicant'
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo19/community/addons/hr_recruitment/data/scenarios/hr_recruitment_scenario.xml:72, somewhere inside
<record id='scenario_applicant_macm_helen' model='hr.applicant'>
<field name=email_from>helenlee@exampe.email.com</field>
<field name=partner_name>Helen Lee</field>...
```
Cause:
- The field `user_id` was changed to `recruiter_id` from the [PR].
- But the scenario data still had the field `user_id`, this caused the error.
Solution:
- Replace user_id in the sample data with recruiter_id and use an employee as a value instead of a user. One additional detail is that since this is sample data that can potentially be applied on a db that already has some records. There is a case where creating an employee in the sample file and linking them to the admin user, but that can cause an exception if the admin user is already linked to an employee. To circumvent this, we first check if there is an employee linked to the admin user. If not we create a new one and make the sample data use whichever employee that is linked to the admin user.
Backport for the PR: https://github.com/odoo/odoo/pull/246362
[PR]: https://github.com/odoo/odoo/pull/229665
sentry-7324422905
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where VIES validation errors caused system slowdowns and errors. By catching a wider range of exceptions from the VIES service, the system is now more robust and reliable when checking VAT numbers, preventing disruptions to key processes like OCR invoice updates. This improves overall system stability.
Original PR description
Catch all `zeep` exceptions instead of only `zeep.Fault`. On 14th of February 2026, the VIES service wasn't working properly, they were returning invalid XML in their response. This caused the `check_vies` call to raise a `zeep.XMLSyntaxError` which wasn't caught, causing a traceback every time VIES was used to validate a VAT number. opw-5938723 (OCR couldn't be refreshed on an invoice because it tried to create a partner from its VAT number and it couldn't be checked with VIES). Forward-Port-Of: odoo/odoo#251947 Forward-Port-Of: odoo/odoo#249853
This update fixes an error in how the system maps CPV codes for Romanian VAT invoices. Previously, the system incorrectly used 'CPV' instead of 'STI' for the ItemClassificationCode/listID, which is the correct code according to PEPPOL standards. This ensures accurate VAT 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 resolves an issue where the font size in the HTML editor toolbar would disappear when navigating within a document. The fix ensures that the editor's state, including font size settings, is preserved across toolbar redraws. This improves the user experience and prevents data loss during document editing.
Original PR description
Since [1], the font size in editor's toolbar is a `button` that contains an `iframe`. An `input` is put within this `iframe` so that when it is focused, the selection in the edited document is not lost. Unfortunately, when an `iframe` is moved in the DOM, it is restarted. In this case, the `iframe` has no source, so it becomes empty, and the content that was added into it `onMounted` is lost. This commit solves this by listening to every `load` events on the `iframe` instead of only the initial one. Steps to reproduce: - Go to a "To Do" note - Create a table with `/table` - Press Enter to confirm the 3x3 size - Select the last two cells of the first column - Move the mouse upwards to the next cell => The font size disappeared [1]: https://github.com/odoo/odoo/commit/a468de9d1099931d8f553c8569359996e7b694f2 task-6003539 Forward-Port-Of: odoo/odoo#252013
This update ensures that the country associated with a phone number (e.g., +1 or +32) always matches the currently selected country in the user interface. Previously, the system incorrectly used a fallback country, leading to inconsistencies. A new test has been added to verify this fix.
Original PR description
When parsing a keypad number, we were formatting the phone number with a fallback country (from the currently selected flag) but still resolving the returned country/flag from the pre-format parsing context (see [1]). This could lead to inconsistencies where the number is normalized as +1... while the UI country remains the previously selected one (e.g. Belgium). This commit recomputes country information from the formatted number before returning countryId/storeData, so the softphone flag matches the normalized phone number. Also adds a controller regression test covering this behavior. [1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294 task-5995387 Forward-Port-Of: odoo/enterprise#109365
This update resolves a technical issue related to XML files used for Swedish payment processing (pain.001.001.09). The fix ensures the correct XML format is used, aligning with industry standards and improving the reliability of payment transactions in Sweden. This change primarily impacts the handling of financial data.
Original PR description
In Sweden, pain.001.001.09 XML files should use `<BICFI>` node, not `<BIC>`. This commit fix an XML test file to use BICFI. runbot-241221 Forward-Port-Of: odoo/enterprise#109930
A warning message was appearing unexpectedly when adjusting the B1 field in French tax reports. This fix removes a redundant reference to 'box_B1' within the report's calculation logic, ensuring the system functions correctly without displaying the error. This improves the user experience for French accounting users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001 Forward-Port-Of: odoo/enterprise#110169
This update resolves an issue where the invoice button wasn't correctly triggering invoice creation for orders in the Indian localization. The fix ensures the 'to_invoice' field is properly set when the button is clicked and the order is validated, preventing invoices from being missed. This improves the order processing workflow.
Original PR description
For some unknown reason, with the indian localization, in some tests, when the invoice button was clicked and the order was validated right after, the to_invoice field was not set to true and no invoice was created. This led to problem cause when we click on the button we want it to be taken into account. This commit fix this by checking that the button is unchecked, then clicked and then check that the button changed state. runbot-error: 238505 Community PR: https://github.com/odoo/odoo/pull/253119
This update resolves an issue where the invoice button within the Point of Sale system was not being properly accounted for. The fix involves adding a test method to ensure the button's functionality is correctly recognized. This ensures accurate invoice generation from Point of Sale transactions.
Original PR description
This commit adds a method used in some tests. runbot-error: 238505 Enterprise PR: https://github.com/odoo/enterprise/pull/110171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
35 changes
Enhancements to existing features
This update simplifies the partner list by adding a direct 'unselect' button. Previously, users had to hover over a selected partner to remove it, which was confusing. This change makes it easier and more intuitive for users to manage their customer list.
Original PR description
Before this commit: ==== - Initially if partner is selected then hovering over partner shows option to remove the partner, until user won't be able to get how to remove the customer if selected. - Not good from user perspective. Following this commit: ==== - Unselect button will be shown everytime instead of hovering if partner is selected so that when user open the partner list, user can easily unselect the partner. task-5945904 Forward-Port-Of: odoo/odoo#249405
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 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 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 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 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 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 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 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 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 fixes an issue where users weren't reliably navigating to the correct knowledge article before performing actions like sharing or saving. The change ensures that users are always in the intended article, improving the overall user experience and preventing potential errors. This is a routine maintenance fix.
Original PR description
With this commit, We ensure we're in the correct article before making any changes (share, add to favorites, edit) using `waitUntil`. We've added a `checkArticle` function to ensure the article is in the correct place in the menu. runbot-error-id~234645
A recent update to the website's product image functionality caused a problem where videos couldn't be properly displayed. This fix resolves a technical error that prevented users from creating product images with video links, ensuring videos are now correctly shown. This improves the user experience for product browsing.
Original PR description
Since the view cleaning done in #230098, the `video_url` field infos were not automatically loaded by the JS ORM anymore. Therefore a traceback was raise when trying to create a new `product.image` record with a video_url field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue related to the formatting of marketing emails. The system now correctly ensures that email body fields are required based on the email content, improving email deliverability and data accuracy. Additionally, a minor adjustment was made to ensure tours complete properly.
Original PR description
Prior to this commit, `body_html` was hard-coded as a dependency of the `mass_mailing_html_field`, and that dependency lacked the `required` attribute, which should depend on the value of `body_arch`. The dependency is now added in the related views, and the field is now generic. As HtmlField now mark the record `dirty` `onChange`, some tours should ensure that the form view is properly discarded before finishing. task-5976348 Forward-Port-Of: odoo/enterprise#109091
This update corrects a bug where helpdesk users weren't seeing all their ratings in 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 intermittent test failures in the sign process by using dedicated, newly created test users instead of the default 'admin' and 'demo' accounts. This ensures consistent and reliable test results, improving the overall stability of the sign functionality.
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 missing 'Reset' button for specific Spanish informational reports (Mod 130, 347, 349, 390). The change was triggered by a recent configuration update, and this fix ensures users can properly clear and regenerate these reports when needed.
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#104739
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 can be updated successfully, regardless of previous quantity changes, improving the reliability of the POS system. This prevents order processing disruptions.
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 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
This update resolves a technical issue related to XML files used for Swedish payment processing (pain.001.001.09). The change ensures the correct XML format is used, improving compatibility with Swedish banking systems. This ensures accurate and reliable payment processing for our Swedish customers.
Original PR description
In Sweden, pain.001.001.09 XML files should use `<BICFI>` node, not `<BIC>`. This commit fix an XML test file to use BICFI. runbot-241221 Forward-Port-Of: odoo/enterprise#109930
A warning message was appearing during tax report adjustments in the French localization. This was caused by an unnecessary reference to 'box_B1' within the report's calculations. This fix removes the problematic reference, ensuring accurate report generation and eliminating the warning message for users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001 Forward-Port-Of: odoo/enterprise#110169
12 changes
Resolved issues and error corrections
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 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#250654This update resolves an issue where parallax preview animations appeared differently in Firefox and Chrome due to inconsistent iframe height calculations. The fix now uses the root document height, ensuring a stable and predictable animation across all browsers. This improves the user experience for website editors.
Original PR description
Steps to reproduce: - Open the website editor. - Open the snippet dialog. - Scroll through a parallax snippet preview in Firefox and Chrome. => The preview animation does not move the same way. Before this commit, the parallax preview used `body.clientHeight` inside the scaled snippet preview iframe. Firefox and Chrome can return different values there, so the preview animation was inconsistent. After this commit, the preview reads `document.documentElement.clientHeight` instead, which gives a stable iframe viewport height across browsers.
This update resolves an issue where quotation documents with zero subtotal lines were being discarded during upload. The fix ensures that all lines, including those with a zero subtotal, are correctly processed, preventing data loss and improving the accuracy of quotation generation. This change maintains compatibility with older Odoo versions (16.0+).
Original PR description
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document…
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document upload. Steps to reproduce: --- 1- In sale app, upload a quotation document without line amount. (You could use the one attached in the ticket) 2- As you see, lines are discarded. Cause: --- This regression is introduced in https://github.com/odoo/odoo/pull/245862, to prevent lines with zero amount in accounting. The https://github.com/odoo/odoo/pull/245862 targets 16.0. However, the `sale_edi_ubl` is introduced on 18.0. Fix: --- Instead of `_retrieve_line_vals` (`_import_fill_invoice_line_values` on 16.0) returning `None` when `price_subtotal` is not present, it can keep returning `dict` with an extra key `price_subtotal`, and filter out unwanted line in `_retrieve_invoice_line_vals` itself. opw-5977735 Forward-Port-Of: odoo/odoo#253149 Forward-Port-Of: odoo/odoo#251463
This update fixes a technical issue related to XML files used for Swedish payment processing (pain.001.001.09). The change ensures the correct XML structure is used, improving compatibility with Swedish banking systems. This ensures accurate and compliant payment processing for our Swedish customers.
Original PR description
In Sweden, pain.001.001.09 XML files should use `<BICFI>` node, not `<BIC>`. This commit fix an XML test file to use BICFI. runbot-241221 Forward-Port-Of: odoo/enterprise#109930
A warning message was appearing during tax report adjustments in the French localization. This was caused by an unnecessary reference to a field ('box_B1') within the report's calculations. This update removes the problematic reference, ensuring accurate reporting and eliminating the warning message for users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001 Forward-Port-Of: odoo/enterprise#110169
This update corrects a minor syntax error in the PWA service's CSS selector, which was preventing the application from correctly registering during installation. This fix ensures that the PWA installation process functions smoothly, resolving a potential issue that could have disrupted the user experience. The change is focused on version 18.3.
Original PR description
Description of the issue/feature this PR addresses:
Fixes a typo in the manifest selector used by the PWA service.
document.querySelector("link[rel=manifest") was missing the closing ], making the selector invalid.
Current behavior before PR:
Calling getManifest() could throw a DOMException due to an invalid CSS selector, preventing manifest retrieval and potentially breaking PWA install flow.
Desired behavior after PR is merged:
getManifest() correctly queries link[rel=manifest], retrieves the manifest URL, and keeps the existing manifest-fetch behavior intact (including test coverage already present in pwa_service.test.js).
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251376This update fixes an issue where temporary files used during report generation weren't always being properly deleted after tests. The change ensures these files are cleaned up immediately, preventing potential disk space issues. This improves the stability and efficiency of the Odoo reporting system.
Original PR description
Investigated after finding `/tmp/report.*` left over after running tests. #186547 left some temporal holes in the cleanup which are apparently sufficient to not correctly clean the files in some cases? Since `mkstemp` already creates the files, don't wait to have written stuff inside to record the file for deletion, do it immediately *then* write content to the file. An even better solution would be to use `NamedTemporaryFile(delete_on_close=False)`, however that's only available from 3.12, and it does not log deletion errors (although I'm not convinced that's useful in the first place). Forward-Port-Of: odoo/odoo#253053
This update resolves an issue where a regex used to process vendor bills could fail when encountering unexpected data types (specifically, False). The change ensures the regex only operates on valid string values, improving bill processing reliability and preventing errors during import.
Original PR description
The issue occurred because a test regex was applied to a non-string value. In some cases the value was False, which caused the operation to fail. Steps to reproduce: - Import a vendor bill - Remove the product and the label from one line, then post the bill - Import another bill (or the same bill)from the same supplier - An error occurs when the regex tries to match a non-string value This change ensures the regex is only applied to valid strings. It also improves the code by extracting the static part of the regex into a dedicated variable. opw-6019298 opw-6030364 opw-6033013 opw-6032608 opw-6032546 Forward-Port-Of: odoo/odoo#253576
This update fixes a problem where the HTML editor would lose its current selection when the editor regained focus after using the command palette. The change ensures the selection is preserved, improving the user experience when navigating the editor. This prevents frustration and allows users to continue editing seamlessly.
Original PR description
Before this commit: when the whole editable regains the focus, the selection in the editable is reset to the start of it. After this commit: We create a override for hotkey service to open the command palette with an onClose to refocus the editable area without losing the current selection. For the hotkey override, we pass the area option so it's only valid in the editable area. Outside the editable, the command palette is opened in the default way. task-5949705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250624
This update ensures Odoo complies with new NACHA regulations regarding payment descriptions. Starting March 2026, all payroll payments must include 'PAYROLL' in the Company Entry Description field to avoid potential payment issues. This change is a necessary update to maintain compliance and accurate financial reporting.
Original PR description
Starting March 20, 2026, NACHA requires the Company Entry Description field to contain "PAYROLL" for paying wages, salaries, or compensation [1]. [1] https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions task-5981941 Forward-Port-Of: odoo/enterprise#109460
8 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 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 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 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
This update fixes a technical issue related to XML files used for Swedish payment processing (pain.001.001.09). The change ensures the correct XML format is used, aligning with industry standards and improving the reliability of financial transactions in Sweden. This is a minor fix impacting the processing of these specific files.
Original PR description
In Sweden, pain.001.001.09 XML files should use `<BICFI>` node, not `<BIC>`. This commit fix an XML test file to use BICFI. runbot-241221 Forward-Port-Of: odoo/enterprise#109930
A warning message was appearing during tax report adjustments in the French localization. This fix removes a redundant reference to 'box_B1' from a calculation, ensuring the report functions correctly without the unexpected warning. This improves the user experience for French accounting users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001 Forward-Port-Of: odoo/enterprise#110169
6 changes
Enhancements to existing features
This update enhances the Odoo demo data by adding 'hr_responsible_id' values, replacing the default 'Oodobot' assignment. This provides a more realistic and useful demo environment for evaluating the planning module, aligning with best practices for demonstration data.
Original PR description
Changes: Added hr_responsible_id to the demo data as per the request since by default it's assigned to Oodobot it's better add real users to the demo data Com PR-244686 task-5602911
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 technical issue where the Odoo Enterprise system would crash or display warnings due to missing view IDs. It also adds a calendar icon to date-type fields in the sidebar, improving clarity and usability for users. This ensures a more stable and intuitive experience.
Original PR description
Before this commit, the component would crash or throw warnings when the optional view ID was missing. The sidebar list also lacked a clear visual indicator for date-type fields. After this commit, the view ID is correctly marked as optional to prevent those errors. We also map the calendar icon to date items so they're easier to identify. taskid-6018352
Code cleanup and technical improvements
This update simplifies website configuration by moving option definitions from JavaScript to XML files. This change improves maintainability and consistency across the website modules, aligning with a new development standard. The core logic for website options is now managed through XML, streamlining the process and reducing complexity.
Original PR description
*: ai_website_livechat, website_appointment, website_sale_renting This commit adapts website_* options to the XML-first DSL introduced in `html_builder`/`website`. Core changes: - Option placement and attributes (`selector`, `title`, `groups`, `editableOnly`, ...) are now declared in `website.BuilderOptions` XML extensions. - JS plugins no longer register options via `builder_options` using `withSequence`; they stay focused on actions and services. - Option classes kept for behavior are linked through `static id` and registered in `website-options` registry when needed. - Obsolete JS-only option wrappers/plugins are removed when XML-only declarations are sufficient. For more information and context, read the community commit message. task-5358660
This update prepares the website templates for OWL3, a new technology that requires a specific syntax (.this) to access components within templates. The changes add this. to template variables, ensuring compatibility with the upcoming OWL3 update and maintaining consistent component referencing across various website modules.
Original PR description
In preparation for OWL3, where template variables will need to use .this to target component variables, we add this. to template variables that are targetting the component. Script PR: odoo#247965 https://github.com/odoo/odoo/pull/253364
3 changes
Resolved issues and error corrections
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 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
This update clarifies error messages related to Instagram integration (code 9004) within Odoo Enterprise. It provides users with more detailed guidance to troubleshoot common issues, reducing the need to contact support. This improves the user experience and streamlines problem resolution.
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 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 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 resolves a technical issue where the menu toggle's SVG icon was not displaying correctly in some browsers. The fix ensures the arrow tip is rounded, preventing it from appearing truncated and improving the overall visual appearance of the application. This ensures a consistent and professional user experience.
Original PR description
Before this commit, some browsers showed a warning or, even worse, dropped this CSS rule because the unit was missing. This line ensures that the tip of the arrow is rounded instead of truncated. 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
This update resolves an issue where a regex used during vendor bill processing would fail when encountering unexpected data types (specifically, False). The fix ensures the regex only operates on valid string values, improving the reliability of bill import and preventing errors. This change enhances the stability of the account management process.
Original PR description
The issue occurred because a test regex was applied to a non-string value. In some cases the value was False, which caused the operation to fail. Steps to reproduce: - Import a vendor bill - Remove the product and the label from one line, then post the bill - Import another bill (or the same bill)from the same supplier - An error occurs when the regex tries to match a non-string value This change ensures the regex is only applied to valid strings. It also improves the code by extracting the static part of the regex into a dedicated variable. opw-6019298 opw-6030364 opw-6033013 opw-6032608 opw-6032546 Forward-Port-Of: odoo/odoo#253576
5 changes
Resolved issues and error corrections
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 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
Documentation and clarification updates
This pull request updates our company's CLA (Contributor License Agreement) to reflect the most current employee list. Previously, the CLA contained outdated information. After this change, the CLA will accurately represent our company's legal commitments to the Odoo project.
Original PR description
Description of the issue/feature this PR addresses: It makes our company CLA up to date with the reality Current behavior before PR: Our company CLA had some old employees in it, and didn't have some new ones Desired behavior after PR is merged: Our company CLA is up to date. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr