Wednesday, June 25, 2025
81 changes · saas-18.4
Enhancements to existing features
The website SEO optimization dialog now restores the clearer previous layout for showing where keywords are mentioned. A helpful tooltip was also added to the Content Check subtitle, making the tool easier to understand and use.
Original PR description
Following the changes introduced in [1], the structure of the keywords table in the SEO optimization tool was modified. To improve readability, this commit reverts to the previous "mentioned in" layout. Additionally, a tooltip has been added to the "Content Check" subtitle for better UX. [1]: https://github.com/odoo/odoo/commit/24019e44ebd30fdd785ab4731108eff04bb88ce8 task-4313421 task-4876497
The website editor’s animated text settings panel can now resize vertically based on its content instead of staying fixed. This makes the editing experience smoother and easier to use when options change size.
Original PR description
When animated text option was added to the toolbar, the size of the popover was fixed, to avoid annoying moves of the popover when the content changed size. But moving vertically the popover when the content changes is not too annoying, and having the height adapted to the content is nicer. Animated text option: e80a2a20d4ba49b51f31f8ed06a5a0d3d1fa2e6d task-4367641
Resolved issues and error corrections
Alternative purchase requests now keep their connection to the related sales order when products use the make-to-stock/order route. This prevents purchasing documents from losing sales context, helping teams trace procurement back to customer demand.
Original PR description
*: purchase_requisition, purchase_requisition_stock This commit fixes a single app test error because of this PR: https://github.com/odoo/odoo/pull/210812 The PR keeps the linkage between the alternative RFQs and SO when the product is in MTSO route.
Code cleanup and technical improvements
This update streamlines how the website builder detects preview mode when applying or cleaning design actions. It reduces internal coupling between builder components, making the website editing experience easier to maintain without changing visible business workflows.
Original PR description
*: website, website_sale Remove unnecessary dependency on `history` plugin just to know whether we're previewing or not. This makes more sense because previewing is done at the level of Builder components behaviors, which are defined in `utils.js`.
Miscellaneous changes
Prior to this change, when users cancelled their payment, they remained stuck on their previous order. It was not possible to cancel the order from the basket page. This change allows the user to cancel the order from the shopping cart page. taskId: 4830007 Forward-Port-Of: odoo/odoo#214437 Forward-Port-Of: odoo/odoo#212140
Original PR description
Prior to this change, when users cancelled their payment, they remained stuck on their previous order. It was not possible to cancel the order from the basket page. This change allows the user to cancel the order from the shopping cart page. taskId: 4830007 Forward-Port-Of: odoo/odoo#214437 Forward-Port-Of: odoo/odoo#212140
This fixes a crash that occurred when editors tried to show hidden website elements while translating a multilingual page. It helps website teams manage translated pages more reliably, especially when working with popup content.
Original PR description
Before this commit it would crash when you clicked on the visibility button in the invisible elements section while translating a website. To reproduce the issue: 1. Create a multilingual website 2. Drop a popup snippet 3. Switch to a secondary language, click edit and select "translate" 4. Click on the eye in the invisible elements panel below => We have an error. This commit follows [the html_builder refactoring]. [the html_builder refactoring]: odoo/odoo@9fe45e2b7ddb
This fix makes the red delete button in website builder lists respond when clicked directly. It removes a small usability issue that forced users to click beside the icon to delete list entries.
Original PR description
Steps to reproduce: - In website builder - In an option with a builder list (I got one in a form with a field of type "Guest") - Add some entries - Click exactly on the delete button (the red minus) - Bug: It does not work (user must click outside of the icon to delete) The bug was introduced during the initial refactor of website builder Website refactor: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
The website translation mode no longer loads an editing shortcut tool that is unnecessary in that context. This prevents confusing or irrelevant controls from appearing while users translate website content.
Original PR description
This commit removes the `powerbox` plugin from the website in translation mode. The `powerbox` plugin was added after the refactoring in master, but it is not needed in translation mode as it does not serve a purpose there. Issue: 
Product variant previews on the website now appear in the same order as the matching product combination, making the shopping experience more consistent. Preview options are also disabled when variants are not created upfront or are created dynamically, preventing confusing settings from being shown.
Original PR description
Follow up of d930c3d424fb75149072774b847a6b13d277b771: 1. Make sure that displayed variants match the order of the first matching combination on /product page. 2. Disable the preview_variants and the is_thumbnail_visible fields when variant creation is 'no_variant' or 'dynamic'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product names are no longer repeated in stock move descriptions when they are already shown elsewhere on the picking form. This makes warehouse transfer information easier to read and avoids duplicate text for users handling stock and dropshipping operations.
Original PR description
This commit makes sure that product name is not shown in the move description if exists at all. The new description widget applied in odoo/odoo#177390 looks for product's `display_name` to hide it. This commit makes `display_name` the fallback value for the description instead of `name` so that it's properly hidden in the picking form. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes the Argentina online sales test suite run correctly when the module is tested on its own. It removes a hidden dependency on another website sales test setup, reducing false test failures and improving release reliability.
Original PR description
## Before this commit: Running `l10n_ar_website_sale` tests in isolation (e.g., single module install with `--test-enable`) failed due to `access rights`. The test class relied on inherited setup from `website_sale's` test common, which implicitly granted sales-related access to the test user. This caused `AccessError` when attempting to create `sales orders`. ## After this commit: The test class no longer inherits from `WebsiteSaleCommon`, avoiding unintended dependencies and access rights assumptions. The tests now run successfully when the module is installed and tested on its own. > Error Log - https://runbot.odoo.com/odoo/runbot.build.error/227642 > Commit Causing Issue - https://github.com/odoo/odoo/commit/e331bcf1cb62d4610fb8d9bbca90e925a676fa38 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue in the website builder where applying a highlight to text near the footer could create unnecessary blank space and allow scrolling beyond the page bottom. This keeps edited pages visually tidy and prevents confusing extra scroll area for website editors.
Original PR description
Steps to reproduce: - Open website builder - Select text at the bottom of the footer - Set some highlight - Bug: - Can scroll down below the bottom of the footer - There is some blank space below the list of highlights task-4367641
This fix makes week numbers appear in bold in the date picker, matching the intended visual style. It improves readability and consistency for users selecting dates by week.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/215343 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
The date picker now shows week numbers by default when selecting a date range, matching the behavior used in other date selection modes. This removes a small inconsistency and makes calendar-based scheduling clearer when dates are added or changed dynamically.
Original PR description
Before this commit, if no value for ´showWeekNumbers´ was set, week numbers were not shown in range mode, whereas in other modes they were displayed. This behavior was inconsistent, especially when a start or end date could be added dynamically. It was likely an aesthetic decision for cases where two calendars were displayed side by side before [1]. ´showWeekNumbers´ is now set to ´true´ by default no matter the case. [1]: https://github.com/odoo/odoo/pull/214383
This fix prevents the website builder from crashing when a disabled image-related snippet is opened in the editing sidebar. It restores a missing component definition so business users can continue editing pages without interruption in this edge case.
This fix prevents the website editor from crashing when users select text and use the AI toolbar. It ensures the editor reads page record details from the correct part of the page, improving reliability for content editing.
Original PR description
__Current behavior before commit:__ `getRecordInfo` tries to get the record info from the closest element of the selection. However the info may rather be in one of its ancestor. This can lead to a crash when using the AI toolbar button after selecting some text. __Description of the fix:__ Add a `predicate` argument in the `closestElement` call in order to make sure that `editableEl` has the record info. Website refactor: https://github.com/odoo/odoo/pull/187419 task-4367641
This fix helps the editor recognize matching formatting even when class or style details are listed in a different order. It prevents unnecessary duplicate markup when adjacent highlighted text is merged, keeping website content cleaner without changing the visual result.
Original PR description
The `areSimilarElements` is used by `mergeAdjacentInline` function to merge similar node and having a clean DOM. In website, highlights use this function but highlights node can have two similar node but with different style order. This commit make `areSimilarElements` compare class and style attributes without considering order.
The website theme editor now correctly saves the System Fonts option when selected. This prevents invalid theme settings and helps users apply their intended typography without manual fixes.
Original PR description
When [1] introduced `html_builder`, the font family picker was re-created in Owl.
The new implementation did not make the difference between the font family used as style to display the font example inside the dropdown, and the font family value actually being set inside the SCSS.
When picking "System Fonts", this led to entries in the `user_values.scss` looking like this:
```scss
'font': var(--o-system-fonts),
```
instead of this:
```scss
'font': 'SYSTEM_FONTS',
```
This commit introduces a distinction between both values to solve this issue.
[1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-4367641Website forms can again use record-based fields when setting conditional visibility rules. This prevents previously working form behavior from breaking after a refactor and keeps website form configuration reliable.
Original PR description
This commit fixes the test_form_conditional_visibility_record_field tour. During the refactoring, the logic to handle record fields in conditional visibility was unintentionally removed. This functionality was originally introduced in commit [1]. This commit reintroduces the missing logic to ensure record fields are correctly handled in conditional visibility conditions. [1]: https://github.com/odoo/odoo/commit/24a7112d7b85d045ffb0629f7feb6e5556e809a1
This fix makes automated website editor checks wait for the page editor to be fully ready before saving. It reduces timing-related failures in appointment and knowledge website test flows, helping maintain release stability without changing end-user features.
Original PR description
*website_knowledge The related commit on community codebase [1] changed the behaviour of `InteractionService.shouldStop()` such that it returns true also when `el` contains `interaction.el`. This means that in edit mode interactions will restart more often: to prevent timing problems in tours, the step `waitIframeIsReady()` is now included in `clickOnSave()`. task-4367641 [1] https://github.com/odoo/odoo/commit/76a1c09c699c220b3f6f31c121b3defb776b3cc6
The subscription portal now safely handles missing resume invoice dates instead of crashing during payment. This prevents affected customers from seeing an error when paying quotations for subscriptions that cannot be paused by the user.
Original PR description
When `next_invoice_date_at_resume` is falsy (None), the template tried to call `format_date(None)`, which resulted in a `'NoneType' object is not callable` error. This commit adds a safe check both in the controller and the template to ensure the value exists before formatting.
Versions -------- - saas-18.2+ Steps ----- 1. Have a product with optional products and/or variants; 2. add the product to your wishlist; 3. go to wishlist; 4. click on the cart button; 5. close the configurator using the × in the top right corner. Issue ----- The product gets removed from the wishlist, even though it wasn't added to the cart. Cause ----- Before b8d0ab4275b24, the product configurator would never get shown from the wishlist, but with the centralizing of the
Original PR description
Versions -------- - saas-18.2+ Steps ----- 1. Have a product with optional products and/or variants; 2. add the product to your wishlist; 3. go to wishlist; 4. click on the cart button; 5. close the…
Versions -------- - saas-18.2+ Steps ----- 1. Have a product with optional products and/or variants; 2. add the product to your wishlist; 3. go to wishlist; 4. click on the cart button; 5. close the configurator using the × in the top right corner. Issue ----- The product gets removed from the wishlist, even though it wasn't added to the cart. Cause ----- Before b8d0ab4275b24, the product configurator would never get shown from the wishlist, but with the centralizing of the "Add to Cart" logic, it does pop up. The issue is that it shows up after the product has already been removed from the wishlist. Solution -------- Await the result of `addToCart`, which returns the quantity add to the cart, and only call `_removeWish` if it is greater than zero. Also ensure that the product configurator opens with the correct product attributes, and that closing it doesn't automatically redirect you to checkout, unless selected in the configurator. opw-4783677 Forward-Port-Of: odoo/odoo#214369
<b>Steps to Reproduce:</b> 1. Navigate to Inventory → Configuration 2. Search for packages and check 3. Products → Packages 4. Click or create a Package (With at least 15-20 Char). 5. Print > Package Barcode (PDF) <b>Issue:</b> - Package names containing dashes (e.g., A101-101-110-1910) or spaces (e.g., A192 2932 2039) were breaking, affecting alignment and readability. <b>Solution:</b> - Applied `white-space: nowrap` style to the text span to prevent line wrapping and ensure con
Original PR description
<b>Steps to Reproduce:</b> 1. Navigate to Inventory → Configuration 2. Search for packages and check 3. Products → Packages 4. Click or create a Package (With at least 15-20 Char). 5. Print > Package Barcode (PDF) <b>Issue:</b> - Package names containing dashes (e.g., A101-101-110-1910) or spaces (e.g., A192 2932 2039) were breaking, affecting alignment and readability. <b>Solution:</b> - Applied `white-space: nowrap` style to the text span to prevent line wrapping and ensure consistent alignment across all package name formats. <b>opw-4872595</b> Before FIX:  After FIX :  Forward-Port-Of: odoo/odoo#215354
Steps: - Open Calendar app without group_system access right Actual result: - Access error due to microsoft_calendar_token field Expected result - No error opw-4850523 Caused-by: https://github.com/odoo/odoo/pull/150186 Forward-Port-Of: odoo/odoo#214328
Original PR description
Steps: - Open Calendar app without group_system access right Actual result: - Access error due to microsoft_calendar_token field Expected result - No error opw-4850523 Caused-by: https://github.com/odoo/odoo/pull/150186 Forward-Port-Of: odoo/odoo#214328
This error occurs when both companies are selected and `Refresh tax mapping` is clicked under Taxes. Steps to reproduce: --- - Install `l10n_eu_oss` application - Create a NEW Company with EU Localizations > Switch to it - Now select both Companies - Invoicing > Configuration > Settings > Taxes > `Refresh tax mapping` Traceback: --- `TypeError: expected string or bytes-like object, got 'bool'` At [1], this error occurs because clicking `Refresh tax mapping` attempts to retrieve t
Original PR description
This error occurs when both companies are selected and `Refresh tax mapping` is clicked under Taxes. Steps to reproduce: --- - Install `l10n_eu_oss` application - Create a NEW Company with EU…
This error occurs when both companies are selected and `Refresh tax mapping` is clicked under Taxes. Steps to reproduce: --- - Install `l10n_eu_oss` application - Create a NEW Company with EU Localizations > Switch to it - Now select both Companies - Invoicing > Configuration > Settings > Taxes > `Refresh tax mapping` Traceback: --- `TypeError: expected string or bytes-like object, got 'bool'` At [1], this error occurs because clicking `Refresh tax mapping` attempts to retrieve the `Tax Payable` account code from both companies. In this case, the code from the parent company is retrieved correctly, but the child company's code is missing (i.e., False). As a result, an error is raised during the process. This commit fixes the above error by ensuring the code is fetched within the appropriate company context. [1]- https://github.com/odoo/odoo/blob/4cadc407c00dfe93af943c70d6d3b07c5ae01929/addons/l10n_eu_oss/models/res_company.py#L46-L49 sentry-6611611716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211018
Updated XML files to include the noupdate attribute for the data in project_data.xml. This change ensures that the records are not updated during module upgrades, preserving customizations. 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#214275
Original PR description
Updated XML files to include the noupdate attribute for the data in project_data.xml. This change ensures that the records are not updated during module upgrades, preserving customizations. 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#214275
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during super.onWillStart. - Modified onWillStart to ensur
Original PR description
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during super.onWillStart. - Modified onWillStart to ensure hr_access data is fetched without risking lifecycle conflicts. task-4210513 Forward-Port-Of: odoo/odoo#212695 Forward-Port-Of: odoo/odoo#187171
## Pull Request HOOT (PRHOOT) 33 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/87476 --- I confirm I have s
Original PR description
## Pull Request HOOT (PRHOOT) 33 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/87476 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215496 Forward-Port-Of: odoo/odoo#213223
Since expense reports removal (https://www.odoo.com/odoo/967/tasks/4481615), expenses paid by employee and made in foreign currency are posted using the expense currency instead of the company currency. This is an unwanted behavior. It makes sense for company paid expenses because payments are created: Having the same currency as the one used in the transaction is easier for the reconciliation. It's however unusual to keep the transaction currency for vendor bills representing debts towards th
Original PR description
Since expense reports removal (https://www.odoo.com/odoo/967/tasks/4481615), expenses paid by employee and made in foreign currency are posted using the expense currency instead of the company currency. This is an unwanted behavior. It makes sense for company paid expenses because payments are created: Having the same currency as the one used in the transaction is easier for the reconciliation. It's however unusual to keep the transaction currency for vendor bills representing debts towards the employees. In vast majority of cases employees are indeed reimbursed in company currency. task-4708953 Forward-Port-Of: odoo/odoo#205970
This PR has following commit- - **[FIX] l10n_in_ewaybill_stock:cancel remarks mandatory** (Already managed by https://github.com/odoo/odoo/pull/215523) Since it would more much better to handle the fw-port with different version this commit will be removed in saas-18.1 fw-port and will be surpassed by the above mention PR - **[FIX] l10n_in_ewaybill_stock: Allow cancelation of E-waybill** When canceling E-waybill if error `312` occurred it means the E-waybill is already been cancelled b
Original PR description
This PR has following commit- - **[FIX] l10n_in_ewaybill_stock:cancel remarks mandatory** (Already managed by https://github.com/odoo/odoo/pull/215523) Since it would more much better to handle the fw-port with different version this commit will be removed in saas-18.1 fw-port and will be surpassed by the above mention PR - **[FIX] l10n_in_ewaybill_stock: Allow cancelation of E-waybill** When canceling E-waybill if error `312` occurred it means the E-waybill is already been cancelled but in that case we raise warning while E-waybill stays in the state of `Generated`. In this commit we handle error `312`, we receive it, we will log it on the E-waybill and cancel the E-waybill as it is already being cancelled opw-4882071 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215708 Forward-Port-Of: odoo/odoo#215556
Due to historical error, the key mapped for cancel remarks seems to be incorrect. Due to which while cancelling the E-waybill we receive the error code `[659] Remark is mandatory`. In this commit, we make sure the keys are mapped correctly as per https://docs.ewaybillgst.gov.in/apidocs/version1.03/cancel-eway-bill.html Though as per the schema validation the remark is not mandatory after receiving the ticket it doesn't seems like that :) opw-4882071 --- I confirm I have signed th
Original PR description
Due to historical error, the key mapped for cancel remarks seems to be incorrect. Due to which while cancelling the E-waybill we receive the error code `[659] Remark is mandatory`. In this commit, we make sure the keys are mapped correctly as per https://docs.ewaybillgst.gov.in/apidocs/version1.03/cancel-eway-bill.html Though as per the schema validation the remark is not mandatory after receiving the ticket it doesn't seems like that :) opw-4882071 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215709 Forward-Port-Of: odoo/odoo#215523
**Issue:** When editing or creating a milestone from a task (linked to a sale order) form of a billable project, an error is caught **Steps to Reproduce:** - Enable "Milestones" in Settings > Project. - Create a billable project. - From Sales, create a sales order using a service product and generate a task in the same project. - In the task form, attempt to create and edit a new milestone. an error is caught due to the use of the widget 'Many2OneUomField' The fix is about
Original PR description
**Issue:** When editing or creating a milestone from a task (linked to a sale order) form of a billable project, an error is caught **Steps to Reproduce:** - Enable "Milestones" in Settings > Project. - Create a billable project. - From Sales, create a sales order using a service product and generate a task in the same project. - In the task form, attempt to create and edit a new milestone. an error is caught due to the use of the widget 'Many2OneUomField' The fix is about removing the widget as the view has no product field (also the widget might be useless here, as we're only displaying the sale line's UoM ) opw-4852849 Forward-Port-Of: odoo/odoo#214881
- Adding new taxes required by DIOT - Adding relevant tags and accounts Enterprise PR: https://github.com/odoo/enterprise/pull/82864 task-4568859 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215399 Forward-Port-Of: odoo/odoo#204742
Original PR description
- Adding new taxes required by DIOT - Adding relevant tags and accounts Enterprise PR: https://github.com/odoo/enterprise/pull/82864 task-4568859 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215399 Forward-Port-Of: odoo/odoo#204742
This commit fixes a UI bug in chart trendlines by ensuring 'AxisType' is properly passed from Odoo charts to the spreadsheet. Task: [4743602](https://www.odoo.com/odoo/2328/tasks/4743602) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214724
Original PR description
This commit fixes a UI bug in chart trendlines by ensuring 'AxisType' is properly passed from Odoo charts to the spreadsheet. Task: [4743602](https://www.odoo.com/odoo/2328/tasks/4743602) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214724
Before this commit, peer offer filtering was not working as the reference to the store was incorrect. This wouldn't cause tracebacks or known connection issues as the error was caught and the filter was just ignored. Forward-Port-Of: odoo/odoo#215505 Forward-Port-Of: odoo/odoo#215349
Original PR description
Before this commit, peer offer filtering was not working as the reference to the store was incorrect. This wouldn't cause tracebacks or known connection issues as the error was caught and the filter was just ignored. Forward-Port-Of: odoo/odoo#215505 Forward-Port-Of: odoo/odoo#215349
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a multi-company environment, we cannot access the warehouse of a different company. In the sale_order model, the `_init_column` method populates the warehouse value for existing sales orders before stock is installed. It uses self.env.company to set the warehouse, but `_init_colum
Original PR description
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a…
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a multi-company environment, we cannot access the warehouse of a different company. In the sale_order model, the `_init_column` method populates the warehouse value for existing sales orders before stock is installed. It uses self.env.company to set the warehouse, but `_init_column` is called with superuser privileges, which lack user context. This causes warehouses to always be linked to the superuser's company (id=1). As a result, modifying sales orders from different companies becomes impossible. opw-4735086 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#212430 Forward-Port-Of: odoo/odoo#207792
This commit reverts odoo/odoo#208302, odoo/odoo#188848 and odoo/odoo#192876. Issues have been found on the synchronization with Google related to the duplication of events for synchronized users. As it is an urgent matter and these two fixes were merged too close to prior of the first problem report, we're dropping them for additional investigation. task-4873605 Forward-Port-Of: odoo/odoo#215510 Forward-Port-Of: odoo/odoo#215449
Original PR description
This commit reverts odoo/odoo#208302, odoo/odoo#188848 and odoo/odoo#192876. Issues have been found on the synchronization with Google related to the duplication of events for synchronized users. As it is an urgent matter and these two fixes were merged too close to prior of the first problem report, we're dropping them for additional investigation. task-4873605 Forward-Port-Of: odoo/odoo#215510 Forward-Port-Of: odoo/odoo#215449
**Step to reproduce:** 1. Install `l10n_iq` and `res_partner`. 2. Create a contact with Iraq as the country and assign any state. 3. Create an invoice for that customer. **Observation:** - State codes appear as numbers (e.g., 01, 02, 03...) which are not ISO-compliant. **Issue:** - State codes in the CSV file were defined as simple numbers instead of proper ISO codes. **Solution:** - Updated all state codes to match the official ISO 3166-2:IQ codes. (Reference: https://www.iso.org
Original PR description
**Step to reproduce:** 1. Install `l10n_iq` and `res_partner`. 2. Create a contact with Iraq as the country and assign any state. 3. Create an invoice for that customer. **Observation:** - State codes appear as numbers (e.g., 01, 02, 03...) which are not ISO-compliant. **Issue:** - State codes in the CSV file were defined as simple numbers instead of proper ISO codes. **Solution:** - Updated all state codes to match the official ISO 3166-2:IQ codes. (Reference: https://www.iso.org/obp/ui/#iso:code:3166:IQ) - For Arabic names, appended `-AR` to the code (e.g., IQ-BG-AR) for Arabic-specific entries. opw-4808778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214396 Forward-Port-Of: odoo/odoo#213972
<b>Steps to reproduce:</b> 1) Install the Project module and enable debug mode. 2) Go to Configuration > Task Stages in the Project app 3) Try to create a new task stage in form view <b>Issue:</b> The Project field is not visible when creating a new task stage in the form view. <b>Cause:</b> The form view only shows the `project_id` field if the `user_id` is not set. https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/views/project_task_type_v
Original PR description
<b>Steps to reproduce:</b> 1) Install the Project module and enable debug mode. 2) Go to Configuration > Task Stages in the Project app 3) Try to create a new task stage in form view <b>Issue:</b>…
<b>Steps to reproduce:</b> 1) Install the Project module and enable debug mode. 2) Go to Configuration > Task Stages in the Project app 3) Try to create a new task stage in form view <b>Issue:</b> The Project field is not visible when creating a new task stage in the form view. <b>Cause:</b> The form view only shows the `project_id` field if the `user_id` is not set. https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/views/project_task_type_views.xml#L46-L48 However, the action context includes `default_project_id=False`, which causes the defaulting logic to compute a `default_user_id` (based on the falsy project). As a result, `user_id` is set, hiding the project_id field from the form. https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/views/project_task_type_views.xml#L143 https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/models/project_task_type.py#L19-L20 <b>Fix:</b> Add a key in the context to make the user_id as False when creating a new task stage from the Form view. opw-4767251 Forward-Port-Of: odoo/odoo#210355
### Steps to reproduce: **Issue 1:** - Go to To-do - Create a numbered list with a nested sub list. - Select all and increase the font size to 80. - Observe that ::marker in the primary list is hidden. **Issue 2:** - Create a numbered list and type something. - Press Enter, then press tab. - Write something and press backspace. - Observe that the nested list move from its place. ### Description of the issue/feature this PR addresses: - `li.oe-nested` elements do not have
Original PR description
### Steps to reproduce: **Issue 1:** - Go to To-do - Create a numbered list with a nested sub list. - Select all and increase the font size to 80. - Observe that ::marker in the primary list is…
### Steps to reproduce: **Issue 1:** - Go to To-do - Create a numbered list with a nested sub list. - Select all and increase the font size to 80. - Observe that ::marker in the primary list is hidden. **Issue 2:** - Create a numbered list and type something. - Press Enter, then press tab. - Write something and press backspace. - Observe that the nested list move from its place. ### Description of the issue/feature this PR addresses: - `li.oe-nested` elements do not have a marker, causing `markerWidth` to be `NaN`, and `Math.max(NaN, value)` also returned `NaN`, so no padding-inline-start was applied. - The nested list could shift unexpectedly because we did not adjust the list's padding when indenting with the Tab key. ### Desired behavior after PR is merged: - Fallback to default padding is applied when marker width is invalid, ensuring list marker remains visible and properly aligned. - On indenting, the list padding is properly adjusted. task-4854704 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213521
We add a button to ease logs downloading from the IoT Box http 502 error page. We also update the design to match the homepage's one. This commit also sets the configuration param `list_db = False` to avoid displaying the form when the user is redirected to `/web/database/selector` (which should not happen). Forward-Port-Of: odoo/odoo#215555
Original PR description
We add a button to ease logs downloading from the IoT Box http 502 error page. We also update the design to match the homepage's one. This commit also sets the configuration param `list_db = False` to avoid displaying the form when the user is redirected to `/web/database/selector` (which should not happen). Forward-Port-Of: odoo/odoo#215555
Problem: When copying content that includes an image with a `src` in base64 format, the origin is incorrectly prepended to the `src`, resulting in a broken image on subsequent paste. Cause: The logic that prepends the origin doesn't exclude base64 images, causing the final `src` to be invalid. Solution: Skip appending the origin if the `img.src` is already in base64 format. Steps to reproduce: 1. Copy an image (with base64 `src`) into the editor. 2. Copy the image again from within
Original PR description
Problem: When copying content that includes an image with a `src` in base64 format, the origin is incorrectly prepended to the `src`, resulting in a broken image on subsequent paste. Cause: The logic that prepends the origin doesn't exclude base64 images, causing the final `src` to be invalid. Solution: Skip appending the origin if the `img.src` is already in base64 format. Steps to reproduce: 1. Copy an image (with base64 `src`) into the editor. 2. Copy the image again from within the editor. 3. Paste the image. → The image is not shown due to incorrect `src`. opw-4872676 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214367
Fixed an issue where, when canceling a payment that originated the third-party check, the check remained in "In Hand" status when it shouldn't. Now, when the payment is canceled, the check status is properly updated to reflect its cancellation, ensuring consistency in the workflow. **Description of the issue/feature this PR addresses:** This PR addresses an issue where a third-party check remains in the "In Hand" status even after the origin payment is canceled. **Current behavior b
Original PR description
Fixed an issue where, when canceling a payment that originated the third-party check, the check remained in "In Hand" status when it shouldn't. Now, when the payment is canceled, the check status is…
Fixed an issue where, when canceling a payment that originated the third-party check, the check remained in "In Hand" status when it shouldn't. Now, when the payment is canceled, the check status is properly updated to reflect its cancellation, ensuring consistency in the workflow. **Description of the issue/feature this PR addresses:** This PR addresses an issue where a third-party check remains in the "In Hand" status even after the origin payment is canceled. **Current behavior before PR:** A customer payment is created with a third-party check. The payment is confirmed, then moved to draft and canceled. After cancellation, the third-party check remains in the "In Hand" status in the third-party checks menu, even though the origin payment has been canceled. **Desired behavior after PR is merged:** When the payment is canceled, the check will no longer remain in "In Hand" status in the third-party checks menu after the payment is canceled. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215506 Forward-Port-Of: odoo/odoo#214071
We store the server url in `store.base`, which was made unreactive by using owl `toRaw` method. This made the `disconnect from current` button not being displayed right after connecting to a database, without reloading the page. We removed this call to fix this behavior. We also called `waitRestart` before calling the disconnect method from the back end, in order to remove the delay before displaying the loader. Forward-Port-Of: odoo/odoo#215560
Original PR description
We store the server url in `store.base`, which was made unreactive by using owl `toRaw` method. This made the `disconnect from current` button not being displayed right after connecting to a database, without reloading the page. We removed this call to fix this behavior. We also called `waitRestart` before calling the disconnect method from the back end, in order to remove the delay before displaying the loader. Forward-Port-Of: odoo/odoo#215560
For a document fix, we add a method to the activity button that implements custom behavior when an activity changes. see odoo/enterprise#84128 task-4690165 Forward-Port-Of: odoo/odoo#213791 Forward-Port-Of: odoo/odoo#210988
Original PR description
For a document fix, we add a method to the activity button that implements custom behavior when an activity changes. see odoo/enterprise#84128 task-4690165 Forward-Port-Of: odoo/odoo#213791 Forward-Port-Of: odoo/odoo#210988
Restore the "New Content" ribbon (activated via page options) which should be displayed on the course card when a new published content has been added during the last 7 days. The ribbon isn't displayed because it's declared in a "t-field" element which replaces its content to display the field at rendering. Task-4852463 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213788
Original PR description
Restore the "New Content" ribbon (activated via page options) which should be displayed on the course card when a new published content has been added during the last 7 days. The ribbon isn't displayed because it's declared in a "t-field" element which replaces its content to display the field at rendering. Task-4852463 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213788
A global rule for base.group_user is missing for the event.answer.model. This commit adds it. A test has been added to check that internal users have all the permissions required to register for events. Reproduce: The administrator must create a new user and let empty the permissions for sales and for events. When trying to register for an event that has questions with options, this new user will trigger a 500 error. task- Forward-Port-Of: odoo/odoo#215444
Original PR description
A global rule for base.group_user is missing for the event.answer.model. This commit adds it. A test has been added to check that internal users have all the permissions required to register for events. Reproduce: The administrator must create a new user and let empty the permissions for sales and for events. When trying to register for an event that has questions with options, this new user will trigger a 500 error. task- Forward-Port-Of: odoo/odoo#215444
Steps to reproduce: - Open Project go to a task. - Go to Sub-Tasks sub setting page. - Don't fill anything click on view. Issue: - A trace-back instead of a sticky notification. Reason: - Missing notification service initialization. Fix: - Add the notification service initialization. Issue from PR: https://github.com/odoo/odoo/pull/197629 task-4891134 Forward-Port-Of: odoo/odoo#215433
Original PR description
Steps to reproduce: - Open Project go to a task. - Go to Sub-Tasks sub setting page. - Don't fill anything click on view. Issue: - A trace-back instead of a sticky notification. Reason: - Missing notification service initialization. Fix: - Add the notification service initialization. Issue from PR: https://github.com/odoo/odoo/pull/197629 task-4891134 Forward-Port-Of: odoo/odoo#215433
Before PR #187439, the field DescripcionFactura defaulted to `manual` when the origin was False. That PR removed the fallback and moved the default assignment to `_l10n_es_tbai_get_invoice_values` in `l10n_es_edi_tbai` module, but forgot to apply the same logic in `_l10n_es_tbai_get_values`. Steps to reproduce: - Create a new TBAI POS order - Try to submit it - You’ll get an error: ```cvc-complex-type.2.4.a: Invalid content was found starting with element 'DetallesFactura'. One of '{F
Original PR description
Before PR #187439, the field DescripcionFactura defaulted to `manual` when the origin was False.
That PR removed the fallback and moved the default assignment to `_l10n_es_tbai_get_invoice_values` in `l10n_es_edi_tbai` module, but forgot to apply the same logic in `_l10n_es_tbai_get_values`.
Steps to reproduce:
- Create a new TBAI POS order
- Try to submit it
- You’ll get an error:
```cvc-complex-type.2.4.a: Invalid content was found starting
with element 'DetallesFactura'. One of '{FechaOperacion,
DescripcionFactura}' is expected.
```
This fix restores the fallback value 'manual' for POS invoices
to ensure schema compliance.
opw-4834333
Forward-Port-Of: odoo/odoo#215157Whenever there is a fault in the ZATCA onboarding steps (like missing Certificate Signing Request (CSR) information etc.), a traceback is returned to the user instead of a clear error message. This behavior was introduced by the following PR: https://github.com/odoo/odoo/pull/205671 which changed the return format of the `_l10n_sa_call_api` function in case of failures. Steps to reproduce: - Configure a Saudi Arabia company - Switch ZATCA environment to Simulation (or Production) - At
Original PR description
Whenever there is a fault in the ZATCA onboarding steps (like missing Certificate Signing Request (CSR) information etc.), a traceback is returned to the user instead of a clear error message. This…
Whenever there is a fault in the ZATCA onboarding steps (like missing
Certificate Signing Request (CSR) information etc.), a traceback is
returned to the user instead of a clear error message.
This behavior was introduced by the following PR: https://github.com/odoo/odoo/pull/205671
which changed the return format of the `_l10n_sa_call_api` function in
case of failures.
Steps to reproduce:
- Configure a Saudi Arabia company
- Switch ZATCA environment to Simulation (or Production)
- Attempt to onboard a journal using an incorrect OTP code
- A traceback is triggered instead of a clear user-facing error
Traceback example:
```
File "/home/odoo/src/odoo/17.0/addons/l10n_sa_edi/models/account_journal.py", line 200, in _l10n_sa_compute_production_csid_validity
journal.l10n_sa_production_csid_validity = self._l10n_sa_get_pcsid_validity(
File "/home/odoo/src/odoo/17.0/addons/l10n_sa_edi/models/account_journal.py", line 516, in _l10n_sa_get_pcsid_validity
b64_decoded_pcsid = b64decode(PCSID_data['binarySecurityToken'])
File "/usr/lib/python3.10/base64.py", line 80, in b64decode
s = _bytes_from_decode_data(s)
File "/usr/lib/python3.10/base64.py", line 45, in _bytes_from_decode_data
raise TypeError("argument should be a bytes-like object or ASCII "
TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType'
```
This is due to the check in `_l10n_sa_get_compliance_CSID` for an 'error'
key, not present in the response when an OTP is invalid because in these
case, the `_l10n_sa_call_api` return the response_data directly.
This fix improves the behavior by displaying a user-friendly alert
message with the error returned by ZATCA, instead of a traceback.
This ensures a better experience and compliance with CCSID onboarding flows.
opw-4838542
Forward-Port-Of: odoo/odoo#215131
Forward-Port-Of: odoo/odoo#214391Before this commit, when the module was installed but not used, events would be duplicated even if it was not useful. As a result the following code would duplicate the activities linked to the events as _recreate_event_different_organizer would be called even if both user would not sync their calendar. ```py test_event = self.env['calendar.event'].with_user(test_user).with_context( default_res_model=test_record._name, default_res_id=test_record.id, ).create({ 'name': test
Original PR description
Before this commit, when the module was installed but not used, events would be duplicated even if it was not useful. As a result the following code would duplicate the activities linked to the…
Before this commit, when the module was installed but not used, events would be duplicated even if it was not useful.
As a result the following code would duplicate the activities linked to the events as _recreate_event_different_organizer would be called even if both user would not sync their calendar.
```py
test_event = self.env['calendar.event'].with_user(test_user).with_context(
default_res_model=test_record._name,
default_res_id=test_record.id,
).create({
'name': test_name,
'description': test_description,
'start': fields.Datetime.to_string(now + timedelta(days=-1)),
'stop': fields.Datetime.to_string(now + timedelta(hours=2)),
'user_id': self.env.user.id,
})
test_event.write({
'name': '%s2' % test_name,
'description': test_description2,
'start': fields.Datetime.to_string(now + timedelta(days=-2)),
'user_id': test_user.id,
})
```
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#215141**Issue** Duplicated Profit and Loss reports fail to open and raise an "invalid operation" error when accessed. **Steps to Reproduce** 1. Install the Accounting module and French localization. 2. Go to Accounting > Configuration > Accounting > Accounting Reports. 3. Duplicate the "Profit and Loss (2024)" report. 4. Navigate to Accounting > Reporting > Profit and Loss. 5. Attempt to open the duplicated report. 6. An error occurs. **Root Cause** During duplication, the label field of
Original PR description
**Issue** Duplicated Profit and Loss reports fail to open and raise an "invalid operation" error when accessed. **Steps to Reproduce** 1. Install the Accounting module and French localization. 2. Go…
**Issue** Duplicated Profit and Loss reports fail to open and raise an "invalid operation" error when accessed. **Steps to Reproduce** 1. Install the Accounting module and French localization. 2. Go to Accounting > Configuration > Accounting > Accounting Reports. 3. Duplicate the "Profit and Loss (2024)" report. 4. Navigate to Accounting > Reporting > Profit and Loss. 5. Attempt to open the duplicated report. 6. An error occurs. **Root Cause** During duplication, the label field of expressions is altered to include a " (copy)" suffix. Some formula expressions rely on exact label matches (e.g., i_1_2024.balance), so when "balance" becomes "balance (copy)", the lookup fails. This mismatch causes a KeyError when resolving subformulas like line_code.balance, breaking the report evaluation. **Fix** Prevent the duplication process from altering the label of expressions. There is no functional need to add " (copy)" to these internal labels, as they are not user-facing and must remain stable for formula resolution to work. Opw-4826749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212777
In this commit we remove checkDelay from codebase because it is no longer used since https://github.com/odoo/odoo/pull/194508 has been merged. 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#207531 Forward-Port-Of: odoo/odoo#205524
Original PR description
In this commit we remove checkDelay from codebase because it is no longer used since https://github.com/odoo/odoo/pull/194508 has been merged. 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#207531 Forward-Port-Of: odoo/odoo#205524
**Error:** `ValueError: Wrong value for whatsapp.template.lang_code: 'es_CO'` **Before:** Some language codes that are officially supported by WhatsApp were missing from the module's language list, leads to an error during template synchronization. **After:** This commit adds missing language codes, which are supported by WhatsApp to prevent errors during synchronization. Reference: https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates/supported-la
Original PR description
**Error:** `ValueError: Wrong value for whatsapp.template.lang_code: 'es_CO'` **Before:** Some language codes that are officially supported by WhatsApp were missing from the module's language list, leads to an error during template synchronization. **After:** This commit adds missing language codes, which are supported by WhatsApp to prevent errors during synchronization. Reference: https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates/supported-languages Sentry – 6704097351 Forward-Port-Of: odoo/enterprise#88329
when clicking the next button in the pager of the tour, it was causing issues with the report editor not being ready yet with the updated page. so added a delay after clicking n next button in the pager of the tour to avoid issues with the report editor not being ready with the updated page. build_error-163405 Forward-Port-Of: odoo/enterprise#87302
Original PR description
when clicking the next button in the pager of the tour, it was causing issues with the report editor not being ready yet with the updated page. so added a delay after clicking n next button in the pager of the tour to avoid issues with the report editor not being ready with the updated page. build_error-163405 Forward-Port-Of: odoo/enterprise#87302
Currently, an error occurs when all reconciliation models are deleted and the user attempts to create a Transactions(bank statement lines). **Steps to produce:** - Install the `accountant` module. - Navigate to `Accounting > Bank > Models (under Reconciliation)` and delete all reconciliation models. - Go to bank transactions, Create a new `bank statement line` and attempt to `save` it. **Error:** `SyntaxError: syntax error at or near ')' LINE 39: AND reco_model.id IN ()` **Root
Original PR description
Currently, an error occurs when all reconciliation models are deleted and the user attempts to create a Transactions(bank statement lines). **Steps to produce:** - Install the `accountant` module. - Navigate to `Accounting > Bank > Models (under Reconciliation)` and delete all reconciliation models. - Go to bank transactions, Create a new `bank statement line` and attempt to `save` it. **Error:** `SyntaxError: syntax error at or near ')' LINE 39: AND reco_model.id IN ()` **Root Cause:** At [1], an `SQL query` is executed that references `Reconciliation models(reco_models)`, as `reco_models` is empty, this is causing an error. [1] https://github.com/odoo/enterprise/blob/8289993c7d52a6cf71982aace87bcb11fde16967/account_accountant/models/account_bank_statement.py#L220 This commit ensures and prevent error when user add transactions without reconciliation model. sentry - 6650696331 Forward-Port-Of: odoo/enterprise#86861
When creating a SEPA Direct Debit (SDD) mandate for a contact, mandates linked to a child contact are not recognized as valid at payment registration. It should be but it suggests a configuration issue so it needs a warning but not an error. task-4507135 Forward-Port-Of: odoo/enterprise#85882
Original PR description
When creating a SEPA Direct Debit (SDD) mandate for a contact, mandates linked to a child contact are not recognized as valid at payment registration. It should be but it suggests a configuration issue so it needs a warning but not an error. task-4507135 Forward-Port-Of: odoo/enterprise#85882
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during `super.onWillStart`. - Modified `onWillStart` to ensure `h
Original PR description
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during `super.onWillStart`. - Modified `onWillStart` to ensure `hr_access` data is fetched without risking lifecycle conflicts. task-4210513 Forward-Port-Of: odoo/enterprise#86878 Forward-Port-Of: odoo/enterprise#75121
The current code of `_recompute_shifts_in_leave_periods` explicitely calls the compute method `_compute_allocated_hours` of planning.slot to recompute the allocated hours according to modifications done to the public holidays. Calling the method directly like that is far from ideal as we are missing proper batching, fields protection, etc.. that the ORM usually does for computed fields. This commit replaces the explicit call by an `add_to_compute`. This essentially marks the field as "to be r
Original PR description
The current code of `_recompute_shifts_in_leave_periods` explicitely calls the compute method `_compute_allocated_hours` of planning.slot to recompute the allocated hours according to modifications…
The current code of `_recompute_shifts_in_leave_periods` explicitely calls the compute method `_compute_allocated_hours` of planning.slot to recompute the allocated hours according to modifications done to the public holidays. Calling the method directly like that is far from ideal as we are missing proper batching, fields protection, etc.. that the ORM usually does for computed fields. This commit replaces the explicit call by an `add_to_compute`. This essentially marks the field as "to be recomputed". This recomputation then happens at the next flush_model/recompute_model call and can applies the proper ORM optimizations of batching by `PREFETCH_MAX` size, protecting fields to avoid triggering loops of recomputations. This speeds up the import of new Public Holidays in an already populated database. #### speedup In a customer database with 50K planning.slots, 1300 of which needs to recompute their allocated_hours, the import timing Before PR vs After PR is the following: - 40 min -> 4 min opw-4782452 Forward-Port-Of: odoo/enterprise#88351
Currently when using Fiskaly, the receipt gets printed with the technical names of the tss values. Steps to reproduce: ------------------- * Set up the db to use fiskaly * Open restaurant * Place and pay an order > Observation: On the receipt screen the name of the tss values are shown as: transaction_number, signature_algorithm, client_serial_number, .... Why the fix: ------------ Beore this commit https://github.com/odoo/enterprise/commit/d1a94147060083da54f9423f8c379676fbb7db66#
Original PR description
Currently when using Fiskaly, the receipt gets printed with the technical names of the tss values. Steps to reproduce: ------------------- * Set up the db to use fiskaly * Open restaurant * Place and…
Currently when using Fiskaly, the receipt gets printed with the technical names of the tss values. Steps to reproduce: ------------------- * Set up the db to use fiskaly * Open restaurant * Place and pay an order > Observation: On the receipt screen the name of the tss values are shown as: transaction_number, signature_algorithm, client_serial_number, .... Why the fix: ------------ Beore this commit https://github.com/odoo/enterprise/commit/d1a94147060083da54f9423f8c379676fbb7db66#diff-960ffa6839618d084dd5de6e29458ef68766a31250fc7d296512ec5358f04056 we were using a dictionnary `name, value` when using tss information, cf `_initTssInformation()` in `l10n_de_pos_cert/static/src/overrides/models/models.js`. We re-introduce this behavior and revert the following commit https://github.com/odoo-dev/enterprise/commit/9f75e3fe092bd838fffb11a35a8d854afff71869 to use the official names instead of the technical ones. opw-4822342 Forward-Port-Of: odoo/enterprise#88179 Forward-Port-Of: odoo/enterprise#87717
## Pull Request HOOT (PRHOOT) 33 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/213223 Forward-Port-Of: odoo/enterpris
Original PR description
## Pull Request HOOT (PRHOOT) 33 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/213223 Forward-Port-Of: odoo/enterprise#88304 Forward-Port-Of: odoo/enterprise#87476
UI-wise, there are two types of VoIP errors: blocking and non-blocking. Blocking errors are unrecoverable, they're displayed at the top of the UI and prevent further use of the softphone. Non-blocking errors, on the other hand, can be dismissed by a simple click on the error screen. Problem: the handler that hides the error screen in case of non-blocking errors wasn't attached to anything, and even if it was, its implementation was wrong! This commit makes it work as intended. Part of [tas
Original PR description
UI-wise, there are two types of VoIP errors: blocking and non-blocking. Blocking errors are unrecoverable, they're displayed at the top of the UI and prevent further use of the softphone. Non-blocking errors, on the other hand, can be dismissed by a simple click on the error screen. Problem: the handler that hides the error screen in case of non-blocking errors wasn't attached to anything, and even if it was, its implementation was wrong! This commit makes it work as intended. Part of [task-4891947](https://www.odoo.com/odoo/project/5778/tasks/4891947). Forward-Port-Of: odoo/enterprise#88358
- Reworking the DIOT report to comply with 2025 standard - Adjusting operation_type values on res.partner to match - Adjusting DIOT tests and other tests affected by the rework Community PR: https://github.com/odoo/odoo/pull/204742 task-4568859 Forward-Port-Of: odoo/enterprise#88253 Forward-Port-Of: odoo/enterprise#82864
Original PR description
- Reworking the DIOT report to comply with 2025 standard - Adjusting operation_type values on res.partner to match - Adjusting DIOT tests and other tests affected by the rework Community PR: https://github.com/odoo/odoo/pull/204742 task-4568859 Forward-Port-Of: odoo/enterprise#88253 Forward-Port-Of: odoo/enterprise#82864
**Issue:** - In sale order, first select the quotation template with a recurring plan, then, change the quotation template to without a recurring plan. After changing the quotation template, the 'Recurring Plan' (`plan_id`) field still shows the value from the previously selected template. This happens because the `plan_id` is not reset when the new template has no recurring plan. - In version 17, this case was handled in the else part and set [default value](https://github.com/odoo/enterp
Original PR description
**Issue:** - In sale order, first select the quotation template with a recurring plan, then, change the quotation template to without a recurring plan. After changing the quotation template, the…
**Issue:** - In sale order, first select the quotation template with a recurring plan, then, change the quotation template to without a recurring plan. After changing the quotation template, the 'Recurring Plan' (`plan_id`) field still shows the value from the previously selected template. This happens because the `plan_id` is not reset when the new template has no recurring plan. - In version 17, this case was handled in the else part and set [default value](https://github.com/odoo/enterprise/blob/17.0/sale_subscription/models/sale_order.py#L490) (company_id.subscription_default_plan_id), but in version 18.0, the field was [removed](https://github.com/odoo/enterprise/pull/55355/files). **Steps to reproduce:** - Install the Sales and Subscriptions modules. - Create two quotation templates — one with a recurring plan and one without. - Create a Sale Order and first select the quotation template 'with a recurring plan'. - Then, change the quotation template to 'without a recurring plan'. **Solution:** - Reset `plan_id` to `None` before computing the new value to ensure accurate computation. If the selected quotation template has a recurring plan, it will be assigned; otherwise, the plan_id field will remain empty. **Runbot v18.0 (without fix)**   OPW: [4845478](https://www.odoo.com/odoo/70/tasks/4845478) Forward-Port-Of: odoo/enterprise#87821
This commit resolves a UI bug in chart trendlines by ensuring AxisType is properly passed from the web client to Odoo charts. Task: [4743602](https://www.odoo.com/odoo/2328/tasks/4743602) Forward-Port-Of: odoo/enterprise#87936
Original PR description
This commit resolves a UI bug in chart trendlines by ensuring AxisType is properly passed from the web client to Odoo charts. Task: [4743602](https://www.odoo.com/odoo/2328/tasks/4743602) Forward-Port-Of: odoo/enterprise#87936
### Issue: The tour test_add_component_from_shop_foor_in_multi_step_manufacturing makes an assert on the value of an input before waiting for this input to be updated. runbot-build-error-226734 Forward-Port-Of: odoo/enterprise#88241
Original PR description
### Issue: The tour test_add_component_from_shop_foor_in_multi_step_manufacturing makes an assert on the value of an input before waiting for this input to be updated. runbot-build-error-226734 Forward-Port-Of: odoo/enterprise#88241
To reproduce the issue, on a Belgian company: 1) Create and post an entry impacting line "Other Appropriations of the Year", typically by using an account prefixed 69 in it. 2) Enable totals below sections in the settings 3) Open the Belgian BS at a date including the move created in 1). 4) Enable 'unfold all' in the report ===> "Other Appropriations of the Year" displays no amount This happens because this line is considered as having sublines by the engine (has_sublines is Tr
Original PR description
To reproduce the issue, on a Belgian company: 1) Create and post an entry impacting line "Other Appropriations of the Year", typically by using an account prefixed 69 in it. 2) Enable totals below…
To reproduce the issue, on a Belgian company: 1) Create and post an entry impacting line "Other Appropriations of the Year", typically by using an account prefixed 69 in it. 2) Enable totals below sections in the settings 3) Open the Belgian BS at a date including the move created in 1). 4) Enable 'unfold all' in the report ===> "Other Appropriations of the Year" displays no amount This happens because this line is considered as having sublines by the engine (has_sublines is True), since it considered a non-zero number of move lines in its computation. The condition that was there before makes it so that in that case, when using unfold_all, the line would have the 'unfolded' key set to True, even though, here, the line has no means of generating any subline (no child lines, nor groupby value). Therefore, the "totals below sections" feature hid the amount of the line, since it was supposed to be displayed in the total line. The total line, however was never added, since no expand function was ever called. Note that we could avoid doing 'groupby or has_children' in the condition here, to only use 'has_children'. We do that because that's the former behavior, and some engines (custom or standard) don't return any value for has_sublines in some cases, relying on the presence of the groupby field to properly trigger the unfold. This has changed a little in 18.1, with the introduction of a custom engine for the Trial Balance. We'll see what can be done when forward-porting, and if it's not possible, will probably do something in master later on. has_sublines should probably be mandatory everywhere. opw-4640606 Forward-Port-Of: odoo/enterprise#88359
The default_get method of the 'l10n_uk.hmrc.send.wizard' model assumed the presence of 'client_data' in the context, leading to a KeyError during test_display_name_new_record. This fix checks for the presence of 'client_data' before attempting to call import_vat_obligations. If 'client_data' is not present, it avoids calling import_vat_obligations and raises a UserError, thus preventing the KeyError. build_error-115767 Forward-Port-Of: odoo/enterprise#88297 Forward-Port-Of: odoo/enter
Original PR description
The default_get method of the 'l10n_uk.hmrc.send.wizard' model assumed the presence of 'client_data' in the context, leading to a KeyError during test_display_name_new_record. This fix checks for the presence of 'client_data' before attempting to call import_vat_obligations. If 'client_data' is not present, it avoids calling import_vat_obligations and raises a UserError, thus preventing the KeyError. build_error-115767 Forward-Port-Of: odoo/enterprise#88297 Forward-Port-Of: odoo/enterprise#84327
Since 5f001cbf0ea5e382f00602e3307ffd1fc2eb5bf1, it was possible to save a global filter with an empty label, which is not intended. This commit restore the previous behavior by preventing the saving of a global filter with an empty label. Task: 4876003 Forward-Port-Of: odoo/enterprise#87847
Original PR description
Since 5f001cbf0ea5e382f00602e3307ffd1fc2eb5bf1, it was possible to save a global filter with an empty label, which is not intended. This commit restore the previous behavior by preventing the saving of a global filter with an empty label. Task: 4876003 Forward-Port-Of: odoo/enterprise#87847
Before, a fix was done to round column for materials and payments columns but the method was HALF-UP. This should always be DOWN as specified here https://assets.publishing.service.gov.uk/media/5d53df0040f0b6098ead46c2/cis-qsbvr-v2.2.pdf page 28 task-4881298 Forward-Port-Of: odoo/enterprise#88018
Original PR description
Before, a fix was done to round column for materials and payments columns but the method was HALF-UP. This should always be DOWN as specified here https://assets.publishing.service.gov.uk/media/5d53df0040f0b6098ead46c2/cis-qsbvr-v2.2.pdf page 28 task-4881298 Forward-Port-Of: odoo/enterprise#88018
Case 1: How to reproduce ================ - Select a record in any folder in Kanban view - Display its chatter - Add an activity from the kanban tile --> the chatter is not updated and needs a refresh Expected behavior ================= Chatter should update instantly Case 2: How to reproduce ================ - Select a record in any folder in Kanban view - Display its chatter - Mark done or cancel one or more activities from Chatter - Click on the activity button of the r
Original PR description
Case 1: How to reproduce ================ - Select a record in any folder in Kanban view - Display its chatter - Add an activity from the kanban tile --> the chatter is not updated and needs a refresh Expected behavior ================= Chatter should update instantly Case 2: How to reproduce ================ - Select a record in any folder in Kanban view - Display its chatter - Mark done or cancel one or more activities from Chatter - Click on the activity button of the related kanban record --> stack trace Expected behavior ================= Corresponding KanbanRecord should update. Note: v. 17.4 raises a missing record exception for the same case task-4690165 Forward-Port-Of: odoo/enterprise#87422 Forward-Port-Of: odoo/enterprise#84128
Before, with some errors in the regex search in the different statement line attributes, the search would just return 0, when the regex was just badly written, without giving any hint to the user. Now the method will raise an user error telling the user that the regex is badly written instead of returning 0.0 or a traceback (AttributeError was not handled). Examples of previously failing regexes: - "([^\d]*)" -> AttributeError - [\d,]* -> IndexError (was already handled by https://github.co
Original PR description
Before, with some errors in the regex search in the different statement line attributes, the search would just return 0, when the regex was just badly written, without giving any hint to the user. Now the method will raise an user error telling the user that the regex is badly written instead of returning 0.0 or a traceback (AttributeError was not handled). Examples of previously failing regexes: - "([^\d]*)" -> AttributeError - [\d,]* -> IndexError (was already handled by https://github.com/odoo/enterprise/pull/84284) - ValueError shouldn't arise anymore with that same PR, but better safe than sorry Forward-Port-Of: odoo/enterprise#85881
In this PR: ========== - We are improving the mobile view to make online orders more consistent and seamless. task-4585233 Forward-Port-Of: odoo/enterprise#88305 Forward-Port-Of: odoo/enterprise#80838
Original PR description
In this PR: ========== - We are improving the mobile view to make online orders more consistent and seamless. task-4585233 Forward-Port-Of: odoo/enterprise#88305 Forward-Port-Of: odoo/enterprise#80838
<b>Steps to produce :</b> 1) Install 10n_de_reports and switch to the German company 2) Create a journal entry from accounting with a credit and debit 3) Now update the credit and debit to a different value. 4) Post the journal 5) Go to "Accounting / Reporting / Audit Reports / General Ledger" 6) Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv" <b>Issue:</b> The line for the created journal entry has a price_total of the previous balance even after updating the
Original PR description
<b>Steps to produce :</b> 1) Install 10n_de_reports and switch to the German company 2) Create a journal entry from accounting with a credit and debit 3) Now update the credit and debit to a…
<b>Steps to produce :</b> 1) Install 10n_de_reports and switch to the German company 2) Create a journal entry from accounting with a credit and debit 3) Now update the credit and debit to a different value. 4) Post the journal 5) Go to "Accounting / Reporting / Audit Reports / General Ledger" 6) Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv" <b>Issue:</b> The line for the created journal entry has a price_total of the previous balance even after updating the credit and debit values. <b>Cause:</b> When the user updates the 'debit' and 'credit' values for an `aml`, The `price_totals` value remains unchanged as it is not dependent on `balance`. So, it will show the previous value in the report line because we are taking the abs(aml.price_total) from the report data. <b>Solution:</b> We can add an extra check of the move type so that it will fall back to the else block, where the line_amount will take a value by calculating taxes from `aml.tax_ids.compute_all`. opw-4707567 Forward-Port-Of: odoo/enterprise#85436 Forward-Port-Of: odoo/enterprise#83777
This mostly benefits `test_balance_sheet_balanced` as it mass activates reports on every `_set_up_localization` (so before rendering each report, something it does ~200 times). Forward-Port-Of: odoo/enterprise#88115
Original PR description
This mostly benefits `test_balance_sheet_balanced` as it mass activates reports on every `_set_up_localization` (so before rendering each report, something it does ~200 times). Forward-Port-Of: odoo/enterprise#88115
Issue / current behavior: In the gantt view of hr.attendance, the no content help screen will only show if there's no rows. In the case of a fresh database with only the Administrator employee, the help will not appear because the admin row exists by default. Required behavior: The gantt view should show the no content help screen if recordIds inside the single row is empty, meaning that there's no hr.attendance records. task-4874129 Forward-Port-Of: odoo/enterprise#87874
Original PR description
Issue / current behavior: In the gantt view of hr.attendance, the no content help screen will only show if there's no rows. In the case of a fresh database with only the Administrator employee, the help will not appear because the admin row exists by default. Required behavior: The gantt view should show the no content help screen if recordIds inside the single row is empty, meaning that there's no hr.attendance records. task-4874129 Forward-Port-Of: odoo/enterprise#87874
In this commit we remove checkDelay from codebase because it is no longer used since https://github.com/odoo/odoo/pull/194508 has been merged. Forward-Port-Of: odoo/enterprise#84148 Forward-Port-Of: odoo/enterprise#83217
Original PR description
In this commit we remove checkDelay from codebase because it is no longer used since https://github.com/odoo/odoo/pull/194508 has been merged. Forward-Port-Of: odoo/enterprise#84148 Forward-Port-Of: odoo/enterprise#83217
**Current behavior:** A user who can otherwise use the entire mps can not add 'rows' to the view (i.e., write on `ResCompany` `mrp_mps` fields). **Expected behavior:** Can add rows to the MPS. **Steps to reproduce:** 1. Install `mrp_mps` with demo data 2. Edit "Demo" user access rights so they only have the mrp manager group 3. Open MPS -> click `Rows` dropdown (under search bar) and add/remove one -> access error **Cause of the issue:** Field is on `ResCompany` and the MPS us
Original PR description
**Current behavior:** A user who can otherwise use the entire mps can not add 'rows' to the view (i.e., write on `ResCompany` `mrp_mps` fields). **Expected behavior:** Can add rows to the MPS. **Steps to reproduce:** 1. Install `mrp_mps` with demo data 2. Edit "Demo" user access rights so they only have the mrp manager group 3. Open MPS -> click `Rows` dropdown (under search bar) and add/remove one -> access error **Cause of the issue:** Field is on `ResCompany` and the MPS user can't write to that model. **Fix:** Permit writes on `ResCompany` `mrp_mps` fields if they are on an mps field and the user has the mrp manager group. opw-4591655 Forward-Port-Of: odoo/enterprise#87871 Forward-Port-Of: odoo/enterprise#80881
Steps to reproduce: - Open Follow-up levels for 15 days -Check the option for “Automatic” - Go to the email template set in the “Content Template” and set a test email in the CC of the email configuration. - Open the follow up reports for a sample customer who is in the “15 days” stage and change the next reminder date to be a day before today. The reminder must be set to automatic. - There will appear a red ribbon on the right corner that says “In need of action” - In another tab, open sch
Original PR description
Steps to reproduce: - Open Follow-up levels for 15 days -Check the option for “Automatic” - Go to the email template set in the “Content Template” and set a test email in the CC of the email…
Steps to reproduce: - Open Follow-up levels for 15 days -Check the option for “Automatic” - Go to the email template set in the “Content Template” and set a test email in the CC of the email configuration. - Open the follow up reports for a sample customer who is in the “15 days” stage and change the next reminder date to be a day before today. The reminder must be set to automatic. - There will appear a red ribbon on the right corner that says “In need of action” - In another tab, open scheduled actions and Open the action “Account Report Followup; Execute followup” - Run this action manually Issue: Go to the previous tab and notice that the email is only sent out to the customer partner record and not the cc email address Note: This issue only occurs if the automatic followup is set. If we try to manually followup by clicking on the “Follow Up” button on the customer report, the email is sent correctly to both addresses. Cause: When running the cron, the recipients aren't in the options Solution: Add an helper to find all necessary recipients from the template if no recipient ids in the options opw-4527398 Forward-Port-Of: odoo/enterprise#87014 Forward-Port-Of: odoo/enterprise#83944
Currently, an error occurs when finding duplicate transactions in the bank. Steps to Reproduce: - Install the `accountant` module. - In `Accounting Dashboard`, click on `Bank`. - In Actions, click `Find Duplicate Transactions`. - Clear the `Starting Date` field and click save. `TypeError: unsupported operand type(s) for -: 'bool' and 'relativedelta'` This error occurs when the system attempts to find duplicate transactions without a Starting Date. When finding duplicate transa
Original PR description
Currently, an error occurs when finding duplicate transactions in the bank. Steps to Reproduce: - Install the `accountant` module. - In `Accounting Dashboard`, click on `Bank`. - In Actions, click…
Currently, an error occurs when finding duplicate transactions in the bank. Steps to Reproduce: - Install the `accountant` module. - In `Accounting Dashboard`, click on `Bank`. - In Actions, click `Find Duplicate Transactions`. - Clear the `Starting Date` field and click save. `TypeError: unsupported operand type(s) for -: 'bool' and 'relativedelta'` This error occurs when the system attempts to find duplicate transactions without a Starting Date. When finding duplicate transactions, it tries to calculate the `prior_date` using `date_from - relativedelta(months=3)` [1]. However, since `date_from` is `False`, this raises an error. [1] https://github.com/odoo/enterprise/blob/acdba5ecf89ee8920f82e07e16fac2a0f9659b12/account_online_synchronization/models/account_journal.py#L314 This commit ensures that if the Starting Date is empty when finding duplicate transactions, it uses today’s date as the Starting Date. sentry-6653835511 Forward-Port-Of: odoo/enterprise#87000
Before this commit, when a recurring order_line had an invoice_policy "order" and the quantity was 0, it would be added to the invoice. taskid: 4841550 Forward-Port-Of: odoo/enterprise#87990 Forward-Port-Of: odoo/enterprise#86870
Original PR description
Before this commit, when a recurring order_line had an invoice_policy "order" and the quantity was 0, it would be added to the invoice. taskid: 4841550 Forward-Port-Of: odoo/enterprise#87990 Forward-Port-Of: odoo/enterprise#86870