Friday, March 13, 2026
63 changes · saas-19.1
New functionality added to Odoo
This update adds support for obtaining currency rates directly from the National Bank of Georgia (NBG). This is required to comply with Georgian tax regulations, ensuring all transactions are accurately translated into the local currency (GEL) using official exchange rates.
Original PR description
This commit adds the National Bank of Georgia (NBG) as a supported service provider for automatic currency rate updates. Purpose: To comply with the Georgian Tax Code (Article 73), taxable transactions must be translated into the national currency (GEL) using the official exchange rate defined by the NBG for the transaction day. Functionality: -Enables fetching official exchange rates directly from NBG. -Automatically handles rates defined for different quantities (e.g, rates quoted per 100 units instead of 1 unit). task-5894623 Forward-Port-Of: odoo/enterprise#107375
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
Miscellaneous changes
This update enhances the statement line dropdown by adding colored bubbles to highlight matching move lines with the same amount and currency. This provides users with quicker visual cues for related transactions, streamlining reconciliation processes. The feature also includes an optional display setting for increased flexibility.
Original PR description
This will add a new colored bubble on the dropdown of a statement line when there is a move line that has the same amount currency or amount. task-5493859 Forward-Port-Of: odoo/enterprise#104896
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
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 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 and DOM movements. 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 corrects a previous issue where quotation documents with lines having a zero subtotal amount were being discarded during upload. The fix ensures that all lines, including those with zero subtotal, are now correctly processed, maintaining accurate quotation data. This resolves a compatibility problem introduced in a recent update.
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 ensures that session rotation is correctly disabled when a WebSocket connection closes, specifically on the `/websocket/on_closed` route. Previously, this route wasn't accounted for, potentially leading to session issues. This change enhances stability and reliability of the Odoo WebSocket functionality.
Original PR description
In [1], session rotation was disabled for websocket routes. However, the `/websocket/on_closed` route was forgotten. This commit ensures session rotation is also disabled for this route. [1]: https://github.com/odoo/odoo/pull/250826 opw-5445323 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#253615
A recent test was failing because the system wasn't loading all necessary partner data due to a limit on the number of users loaded. This fix increases the loading limit to guarantee the correct partner information is available, preventing reporting issues. This ensures accurate data display in key reports.
Original PR description
In the test, test_pos_settle_due_with_rounding, the partner that we want to check was sometimes not loaded in the frontend due to the default limit of 100 users loaded. Those users are loaded by priority of number of orders and then name. In the test, no order has been made before so we only check the alphabetical order of the names and the partner we want to check is not always in the first 100. In the fix, we change the limits to a very big number to be sure that the partner is loaded. runbot-error: 241039
This update resolves a technical issue related to the format of XML files used for processing payments in Sweden. Specifically, a test file was updated to correctly utilize the `<BICFI>` node, ensuring compliance with Swedish banking standards. This ensures accurate payment processing and avoids potential disruptions.
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 issue stemmed from an outdated reference within the report's calculations. This fix removes the problematic reference, ensuring accurate reporting and eliminating the warning message for French 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 fixes an issue where selecting an office on the Jobs page would remove the previously applied country filter. The fix ensures that country filters remain active and accurate when users select offices, improving the user experience for job searches. This change was made to ensure consistent and reliable filtering functionality.
Original PR description
Steps to reproduce: =================== 1. Navigate to the Jobs page. 2. Filter a specific country 3. Select all offices -> The country filter will be removed Cause: ====== the "All Offices" link inside job_filter_by_offices, the href uses 'all_countries=1' if is_remote else current_country_path but current_country_path is not defined anywhere Solution: ========= Switch to current_country_param Note: ===== The fix will be adapted in later versions opw-5947819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252909 Forward-Port-Of: odoo/odoo#252477
This update resolves a visual bug where icons within the HTML editor weren't correctly styled with padding. The fix ensures icons are consistently formatted upon page load, improving the editor's appearance and functionality. This was caused by a timing issue in how the editor processed elements.
Original PR description
Problem: When content is added to the editor, icons are not surrounded by `feff`s. Cause: The selector used to pad elements with `feff`s relies on `o-paragraph`, which is added during normalization. However, `BaseContainerPlugin.normalize_handlers` runs last, so when `FeffPlugin.normalize_handlers` executes, it cannot find icons through `selectors_for_feff_providers` because the expected paragraph-related parent is not yet in place. Solution: Execute `FeffPlugin.normalize_handlers` immediately after `BaseContainerPlugin.normalize_handlers`, ensuring the DOM structure is ready before attempting to add surrounding `feff`s. Steps to reproduce: - Add an icon. - Reload the page. - Do not make any changes (so normalization is not triggered again). - Inspect the icon and observe that it does not have surrounding `feff`s. task-5960097 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250855
A small technical issue preventing the PWA (Progressive Web App) from correctly installing Odoo was resolved. The fix corrected a syntax error in the PWA's CSS selector, which was causing installation problems. This ensures a smoother and more reliable PWA installation experience for users.
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 resolves an issue where users without HR officer permissions would encounter an error when trying to open the user form. The change removes unnecessary PIN information from the main user view, streamlining access for authorized personnel while retaining the data in employee records and preferences.
Original PR description
If a person having rights to edit users is not HR officer, he gets a traceback when he tries to open the user form. As the information of PIN is not really related to the user, we left it on the employee and the "Preference" view, but remove it from the main user view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where archived employee versions were incorrectly appearing in pay run reports. The fix ensures that only active employees are included in pay run calculations, preventing inaccurate payroll processing. This improves data accuracy and reliability.
Original PR description
Steps to reproduce: 1. Create an employee with a contract for this month 2. Archive the employee (but not the version) 3. Create a pay run 4. The employee's version will appear in the list Cause: The domain takes versions for archived employees. Fix: Add active_employee in the domain. Task: 6022437 Forward-Port-Of: odoo/enterprise#110204 Forward-Port-Of: odoo/enterprise#110073
This update prevents an infinite loop in the system's credit note processing. Previously, credit notes were incorrectly polled, causing delays. The fix restricts the polling process to only invoices, ensuring efficient claim status updates.
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 Forward-Port-Of: odoo/enterprise#109995
When a bill import fails, Odoo now displays a clearer message in the chat indicating an error occurred and attaching the original XML file. This prevents confusion for users who might otherwise be unsure why an empty bill was created.
Original PR description
When a bill import (including Peppol) fails, an empty bill is created with the XML attached in the chatter, which can be confusing for users. This commit adds a clearer chatter message indicating that an error occurred and that the incoming XML is attached. task-5932172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250586
This update fixes a problem where temporary files used during report generation weren't being properly deleted after tests, leading to potential clutter. The change uses a safer method for creating temporary files, ensuring they are always cleaned up, minimizing storage usage and improving system stability. This resolves a minor technical issue with no direct impact on users.
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? Swap with `NamedTemporaryFile(delete_on_close=False)`. Forward-Port-Of: odoo/odoo#253053
This update resolves an issue where users without write access to product templates couldn't print labels. The fix adjusts how access rights are checked, now permitting label printing for users with read-only permissions. This ensures all users can utilize the product label printing functionality.
Original PR description
## Issue Users who do not have the "write" right access on `product.template` cannot print product labels. ## Steps to reproduce 1. Install *Sales* (`sale_management`) 2. In Settings > User &…
## Issue Users who do not have the "write" right access on `product.template` cannot print product labels. ## Steps to reproduce 1. Install *Sales* (`sale_management`) 2. In Settings > User & Companies > Users, make sure Marc Demo does not have any write access on `product.template` 3. Log in as Marc Demo 4. In Sales > Products > Products, open a product and click *Print Labels* from the cogwheel menu 5. **An Access Error is shown, saying that the operation is allowed for the `Products/Create` group.** ## Cause [This commit](https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e) removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling `_can_execute_action_on_records`: https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239 When a `group_ids` field is added to the action, this check is no longer performed. opw-5914988 Forward-Port-Of: odoo/odoo#248672
A bug was preventing users from successfully deleting files within the HTML editor. This update corrects a technical issue related to how the HTML editor's removal functionality interacts with editable elements. The fix ensures that files can now be properly removed using the backspace key.
Original PR description
Steps to reproduce: =================== 1- Go to website & add a file using /file or /upload file 2- Click on the file box and press backspace -> Nothing happens. Cause: ====== After this commit [1], `is_node_editable_predicates` was added to prevent color from being applied to the file box so when removing the file box, The delete plugin's removeNode checks `isNodeEditable(node)` which returns false for the file box and thus prevents it from being removed. Solution: ========= a non-editable node that sits inside an editable parent should still be removable so now : node is not removable if !isNodeEditable(node) & its parent is also not contentEditable [1]: https://github.com/odoo/odoo/pull/226927/changes/7f4eedd76c833f3a162070563f3982a1fbdb77c7 opw-5995236 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252764
This update fixes an issue where `equity_unaffected` accounts were incorrectly using 'historical' currency rates. By reordering the CASE statement, the system now accurately applies the correct rate conversion, ensuring more precise reporting of equity values. This improves the reliability of financial reports.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update addresses an issue where the Odoo upgrade process was unintentionally growing a database mapping, leading to potential performance problems. The fix ensures custom models are correctly handled during upgrades, preventing unnecessary data duplication and improving overall system stability. This change focuses on internal system improvements.
Original PR description
During upgrades we observed an uncontrolled growth of the mappings `field_depends` and `field_depends_context` in the registry. The Field instances that serve as keys are duplicated for custom models. This comes from the fact that custom models are completely reloaded during registry setup, even incremental setup. To avoid duplication we consider custom models to be re-setup, which they actually are.
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Xavier Dollé (xdo) <xdo@odoo.com>
Forward-Port-Of: odoo/odoo#253377This update fixes a bug in how the system calculates scrap quantities. Previously, if a product lacked a related BOM, the calculation would stop prematurely, leading to inaccurate scrap amounts. Now, all products in a recordset are correctly processed, ensuring accurate scrap quantity reporting.
Original PR description
### Description of the issue/feature this PR addresses: The `_compute_scrap_qty` method in **mrp/models/stock_scrap.py** exits early with return when a record has no BOM, preventing the computation of `scrap_qty` for remaining records in the recordset. ### Current behavior before PR: When iterating over a multi-record recordset, if any record lacks a `bom_id`, the method does return `super(...)._compute_scrap_qty()`, which exits the entire loop. Records after that one are never computed and keep the default value of 1. ### Desired behavior after PR is merged: Records without a `bom_id` delegate to `super()._compute_scrap_qty()` and the loop continues (continue) to the next record, ensuring all records in the recordset are properly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253368 Forward-Port-Of: odoo/odoo#252149
This update resolves an issue where users without HR access were blocked from accessing PoS settings when an incorrect employee was automatically assigned. The fix ensures that only employees from the same company as the PoS configuration are used, preventing access errors and improving usability.
Original PR description
When writing to a PoS config, it will automatically set an `advanced_employee_ids` if none is set. But it will take any employee that is part of `point_of_sale.group_pos_manager`. If the employee…
When writing to a PoS config, it will automatically set an `advanced_employee_ids` if none is set. But it will take any employee that is part of `point_of_sale.group_pos_manager`. If the employee selected is not part of the same company as the PoS config, and the current user doesn't have HR employee access it will trigger an ir.rule that block the user from opening the settings. Steps to reproduce: ------------------- * Create a new company * Create a new user that only have access to this company and no HR access * Create a PoS in the new company * Login as the new user * Try to open the settings > Observation: You will get an access error because the employee set in `advanced_employee_ids` is from the other company Why the fix: ------------ We make sure that when automatically setting the advanced_employee_ids we filter out the ones that are not from the correct company. If no employee exist that satisfies the requirements, we take a user from the `group_pos_manager` and create an employee for him. opw-5885417 Forward-Port-Of: odoo/odoo#252402
This update corrects a bug that prevented the creation of 'Cash Supplement' cash moves in German POS systems. The original system incorrectly capitalized the type, causing an error with the Fiskaly accounting software. Now, the correct casing is maintained, ensuring proper cash move processing.
Original PR description
When creating a cash move of type "Cash Supplement", the type sent was "Zuschussecht" instead of "ZuschussEcht", which caused is not an allowed type. Steps to reproduce: ------------------- * Setup a PoS with a TSS for a German localization * Start a session and open the cash control popup * Create a cash move of type "Cash Supplement" * Close the session > Observation: You get an error from Fiskaly that the type is not allowed Why the fix: ------------ When doing `.capitalize()` on a string it would make the first letter uppercase and the rest lowercase. In this case "ZuschussEcht" would become "Zuschussecht", which is not the correct type expected by Fiskaly We now keep the original casing for all the type. opw-5462364 Forward-Port-Of: odoo/enterprise#109235
This update simplifies how users manage icons within accordions. Previously, users could switch icons by clicking, which wasn't an efficient editing method. This change removes the inline icon editing option, streamlining the process and improving usability.
Original PR description
In the accordion snippet option, the user can set the icons as custom to choose them. He can do so in the sidebar with the options "Active / Inactive Icons", or by double clicking on them. Since clicking on the icon open / close the accordion item, switching from one icon to the other, it is not a practical way to edit them that way. It was decided to remove the possibility to edit the icon inline. task-5885917 Forward-Port-Of: odoo/odoo#246937
This update fixes an issue where loyalty discounts weren't applied to sales orders using foreign currencies when the order total was below a certain threshold. The change ensures that the correct currency is used to calculate discountable amounts, resolving a bug that prevented discounts from being applied in these scenarios. This improves the accuracy of loyalty program rewards.
Original PR description
When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied Steps to reproduce: 1.…
When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied Steps to reproduce: 1. Install Sales app and l10n_cl and loyalty module 2. Switch to CL Company 3. Go to Sales > Products > Discount & Loyalty 4. Create a new program and change the rule's minimum purchase to 0.00 5. Go to Sales and create a new quotation for customer Acme Corporation and add any product 6. Change the sale order line unit price to 0.4 and click on Reward 7. No discount is applied Problem: The company currency is used to compute the discountable amount but when this currency rounds on unit, any amount that is less than 0.5 will be considered as zero so no discount will be applied. This is because the `compute_all` method is called without specifying the currency, so we fallback on the company currency. Solution: Pass the order currency when computing the discountable amount opw-5946975 Forward-Port-Of: odoo/odoo#252756 Forward-Port-Of: odoo/odoo#250153
Copying translations from 19.0, only direct module matches. I.e. Missing translations were not filled in + moved terms were not matched across modules (i.e. no translation context to ensure correctness) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Copying translations from 19.0, only direct module matches. I.e. Missing translations were not filled in + moved terms were not matched across modules (i.e. no translation context to ensure correctness) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Copying translations from 19.0, only direct module matches. I.e. Missing translations were not filled in + moved terms were not matched across modules (i.e. no translation context to ensure correctness)
Original PR description
Copying translations from 19.0, only direct module matches. I.e. Missing translations were not filled in + moved terms were not matched across modules (i.e. no translation context to ensure correctness)