Daily updates from Odoo
Navigate
Branch
Wednesday, August 13, 2025
65 changes
28 changes
Enhancements to existing features
Brazilian AvaTax NCM code records now require both a code and a clear name, reducing duplicate or confusing entries. Dropdown searches and displays are cleaner, and the form layout has been refreshed for easier maintenance.
Original PR description
This model was readonly without any views when it was originally created [1]. We forgot to add the correct constraints, and we duplicated the code inside the name field to avoid overwriting display_name and having to add a _rec_name_search. This commit fixes those issues. First of all, we require both the code and name field. Second of all, we remove the code from the name field and modify display_name and _rec_name_search accordingly. To not have identical display names in a dropdown, we also add a unique constraint on the combination of name and code. It's possible to have multiple identical NCM codes with different EX values, but in those cases the user should give them unique names. We also take the opportunity to put the NCM form view in a sheet, looks a bit more modern that way. [1] https://github.com/odoo/enterprise/pull/43797 task-4998498
The website’s button for moving from the public site to the backend now points to the updated /odoo address instead of the old /web address. This helps users land in the correct backend area and keeps navigation aligned with the current Odoo URL structure.
Original PR description
This commit changes the backend href from /web to /odoo, on the frontend to backend button.
The spreadsheet selection dialog has been redesigned to make labels, fields, and actions clearer for users. Button wording now better reflects the available choices, helping users insert or discard spreadsheet content with more confidence.
Original PR description
## Description
- Restyled the spreadsheet selector dialog for better visibility and clarity.
- Updated title, labels and input style for improved user experience.
Before this PR:
- Labels and fields styling made them less noticeable.
- Action buttons were generically labeled ("Confirm" / "Cancel").
After this PR:
- Labels and input fields are visually prominent and consistently styled.
- Button labels are now action-driven ("Insert" / "Discard").
Task: [4953592](https://www.odoo.com/odoo/project/2328/tasks/4953592)New salary contract offers are now consistently created with an associated employee or applicant. This helps HR teams keep offers properly connected to the right person, reducing confusion and improving record accuracy.
The WhatsApp test tools now automatically clear prior message bus activity before checking new notifications. This reduces flaky or confusing test failures and makes future maintenance safer, without changing customer-facing behavior.
Original PR description
With this change, the `assertBus` context manager is now responsible for resetting the bus state before executing its code block. Previously, `_reset_bus ()` had to be called manually before assertBus in order to explicitly check the bus notification for the targeted test process. This was repetitive and error prone, as forgetting to reset could cause notifications from previous actions to leak into the current assertion, leading to confusing test failures. [Community PR](https://github.com/odoo/odoo/pull/222753)
Breadcrumbs in the Cohort view now restore from the user's recent session state instead of relying only on the page URL. This helps users return to the same navigation path after refreshing the browser, avoiding confusing or extra breadcrumb steps.
Original PR description
Since [1] when reloading the browser the breadcrumb is restored based on the URL. This was implemented in a very naive way. For each action found in the URL, a multiview was added to the breadcrumb.…
Since [1] when reloading the browser the breadcrumb is restored based on the URL. This was implemented in a very naive way. For each action found in the URL, a multiview was added to the breadcrumb. Similarly, for each pain action/ID found in the URL, a form view was added to the breadcrumb. Note that the active_id (found before the action in the URL), is taken into account in the context of the action. For example, if the URL is : `/odoo/project/5/tasks`: - for the `project` action, the list of projects will be added to the breadcrumb; - for the `project/5` action/ID pair, the form view of the project 5 will be added; - for the `5/tasks` action (with active_id 5), the list of tasks for the project 5 will be added. However, this naive implementation does not consider that the user can navigate directly from the list of projects to the list of tasks for a project without passing through the project form view. This commit saves the current state in the session storage, to be used to restore the breadcrumb when the page is reloaded. Note that similar behaviour was implemented to improve action restoration [2]. [1] https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f [2] https://github.com/odoo/odoo/commit/e8afebdcbf5d725091983fbe3b425fec4aa3a071 task-id 5011505
Shop floor users can now adjust how many manufacturing orders appear at once, restore filtering to the current station, and load all available order cards when needed. This makes it easier for production teams to manage busy work centers with large order volumes.
Original PR description
Three small commits making the handling of large amounts of MOs easier in the shop floor: 1. Add a setting to customize the card limit (currently locked at 40) 2. Add back this station filter 3. Add button to load all cards task-4822881
Automatic transfers in accounting have been redesigned to make them easier and more useful for businesses. The update refreshes the user experience and improves how amounts are redirected from original accounting entries, helping teams automate transfer processes more effectively.
Original PR description
Description of the issue this commit addresses: The automatic transfers have been the way they are for a long time now and are barely used compared to how they could be. A little revamp could give them a bigger impact and use. --- Desired behavior after this commit is merged: The automatic transfers have a renewed UI and use different systems to redirect the amounts of the original moves. --- upgrade PR: https://github.com/odoo/upgrade/pull/7887 task-4813376
Bank reconciliation matching rules now handle negative amount ranges more intuitively. Users can enter the lower and higher amounts in either order, reducing confusion and helping rules match transactions as expected.
Original PR description
Before this commit, when having the match amount in between with negative amount we had the min and max amount. Some user were confused that since the amount are negative the min and max need to be inverted. To solve that we rewrite the way the match amount were dealt to use a case when that will enable to have an in between that works in both ways (min, max and max, min) notask-id Forward-Port-Of: odoo/enterprise#91744 Forward-Port-Of: odoo/enterprise#91628
The live chat information panel is easier for support teams to use, with clearer recent page views, better layout, and links opening in a new tab. It also improves readability in dark mode and accessibility for helpdesk tickets, helping agents work more efficiently and inclusively.
Original PR description
1. Add website name to recent page views. 2. Improve chatbot answers display in dark mode. 3. Update recent conversations button alignment. 4. Do not display recent conversations when the chat is closed. 5. Move notes section next to the status section. 6. Open links in the info panel in a new tab. 7. Helpdesk tickets accessibility improvements. https://github.com/odoo/odoo/pull/219053 task-4929870 Forward-Port-Of: odoo/enterprise#90350
Brazilian point-of-sale users can now download NFC-e XML files for multiple orders at once from the orders list. This saves time and reduces repetitive manual work when collecting electronic invoice files for reporting or administration.
Original PR description
- Before PR: No available action to download NFC-e XML files in batch. User has to download each xml file one by one. - After PR: An action to download multiple NFC-e XMLs for multiple orders is added in the action menu of POS orders list view. - Task Id: 4934938
Resolved issues and error corrections
Subscriptions that were paused and manually invoiced now resume with the correct next billing date. This prevents businesses from skipping billing periods or invoicing against dates that were already handled manually.
Original PR description
Version: - saas-18.4 Before: - If a subscription was paused and a manual invoice was created, resuming the subscription would set the next invoice date incorrectly. - It would often pick a date that…
Version: - saas-18.4 Before: - If a subscription was paused and a manual invoice was created, resuming the subscription would set the next invoice date incorrectly. - It would often pick a date that had already been invoiced manually, skipping over the pause period. - This happened because the user_pause_start is not reset after posting the manual invoice. After: - Now, when a manual invoice is posted during a pause, the pause state is cleared right away. - This makes sure the next_invoice_date is calculated properly when the subscription is resumed, without missing the pause period. Impact: - Fixes issues where subscriptions skipped billing periods after a manual invoice during a pause. - Keeps the billing period accurate when pausing and resuming subscriptions. Steps to reproduce: - Create and confirm a subscription. - Pause the subscription. - Post a manual invoice. - Resume the subscription. task-4946268 Forward-Port-Of: odoo/enterprise#90395
Rental orders now create and publish planning shifts more reliably, including creating one shift per unit when products are ordered by unit. The update also prevents staff from adding shifts to rental order lines that are already fully planned, helping avoid overbooking and planning errors.
Original PR description
## [FIX] sale_renting_planning: make sure shift generated by RO is published ## [FIX] sale_renting_planning: generate shifts when confirming rental order based on uom Before this commit, when the…
## [FIX] sale_renting_planning: make sure shift generated by RO is published ## [FIX] sale_renting_planning: generate shifts when confirming rental order based on uom Before this commit, when the user creates room product to generate shifts when a rental order is confirmed with that product, we expect to generate one shift per quantity ordered if the UoM is Unit instead of Hours/Days. This commit improves the shifts generation to take into account the UoM set on the SOL linked to rental order confirmed. That is, if the UoM set is Unit then one slot per unit ordered of the product will be generated. Otherwise, one shift will be generated for the SOL as it is currently the case. ## [FIX] sale_renting_planning: make sure to not overload the rental service Before this commit, when the user creates a new shift and clicks on `Add to Last Order` the shift will be added to the SOL contained one of products linked to the role set on the shift. The problem is we don't check if there is still something to plan for that SOL. This commit makes sure the SOL to set to the shift has something to plan to be sure it is not overloaded. task-4916537 Forward-Port-Of: odoo/enterprise#91327
This fix prevents the French FEC import from overwriting account names when multiple accounts share similar codes but have different labels. It helps preserve accounting data accuracy during imports and avoids manual corrections after importing files.
Original PR description
Steps to reproduce: - import a fec with different account 164*** with different names Issue: All the account's name will be overriden Cause: Before 18.0, apparently, code and name were joined and was not an issue solution: update the code to the new logic by filtering out the name from the override (`_apply_template`) opw-4690284 Forward-Port-Of: odoo/enterprise#92149 Forward-Port-Of: odoo/enterprise#86809
The POS Belgian blackbox module now keeps existing employee clock-ins when another employee clocks in from a different device. This prevents accidental clock-outs during device synchronisation, helping stores track staff attendance accurately.
Original PR description
- Fixes an issue where clocking in a second employee on a different device would automatically clock out the first one. This was due to `self` being unset during POS session leading to incorrect loading of `users_clocked_ids` and `employees_clocked_ids`. - The issue was appearing when `pos_session._post_read_pos_data` is triggered from `pos_config.notify_synchronisation`. task-id: 4902090 Forward-Port-Of: odoo/enterprise#89273
Fixed a layout issue in accounting reports where control panel filters could appear pushed to the right. The change keeps the settings button visible while allowing the filters to remain properly centered, improving usability and visual consistency.
Original PR description
Issues: - The control panel filters were appearing right-sided instead of being properly centered. This issue arose from a previous fix that added `flex-basis: min-content` to the breadcrumbs to ensure cog button visibility, but this caused the breadcrumbs to take excessive space and push filters to the right. Fix Applied: - Replaced `flex-basis: min-content` with `min-width: fit-content` on the breadcrumbs container. This maintains cog button visibility while allowing the breadcrumbs to use only the space they actually need, enabling the filters to center naturally in the remaining space. Task-4985129
This fix makes an automated barcode inventory test wait for the destination location update to appear before continuing. It reduces random test failures, helping keep stock barcode workflows stable during development and releases.
Original PR description
A non-deterministic error has been occurring across all versions starting from 18.0 when running the `test_split_line_on_destination_scan`. problem: The issue lies in one of the steps of the tour,…
A non-deterministic error has been occurring across all versions starting from 18.0 when running the
`test_split_line_on_destination_scan`.
problem:
The issue lies in one of the steps of the tour, where the destination location of the remaining quantity is changed from WH/Stock to shelf1 (LOC-01-01-00). Right after this change, the test proceeds to assertLineDestinationLocation. However, the test step was previously waiting for the presence of the .o_validate_page.btn-primary element — an element that is already visible before the destination location update is actually applied. As a result, the tour sometimes skips to the next step prematurely, without ensuring the location change has occurred, leading to test failure.
Fix:
We replaced the trigger .o_validate_page.btn-primary with a more reliable condition: waiting for an element containing the destination text .../Section 1 (.o_line_destination_location:contains(".../Section 1")). This ensures that the step only proceeds once the destination update has been reflected in the UI.
Runbot-145458
Forward-Port-Of: odoo/enterprise#92130
Forward-Port-Of: odoo/enterprise#91927The Argentina electronic invoicing test setup now stops retrying after a small number of failed connection attempts instead of looping indefinitely. This reduces unnecessary external connection attempts and makes test failures clearer and faster to identify.
Original PR description
In 18.0 and above test hasn't worked in months, half the time it fails because pretty much nothing works in it and half the time it's because it keeps looping on trying to set up the connection and failing (possibly because we're getting blacklisted due to how much spamming we do). For now restrict to just trying 5 times (per class since it's called from a `setUpClass`) with an exponential backoff. This may yet end up in removing the entire test directory as it doesn't seem like anyone cares. Forward-Port-Of: odoo/enterprise#92226 Forward-Port-Of: odoo/enterprise#92207
Batch transfer route planning now opens the intended map view, restoring the ability to rearrange pickings from that screen. This helps logistics teams organize deliveries correctly without being sent to a map view that does not support the needed ordering.
Original PR description
Commit ade5e5085df2 move the `default_order` value as it was defined in the wrong module. Consequence is the map view defined in `stock_enterprise` cannot be reordered anymore. This is an issue as the one in `stock_fleet_enterprise` is never used. The action window is patched to take a picking map view but without specifying witch one. This commit force the map view defined in `stock_fleet_enterprise` to be used in the action of `stock_fleet_enterprise`. Consequence is that the picking can be rearranged again in the map view coming from a batch transfer and not coming from the picking list. Forward-Port-Of: odoo/enterprise#91999
This change makes the automated accounting reports tour more reliable by using more precise steps during testing. It helps reduce false test failures, supporting smoother maintenance and more dependable release checks.
Original PR description
In this commit, we fix tour by using less generic triggers.
The portal now shows total hours based only on validated timesheets when that invoicing policy is selected. This prevents customers from seeing inflated hours that include unvalidated work, keeping task totals consistent with the timesheet lines displayed.
Original PR description
### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines…
### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines shown is the validated ones only but the Hours spent includes the non-validated ones too ### Current behavior before PR: The total hours spent for timesheets in portal view when setting the invoicing policy to 'Validate Timesheets Only' is calculated wrongly as it takes the non validated ones into account. This is happening as when passing the values to the view we pass 'task_sudo' variable which will have the SUPERUSER as the env.user https://github.com/odoo/odoo/blob/saas-17.2/addons/project/controllers/portal.py#L569 so it won't pass the condition if the user is portal or not https://github.com/odoo/enterprise/blob/saas-17.2/sale_timesheet_enterprise/models/project_task.py#L33:L35 and it will calculate all the timesheet without taking validation into condisderation. ### Desired behavior after PR is merged: As we are using those computed fields only in portal views so we don't have to check if the user is portal user as even if an internal user is showing the same view for testing he should be able to see the same data as the portal user. opw-4193842 Forward-Port-Of: odoo/enterprise#70557
The Documents app button is now shown to internal users who can already access shared documents through other entry points. This makes access easier and clarifies that a full Documents User role is not required for documents shared with all internal users.
Original PR description
The app is accessible to all internal users via smart buttons and their portal already, showing the button is helpful in two ways: 1/ Easier access to the app, duh. 2/ Makes it explicit that you don't need to be a "Documents User" to have access to documents shared with all **internal users**, even those that are not documents user (that didn't have the app button available). In 18.0 so that new installations have it. Task-4889053 Forward-Port-Of: odoo/enterprise#92124 Forward-Port-Of: odoo/enterprise#90937
A stock barcode test now sets an email address for the admin user so quantity update notifications can be sent as expected. This helps ensure warehouse notification behavior is properly validated even when demo data is not available.
Original PR description
Updating the initial demand of a stock move notify the users. Without email address, the notification cannot be send. As the email address of the admin user is only fill in the demo data, this commit adds one specially for the test. runbot: 226778 Forward-Port-Of: odoo/enterprise#91103 Forward-Port-Of: odoo/enterprise#89722
The Cash Flow report now handles grouping by account codes consistently, preventing an error that could stop the report from loading in some configurations. This helps finance users access cash flow information reliably when account code fields are customized or present.
Original PR description
The term used by GROUP BY should be the same term in the SELECT, avoiding the posible error like: ERROR: column "account_move_line__account_id.code_store" must appear in the GROUP BY clause or be used in an aggregate function That appears when a column named account_code is created for the model account_move_line. opw-4963180 Forward-Port-Of: odoo/enterprise#91915
This fix ensures subscription effective dates set during order processing are properly written to the database. It prevents cases where the date could appear saved internally but be missing later, improving reliability for subscription records.
Original PR description
Since https://github.com/odoo/enterprise/commit/ff8e55ed83d4905584b7ea10b60ded0d7afbd0cf setting the effective date is done in a precommit hook. Problem, the precommit don't automatically flush. The value set in the cache may be never reflected in the database. Solution: Explicitly flush in the precommit hook Forward-Port-Of: odoo/enterprise#92283
Point of Sale orders in the Mexican e-invoicing flow now round totals using the currency's own precision. This prevents valid discounted orders from being blocked by small rounding differences during validation.
Original PR description
Issue: With specific prices and discounts, we can get an rounding issue that does not pass the Validation Error. Purpose of this PR: To round the amount total based on the currency's rounding precision to pass the check. Steps to Reproduce on Runbot: install pos, l10n_mx create products prices with 75.00 and 60.00 respectively. create discount 100% on order change decimal accuracy to 3, change tax to Include with Price create PoS order with products and apply discount receive ValidationError even though the amount total should be rounded to 0.0. opw-4944830 Forward-Port-Of: odoo/enterprise#92141
Features or functions removed from Odoo
Unused code was removed from Point of Sale and several related add-ons. This cleanup reduces maintenance overhead and helps keep the POS codebase lean without changing business-facing functionality.
Original PR description
- Remove dead code in POS and submodueles (`l10n_it_pos`, `pos_iot`, `pos_restaurant_appointment`, `pos_self_order_iot`, `pos_settle_due`, `pos_urban_piper`). task-id: 5006039 community PR: https://github.com/odoo/odoo/pull/222587
Code cleanup and technical improvements
This update renames an internal AI VoIP view identifier and label to match Odoo's coding guidelines. It does not change user-facing functionality, but helps keep the codebase consistent and easier to maintain.
Original PR description
Renamed view id and name according to the coding_guidelines: https://www.odoo.com/documentation/18.0/contributing/development/coding_guidelines.html#inheriting-xml
37 changes
Security fixes and vulnerability patches
Website search now respects page visibility rules and access permissions, so visitors do not see restricted pages in search or autocomplete results. It also improves filtering for empty searches and excludes pages that should not be indexed.
Original PR description
Searching for pages on a website requires sudo. Because of this the ACL and visibility criteria checks are not applied on the delivered results, making pages with restricted visibility returned in the results. Scenario: - add a search widget on the website - restrict a page to a given group - search terms of that page with a user without that group Result: the page is shown in the search results. Fix: handle visibility criteria the same way as we do it in the ir.ui.view()._handle_visibility method, and prevent showing unaccessible pages in the autocomplete results. Also adds access rule checks to ensure custom ACLs are taken into account. This commit also fixes: - the lack of filtering when using an empty search term - filtering out the non indexed pages opw-3964793 opw-4930197 Forward-Port-Of: odoo/odoo#219344
Enhancements to existing features
This update adds Mexican localization support for additional 16% withholding tax scenarios with split distributions, along with the related accounts and fiscal positions. It also improves tax precision so 10.67% taxes can be calculated and displayed more accurately for compliant accounting.
Original PR description
Add few 16% taxes with special distribution (1/3 - 2/3 and 1/4 - 3/4). Also add few accounts and a new fiscal position for each new tax. Also adjust the rounding precision of 10.67% taxes. Linked:https://github.com/odoo/enterprise/pull/83582 task-4571928
Saudi e-invoicing certificate requests now include the exact Odoo software version, including both major and minor version details. This helps ensure certificates are generated with more precise version information, improving compliance traceability with minimal user impact.
Original PR description
Make sure we user the exact software version from which the certificate is being generated, which should include the major and minor version, instead of just the major version. task-4985629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Spanish chart of accounts now classifies account 411000 as a current liability instead of a current asset. This improves the accuracy of financial statements by placing supplier bills of exchange payable in the proper liability category.
Original PR description
This commit changes the account type for account `411000 Acreedores, efectos comerciales a pagar`. It was previously set as a `Current Asset` and now its account type is `Current Liability`. Task : 4757149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes duplicating Italian electronic invoicing document types smoother by preventing an immediate duplicate-code error. Users get a more practical workflow when copying existing document type records, reducing confusion and interruption.
Original PR description
In https://github.com/odoo/odoo/commit/3e557745f16c33ab3c1b5984d6297913a8849024, we added a contraint to avoid same code. The "issue" with that is that the Duplicate option instantly raises the constraint. It's not really user-friendly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218933
This update ensures Odoo modules list the official Odoo website in their module information. It improves consistency in module metadata and helps users find the correct company website from module details.
Original PR description
All modules from odoo/odoo should have website: https://www.odoo.com
Mexican localization now includes additional 16% withholding tax setups with specific split distributions, plus matching accounts and fiscal positions. The update also improves rounding precision for 10.67% taxes, helping businesses calculate and report these tax scenarios more accurately.
Original PR description
Add few 16% taxes with special distribution (1/3 - 2/3 and 1/4 - 3/4). Also add few accounts and a new fiscal position for each new tax. Also adjust the rounding precision of 10.67% taxes. Linked:https://github.com/odoo/odoo/pull/206406 task-4571928
Resolved issues and error corrections
This fixes a date-sensitive automated test in the Time Off module by ensuring all related logic runs with a fixed date. It helps prevent false test failures caused by the current calendar date, improving reliability for future updates.
Original PR description
Given that accrual plans are related to dates, all the testcase logic has to be inside 'with freezetime' to avoid date related errors Runbot-error: https://runbot.odoo.com/odoo/runbot.build.error/230722
This fix ensures Spanish POS orders follow the correct Veri*Factu workflow: eligible orders can be sent after session closing, already registered orders no longer show an unusable send option, and cancellations are blocked in favor of refunds. This helps businesses avoid unsupported compliance actions and reduces confusion for staff handling Spanish electronic reporting.
Original PR description
- The "Send Veri*Factu" button is currently also visible for registered orders (but we can not send documents for such orders anyway; we do not support subsanacion) - We do not allow generating Veri\*Factu documents for posted orders. That makes it impossible to (Veri\*Factu) send orders after the session is closed. - We should not allow to Veri*Factu cancel orders. They would still be included in the closing move. The user should create refund instead. task-None Forward-Port-Of: odoo/odoo#222668
This fixes an intermittent failure in mail-related automated tests by making them wait properly for asynchronous server responses. It helps keep the validation pipeline stable, especially when test servers are under heavy load, without changing user-facing behavior.
Original PR description
These tests were failing due to `expect.verifySteps()` being empty rather than the RPC response. The rpc response is asynchronous and awaiting the click doesn't necessarily mean the RPC had time to effectively happen, especially when runbot CPU load is high. Fixes runbot-error-160954
Point of Sale now applies the same tax treatment in the user interface as in the backend when an order includes a negative line. This prevents mismatched totals and helps avoid accounting entries becoming unbalanced.
Original PR description
Before this commit, when an order contained a negative line, the backend treated it as a refund line while the POS UI did not. This mismatch caused inconsistent tax calculations between the UI and the backend, which could result in unbalanced journal entries. With this commit, the tax calculation logic is aligned between the UI and the backend, ensuring consistency and preventing unbalanced moves. opw-4972314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adjusts an automated test for the HTML editor so it opens the font size menu in a more consistent way. It helps reduce intermittent test failures, improving confidence in release validation without changing user-facing behavior.
Original PR description
The fix at [1] fixed the case when the dropdown had not yet opened, but that was not really the cause of the issue here. It's unclear to me what is the issue exactly, but I've noticed this particular test did open the font size dropdown in a slightly different way than other tests which do not have the same non-deterministic issue. runbot-230945 [1]: https://github.com/odoo/odoo/pull/222583
This change improves the reliability of an automated test for public discussion channels by ensuring the page has fully reloaded before the test continues. It helps reduce false failures in validation systems, making releases and maintenance checks more dependable without changing user-facing behavior.
Original PR description
This test suspiciously fails in various ways in all versions before the following PR: https://github.com/odoo/odoo/pull/214358 This seems to indicate an issue with the page reload. Properly wait for the page to reload before proceeding with the next steps in the tour, hoping it will resolve all the related issues. https://runbot.odoo.com/odoo/error/111051 https://runbot.odoo.com/odoo/error/223165 https://runbot.odoo.com/odoo/error/227755 https://runbot.odoo.com/odoo/error/227756 https://runbot.odoo.com/odoo/error/227757 https://runbot.odoo.com/odoo/error/227758 https://runbot.odoo.com/odoo/error/229657 https://runbot.odoo.com/odoo/error/229724 https://runbot.odoo.com/odoo/error/229745 https://runbot.odoo.com/odoo/error/229817 https://runbot.odoo.com/odoo/error/230901
Partner autocomplete now uses standard industry codes instead of internal database IDs when receiving Dun & Bradstreet data. This prevents errors when a customer has customized, removed, or recreated industry records in their Odoo database, improving reliability during company data enrichment.
Original PR description
Ticket #4992568 highlighted a weird way of sending the industry from IAP to the Odoo client. Before this commit, we were sending the IAP psql id of the industry to the client. There, it would be use as is. It works because these industries haven't been changed in years and they're created in the same order. However the ticket highlighted the fact that a user can edit/delete/create its own industries, therefore some ids that exist on IAP might not exist on the client's Odoo instance. This resulted in a traceback on the client's side. With this commit, we now send the industry code (the ISIC: International Standard Industrial Classification) instead to the client. There it can correctly be mapped if it exists on the client's DB (e.g. not deleted) opw-4992568 https://github.com/odoo/iap-apps/pull/1152 Forward-Port-Of: odoo/odoo#222486
Calendar meetings that do not have an assigned organizer are now shown correctly when users group the list by responsible person and creation date. This prevents valid meetings from being hidden, improving visibility and reliability for calendar planning.
Original PR description
__Issue__ In the calendar list view, meetings with no organizer and default privacy (`privacy=False`) are excluded when grouping by Responsible and Created On. __Steps to Reproduce__ 1. Create a meeting with: - `privacy` set to default, - no `organizer` 2. Go to Calendar > List view. 3. Group by Responsible, then by Created On. → The meeting is missing from the view. __Fix__ Adjust the domain to include meetings where: - `privacy=False`, and - either `user_id` is unset or their settings are in the public allowed list. - opw-4841266
This fixes sales reporting for Point of Sale orders when the same product appears on multiple order lines and is shipped later. Delivered quantities are now split correctly across the lines, preventing inflated totals such as reporting 16 delivered instead of 8.
Original PR description
If you made a sale with multiple lines having the same product, the qty_delivered was not correctly computed on the different lines. Steps to reproduce: ------------------- * Activate the ship later…
If you made a sale with multiple lines having the same product, the qty_delivered was not correctly computed on the different lines. Steps to reproduce: ------------------- * Activate the ship later option in the PoS settings * Open PoS * Add any product with a quantity of 5 * Apply a discount of 20% to the line * Click on the same product so that they are added as a second line * Change the quantity of the second line to 3 * Validate the order and use the ship later option * Validate the picking * Go to the sale report and check the qty_delivered for the product > Observation: The qty_delivered is doubled, 16 instead of 8. Why the fix: ------------ The qty_delivered was computed by summing the quantities of all moves for the product, but it did not take into account that the same product could be present in multiple lines of the same order. We now make sure to dispatch the delivered quantity correctly across the different lines of the order, ensuring that the qty_delivered is accurate. opw-4826487
This fix prevents an error when users duplicate multiple Point of Sale configuration records from the list view. It allows the duplication action to complete reliably for more than one selected record, improving day-to-day administration of POS settings.
Original PR description
### Steps to reproduce the issue: 1) In the Point of Sale app, when trying to duplicate more than two records from the list view, it gives a singleton error. The implementation was added to the master branch from commit [1]. [1]: https://github.com/odoo/odoo/pull/92664/files#diff-4c6e412c7d8f4df2a05831547e7df93d0b91f510d03b7b3ed0d689a18f5dae44R360-R361 opw-4969713 ### Description of the issue/feature this PR addresses: #### Issue Previously, when duplicating more than one pos.config record, it would give a singleton error. #### Solution Added a for loop to iterate over the config records individually. ### Current behavior before PR: https://github.com/user-attachments/assets/ba5a3969-7647-4943-a0b1-12b1961f26cd ### Desired behavior after PR is merged: https://github.com/user-attachments/assets/b952b711-7782-4e9d-b05a-e4019ab79d87 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale now plays the expected error sound when an unknown barcode is scanned, alongside the on-screen warning. This restores feedback that helps cashiers quickly notice failed scans and matches behavior from earlier Odoo versions.
Original PR description
When scanning an unknown barcode, the error notification pop-up is displayed, but the error sound is not played. Steps to reproduce: ------------------- * Open PoS * Scan an unknown barcode > Expected: Both the 'BIP' and the error sound should play. Why this fix: ------------- This feature was present in 16.0 and 17.0, but was lost in 18.0 REF. It was reintroduced in 18.3 with this [IMP](https://github.com/odoo/odoo/pull/209478). opw-4987066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where custom readonly fields on invoice lines could still be changed, causing invoices to appear modified unexpectedly. The readonly override is now limited to the intended invoice line fields, preserving user-defined protections in Studio.
Original PR description
Steps to reproduce ================== - Go to invoices - Open studio - Click on the invoice lines - Edit the list view - Add a new field of type checkbox - Mark that field as readonly - Exit studio - Open an invoice - Click on the checkbox => The form is marked as dirty and the checkbox is toggled Cause of the issue ================== https://github.com/odoo/odoo/commit/291518a7e7708690d183b9d1ca53c84d0c56ad90 If the state is not in ["cancel", "done", "posted"], the fields are never in readonly Solution ======== Only do this for the "name" and "product_id" fields opw-4917471
Uninstalling the Marketing Card module could leave behind database leftovers and block clean reinstallations. This fix skips unnecessary cleanup during module removal so uninstall and reinstall operations complete reliably.
Original PR description
Because it overrides the unlink of `IrModel` odoo/odoo#214315 breaks a ton of model uninstall/reinstall (basically all its dependencies, direct or transitive): when `marketing_card` is marked for…
Because it overrides the unlink of `IrModel` odoo/odoo#214315 breaks a ton of model uninstall/reinstall (basically all its dependencies, direct or transitive): when `marketing_card` is marked for uninstallation, all its fields get removed first (because that's how `_module_data_uninstall` does things), so all the non-magic columns are dropped. Then, when trying to `unlink` the `ir.model` records the `unlink` call fails with some sort of "column does not exist" error (on `active` or `res_model`), the unlink fails, which leads the tables to not be removed, leaving a ton of garbage in the database. This in turns means trying to reinstall the module also fails, as many tables will have a few records left for one reason or another before they are dropped, so new columns which are `required` without a `default` fail to set up their constraint, which logs both errors and warnings on reinstall. None of this is necessary, if `marketing_card` is being uninstalled we can just ignore the entire issue as the table should be dropped eventually, even if it worked it would be a waste of time. https://runbot.odoo.com/odoo/error/230837
This fix prevents an error when a user presses Enter while chat group search results are still loading on a slow connection. It makes the mail chat search experience more reliable and avoids an unexpected interruption for users.
Original PR description
Description of the issue/feature this PR addresses: --- **Reason for PR** When a user searches for a chat group, if the network is slow and the search results have not yet been loaded, pressing **Enter** will cause the system to attempt to access the `unselectable` property of an `option` variable that is not yet initialized. This leads to the following error: ``` Uncaught Javascript Error: undefined is not an object (evaluating 'option.unselectable') ``` This PR adds handling to prevent the error when data has not been fully loaded. --- Current behavior before PR: https://github.com/user-attachments/assets/de3964c7-ff83-4f94-bc1a-cb8e09bfb62f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222576
Saudi e-invoice QR codes now use the amount due on the specific invoice instead of the full sales order total. This prevents ZATCA warnings on regular invoices after down payments and helps invoices be accepted cleanly.
Original PR description
#### Step to reproduce: - In a company in Saudi Arabia - Create a sale order to a customer (B2C) - Create an invoice as a downpayment and confirm it - Process the ZATCA invoice if needed (blue banner at the top) - Create an invoice as a regular payment and confirm it - Process the ZATCA invoice if needed (blue banner at the top) #### Current behavior: - ZATCA return a 200 code for the downpayment invoice. - ZATCA return a 202 code with a Warning for the regular payment invoice. The warning states that the invoice was accepted however it needs the Tag 4 of the QR code to be Amount due payment (BT-115) #### Expected behavior - ZATCA return a 200 code on both invoices. opw-4848578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219464
The self-order table selection popup now shows restaurant tables in a predictable order by floor and table number. This makes it easier for customers or staff to find the right table and reduces confusion during ordering.
Original PR description
Task [#4991803](https://www.odoo.com/odoo/my-tasks/4991803) Runbot: https://runbot.odoo.com/runbot/bundle/18-0-incremental-order-table-pop-pos-self-order-ltra-391429 --- When selecting a table in the POS self-order, we sort the tables by `floor_id` and then by `table_number` in ascending order. This ensures a consistent and user-friendly experience when choosing a table.
Leave validation no longer fails for employees who do not have a fixed working schedule. The system now uses the employee resource timezone as a fallback, helping managers process time off reliably for fully flexible staff.
Original PR description
Currently, if we try to validate a leave for a fully flexible employee (employee without a working schedule), we get a traceback when fetching the timezone from the working schedule. To rectify this issue, we default to the timezone of the resource. opw-4979974
The Point of Sale now reuses an existing empty order when staff select New Order from the receipt screen, rather than creating another blank order. This keeps sessions cleaner and avoids accumulating unnecessary empty orders.
Original PR description
- When clicking `New order` on the receipt screen, we now want to reuse an empty order (not finalized and no order lines) before creating a new one. This avoids creating many useless empty orders. task-id: 5003010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now restore an earlier task description from history, make further edits, and save without seeing an incorrect history-related error. This prevents disruption when using task version history and helps keep project work updates reliable.
Original PR description
Problem: When applying a specific version from history in `task.description`, then updating and saving it, an error appears stating the content was saved from a different history model. Cause: When inserting versioned content, the required `data-last-history-steps` attribute is not included. Solution: Ensure the latest `data-last-history-steps` is added when restoring a version. Steps to reproduce: - Open Project > any task - Change the description - Save - Open version history and apply any version - Update the description - Save - Error appears opw-4829553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error when a user linked to one company views an e-commerce website or products belonging to another company. It ensures the website can read the company currency needed for product display, improving reliability for multi-company online stores.
Original PR description
A multi-company issue can occur when a user from another company tries to access products belonging to a different company. Steps to reproduce: 1. Create a e-commerce website without a pricelist on company A 2. Create a user assigned with only access to company B 3. Connect with this user and try to access the products on the website of company A An error will be raised because the user does not have access to company A. opw-4983506 Forward-Port-Of: odoo/odoo#222457
Peru PLE reports 5.1 and 6.1 now keep the original account move name exactly as entered, including spaces and slashes. This helps ensure exported report data remains complete and audit-ready for tax authority reviews.
Original PR description
Problem: For PLE reports 5.1 and 6.1, the value for `glosa` was being modified (i.e. blank spaces and slashes removed). Although SUNAT accepts the modified value, no information should be removed in the case it might lead to issues with tax authorities during an audit. Solution: The value for `glosa` on the reports should be the exact account move name. opw-4803060 Forward-Port-Of: odoo/enterprise#92167 Forward-Port-Of: odoo/enterprise#91967
Shared document links that have been moved or redirected now send users to the correct content. This preserves access for older links and reduces broken-link issues for document users.
Original PR description
We do not currently check for `documents.redirect` records when accessing the `/documents/content/<access_token>` endpoint. This commit fixes this by redirecting if a `document.redirect` with the appropriate `access_token` was created for backwards compatibility. opw-4517698
A manufacturing work order test now turns on the required lot tracking settings before running. This prevents false failures when demo data is not available, helping keep quality checks reliable without changing user-facing behavior.
Original PR description
The mrp lot generation test lacked the settings to properly add and process lot data, causing it to fail without demo data. This commit aims to address that. Error: https://runbot.odoo.com/odoo/error/229706
The German EC Sales List CSV export now includes the required version information expected by the Elster portal. This prevents valid reports from being rejected during upload and helps businesses submit their EU sales declarations without manual correction.
Original PR description
When uploading the EC Sales List csv to Elster.de portal, users will see the file rejected with the following error (EN translated) """ Your CSV file was created for an older version of the CSV interface. Please refer to the version table in the import help for the latest version of the interface and any changes. If the version information is correct, please check the encoding of your CSV file. The permitted encoding is UTF-8. """ This occurs because the csv is missing the version strings identifying the versions of data format References: https://www.elster.de/eportal/helpGlobal?themaGlobal=zmdo_import_eop https://www.datev-community.de/t5/Betriebliches-Rechnungswesen/Import-CSV-Daten-nacvh-Elster-f%C3%BCr-ZM/td-p/480079 opw-4850314
Fixes an error that could occur when users enabled the Account Types filter and expanded an account in the General Ledger report. This improves reliability for finance teams using filtered ledger views, especially for payable and receivable accounts.
Original PR description
Steps to reproduce:
- Open general ledger configuration
- Under Options tab, set filter Account Types as "Payable and receivable"
- Open General Ledger report
- Unfold an account
Traceback will raise
```
File "[...]/odoo/tools/query.py", line 101, in add_join
assert self._joins[alias] == (sql_kind, table, condition)
AssertionError
```
Because of the account types filter we already add a "LEFT JOIN" between account_move_line and account_account
Then, trying to add a "JOIN" between the same tables, the system find a different type of JOIN and fails the assert
opw-4742411The recurring invoice job now checks a larger set of subscriptions so eligible subscriptions are less likely to be skipped when some records are filtered out. This helps businesses avoid missed subscription invoices during scheduled billing runs while keeping performance safeguards in place.
Original PR description
**Steps to reproduce** With the default batch size of 30: - create 1 subscription not requiring payment and confirm it - create 31 subscriptions requiring payment and confirm them - launch the…
**Steps to reproduce** With the default batch size of 30: - create 1 subscription not requiring payment and confirm it - create 31 subscriptions requiring payment and confirm them - launch the "Generate recurring invoices" cron - the first subscription is not invoiced **Cause** Issue since commit https://github.com/odoo/enterprise/commit/9bad2716c3903ff89dad5f1d4bc0a2fb39c76293 Since the search with the `_recurring_invoice_domain` only returns the first batch_size + 1 records, and a subsequent filtering by `_get_subscriptions_to_invoice` is applied, `len(all_subscriptions) > batch_size` doesn't guarantee that there aren't more subscriptions to invoice not returned by search. **Solution** Increase the limit's size so that `need_cron_trigger` is True in the case where some records are filtered by `get_subscriptions_to_invoice`. In the case where a lot of subscriptions are filtered and the issue still persists, increasing the `batch_size` to process all subscriptions is necessary. The limit is not removed for performance reasons. opw-4766637
This fix ensures Mexican point-of-sale orders use the correct currency rounding when checking totals. It prevents fully discounted orders from being incorrectly blocked by a validation error caused by tiny rounding differences.
Original PR description
Issue: With specific prices and discounts, we can get an rounding issue that does not pass the Validation Error. Purpose of this PR: To round the amount total based on the currency's rounding precision to pass the check. Steps to Reproduce on Runbot: install pos, l10n_mx create products prices with 75.00 and 60.00 respectively. create discount 100% on order change decimal accuracy to 3, change tax to Include with Price create PoS order with products and apply discount receive ValidationError even though the amount total should be rounded to 0.0. opw-4944830
This update fixes an automated test so it no longer fails depending on the time of day or the user's timezone. It helps keep quality checks stable without changing any customer-facing timesheet or holiday behavior.
Original PR description
Before this commit, when the `test_timer_methods_handle_project_access_restrictions` test is executed after 22h in UTC the test failed because the timezone of the current user is the belgian one. This commit makes sure the date and timezone no longer affects this test since it is not the purpose of this test. runbot-error-230490
The Argentina electronic invoicing test setup now stops after a limited number of connection attempts instead of retrying indefinitely. This reduces wasted test time and helps avoid repeatedly hitting external services when they are unavailable.
Original PR description
In 18.0 and above test hasn't worked in months, half the time it fails because pretty much nothing works in it and half the time it's because it keeps looping on trying to set up the connection and failing (possibly because we're getting blacklisted due to how much spamming we do). For now restrict to just trying 5 times (per class since it's called from a `setUpClass`) with an exponential backoff. This may yet end up in removing the entire test directory as it doesn't seem like anyone cares. Forward-Port-Of: odoo/enterprise#92207
The portal now shows total hours based only on validated timesheets when that invoicing policy is selected. This keeps the displayed total consistent with the visible timesheet lines and avoids overstating billable or tracked work for customers.
Original PR description
### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines…
### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines shown is the validated ones only but the Hours spent includes the non-validated ones too ### Current behavior before PR: The total hours spent for timesheets in portal view when setting the invoicing policy to 'Validate Timesheets Only' is calculated wrongly as it takes the non validated ones into account. This is happening as when passing the values to the view we pass 'task_sudo' variable which will have the SUPERUSER as the env.user https://github.com/odoo/odoo/blob/saas-17.2/addons/project/controllers/portal.py#L569 so it won't pass the condition if the user is portal or not https://github.com/odoo/enterprise/blob/saas-17.2/sale_timesheet_enterprise/models/project_task.py#L33:L35 and it will calculate all the timesheet without taking validation into condisderation. ### Desired behavior after PR is merged: As we are using those computed fields only in portal views so we don't have to check if the user is portal user as even if an internal user is showing the same view for testing he should be able to see the same data as the portal user. opw-4193842