Monday, June 2, 2025
37 changes · saas-18.3
Resolved issues and error corrections
The live chat dashboard once again sorts agents by the number of chats they handle. This restores the intended ranking so managers can quickly see the most active agents without manually comparing data.
Original PR description
The "nbr_channel" measure was recently removed from the livechat report channel model. During this change, the agents are not sorted by number of chats in the dashboard. This PR fixes this issue. 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 calendar view now adjusts its size without fully reloading when its surrounding layout changes. This reduces unnecessary work and helps keep the calendar experience smoother for users.
Original PR description
This commit optimize a previous fix as in this fix we always rerender the FullCalendar when the parent's sizing element was changed, but it's not optimal as we can call `updateSize` instead of `render`. Doc: > render > Will initially render a calendar, or if it is already rendered, will rerender it. > > --- > updateSize > Immediately forces the calendar to readjusts its size. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the project dashboard from crashing when a vendor bill linked to a project has its analytic details removed. Users can continue viewing project profitability information without encountering an error in this purchase-related workflow.
Original PR description
When user tries to open the dashboard of project, A traceback will appear. Steps to reproduce the error: - Install ``sale_management``, ``project_purchase`` and ``accountant`` modules - Go to…
When user tries to open the dashboard of project,
A traceback will appear.
Steps to reproduce the error:
- Install ``sale_management``, ``project_purchase`` and ``accountant`` modules
- Go to Settings > Enable Analytic Accounting
- Create Project A > Billable: True > Go to Settings >
Select any analytic account in project(account_id)
- Make sure that bills are available
- Create A new PO > add any product > Other Information > Project: Project A >
Confirm Order > Bill Matching > Select a line > Match > Bill will be created
- Remove Analytic from Invoice Lines of the bill
- Go to Project > click on dropdown menu of Project A > Dashboard
Traceback:
```
File "/home/odoo/src/odoo/addons/project_purchase/models/project_project.py", line 161, in _get_profitability_items
percentage for ids, percentage in line.analytic_distribution.items()
AttributeError: 'bool' object has no attribute 'items'
```
https://github.com/odoo/odoo/blob/9cebb8c23d66a6aadd06bf0d806c65b67dc13ae7/addons/project_purchase/models/project_project.py#L161
When a user removes the analytic from the invoice lines of a bill,
``line.analytic_distribution`` becomes False,
So, It will lead to the above traceback.
sentry-6638122973
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update makes an automated accounting test more stable by avoiding a changing field identifier and waiting for the amount field to be ready. It helps reduce false build failures, improving confidence in release validation without changing user-facing behavior.
Original PR description
The `account_accountant_tour` test was failing at the step that attempts to set an amount, due to the selector `input[id=amount_0]` not being found within the timeout. The root cause was that the selector used an ID (`amount_0`) which is dynamically generated and can change across test runs . To resolve this, the selector was replaced with a more stable one: `div[name=amount] input`, which targets the same field but does not rely on dynamic IDs. Additionally, a no-op wait step was introduced immediately before this interaction to ensure the DOM has fully rendered the input element before the test proceeds. build_error-220890
This fixes an error that could occur when searching or grouping documents by last access date with empty values. The change helps prevent unexpected failures in the Documents app and keeps document filtering more reliable.
Original PR description
…n values. A small error was been made in https://github.com/odoo/enterprise/pull/76079 (`_search_last_access_date_group`): the SQL string contains a %s without an argument, resulting in a "TypeError: not enough arguments for format string." Fix it. A test will be added later to the master branch in a later PR that found the issue https://github.com/odoo/odoo/pull/133224. https://github.com/odoo/odoo/pull/212115
Closing an AI agent chat box no longer causes an error when the chat has not been linked to a conversation. This prevents an unexpected crash and gives users a smoother experience in the AI module.
Original PR description
The system will crash because `AIAgent.close_chat()` requires a `channel_id`, and if `component.thread?.id` is undefined, it results in a missing argument error.
**Steps to Produce:-**
1. Install the `AI` module.
2. Navigate to the AI module. If an agent is already present, click on it. Otherwise, create a new agent.
3. Click on the agent to open the chat box.
4. Close the chat.
**Error:-**
`TypeError: AIAgent.close_chat() missing 1 required positional argument: 'channel_id'`
**Solution:-**
- Check that `component.thread.id` is present before calling
`AIAgent.close_chat`.
**Sentry : 6388425767**Fixes an issue where grouping account records by placeholder code could fail with an error. This helps users view and analyze accounting data more reliably in grouped lists and reports.
Original PR description
The web client considers the `account.account.placeholder_code` field to be groupable since there is an implementation inside _field_to_sql. However, grouping by this field results in a NotImplementedError because the search method doesn't implement equality. Equality is necessary because since the '__extra_domain' returned from `formatted_read_group` contains a leaf, such as `('placeholder_code', '=', ...)`.
Add the equality implementation to the search method. A test will be added later to the master branch in a later PR that found the issue https://github.com/odoo/odoo/pull/133224.
https://github.com/odoo/enterprise/pull/86626This fixes an issue in the website shop onboarding tour so users can complete the guided setup as expected. It helps new or configuring users follow the intended flow without getting blocked or confused.
This fixes failing Sales test checks when Odoo is built with only selected apps enabled. It helps keep automated validation reliable without changing the Sales experience for users.
Original PR description
runbot_error-161629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this commit, when the user clicks on `Make Billable` stat button displayed in the project form view when there is not yet any SO set on that project and directly confirm the SO, a user error is raised because the SO is already confirmed after executing confirm action of that button clicked. The reason is because in that case, the SO is automatically confirmed during the creation of that SO which means the action_confirm could be called 2 times in that use case, one during the save (creati
Original PR description
Before this commit, when the user clicks on `Make Billable` stat button displayed in the project form view when there is not yet any SO set on that project and directly confirm the SO, a user error…
Before this commit, when the user clicks on `Make Billable` stat button displayed in the project form view when there is not yet any SO set on that project and directly confirm the SO, a user error is raised because the SO is already confirmed after executing confirm action of that button clicked. The reason is because in that case, the SO is automatically confirmed during the creation of that SO which means the action_confirm could be called 2 times in that use case, one during the save (creation) and another one because the user clicks on `Confirm` button. This commit makes sure the action_confirm does nothing if the SO is already confirmed and we are in the context in which the user creates the SO via the stat button in project. Steps to reproduce ------------------ 0. install sale_project or sale_timesheet modules 1. Go to Projects > Confirmation > Projects 2. Click on `New` button to create a new project 3. Enable `Billable` feature if it is not already the case by default 4. Add a customer to the project 5. Click on `Make Billable` stat button 6. Add a service product on the SO to create 7. Click on `Confirm` button. Expected behavior ----------------- The SO should be created and confirmed without any issues Current Behavior ---------------- A user error is raised because the SO is already confirmed before executing the action for the button clicked. task-4781751 Forward-Port-Of: odoo/odoo#211137 Forward-Port-Of: odoo/odoo#209259
runbot-error-108129 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#212509
Original PR description
runbot-error-108129 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#212509
Steps: ------ 1. Create a combo product and make it available in restaurant 2. In PoS, add this product to an order 3. Click the product line, and set the quantity to 2 let's 4. Click split button, it takes you to the split screen Observation: We can not select one of these 2 combos to split, it's either all of them, or none. Reason: ------- That's because combos are considered as non groupable in pos, see `is_pos_groupable` [1]. And then, when splitting a combo in `_splitQuantity`
Original PR description
Steps: ------ 1. Create a combo product and make it available in restaurant 2. In PoS, add this product to an order 3. Click the product line, and set the quantity to 2 let's 4. Click split button,…
Steps: ------ 1. Create a combo product and make it available in restaurant 2. In PoS, add this product to an order 3. Click the product line, and set the quantity to 2 let's 4. Click split button, it takes you to the split screen Observation: We can not select one of these 2 combos to split, it's either all of them, or none. Reason: ------- That's because combos are considered as non groupable in pos, see `is_pos_groupable` [1]. And then, when splitting a combo in `_splitQuantity` [2], we either take all the quantity or 0. Fix: ---- We update the split logic to account for special combo cases. [1]: https://github.com/odoo/odoo/blob/bee8b55d7783ea11f2362990cd9d7695b877b8e9/addons/point_of_sale/static/src/app/store/models.js#L829 [2]: https://github.com/odoo/odoo/blob/bee8b55d7783ea11f2362990cd9d7695b877b8e9/addons/pos_restaurant/static/src/app/split_bill_screen/split_bill_screen.js#L124-L127 opw-4737788 Forward-Port-Of: odoo/odoo#209036 Forward-Port-Of: odoo/odoo#208055
Description ----------- Upon importing contracts, in `_recompute_work_entries`, a wizard is created where we set the employee and a timeframe. The field `employee_ids` is a stored `Many2many` and upon reading its content, an active test is performed in `convert_to_record`, meaning that if the employee is archived, reading `employee_ids` would yield `[]`. This is problematic in `regenerate_work_entries` which therefore will search and write on *all* work entries in the timeframe, since readi
Original PR description
Description ----------- Upon importing contracts, in `_recompute_work_entries`, a wizard is created where we set the employee and a timeframe. The field `employee_ids` is a stored `Many2many` and upon reading its content, an active test is performed in `convert_to_record`, meaning that if the employee is archived, reading `employee_ids` would yield `[]`. This is problematic in `regenerate_work_entries` which therefore will search and write on *all* work entries in the timeframe, since reading `employee_ids` returns an empty list -> all employees. This commit adds a context key to take archived records when regenerating work entries. Reference --------- opw-4813590 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212117 Forward-Port-Of: odoo/odoo#211748
Steps to reproduce ================== - Use a mobile device/viewport - Go to any record with a chatter - Click on Log note - Expand the composer - Click on the template dropdown - Save the current content as a template with a long name - Open the dropdown again => The dropdown is almost entirely off screen Cause of the issue ================== The Dropdown component uses the usePosition hook. It works by doing the following: - It tries the fit the content using the position
Original PR description
Steps to reproduce ================== - Use a mobile device/viewport - Go to any record with a chatter - Click on Log note - Expand the composer - Click on the template dropdown - Save the current content as a template with a long name - Open the dropdown again => The dropdown is almost entirely off screen Cause of the issue ================== The Dropdown component uses the usePosition hook. It works by doing the following: - It tries the fit the content using the position props (or it's default value) - If it doesn't fit, it tries the four other corners - If it's still doesn't fit, it gives up and uses the first one again Solution ======== Since we cannot show too much content inside a dropdown, we set a max-width on the dropdown content, and truncate the template names. Another possibility would be to allow an horizontal overflow. opw-4675320 opw-4674341 opw-4656725 Forward-Port-Of: odoo/odoo#211143 Forward-Port-Of: odoo/odoo#208383
**Current behavior before PR:** Link Preview is deletable for only editable messages **Desired behavior after PR is merged:** Link Preview will be deletable for all messages task-[4690326](https://www.odoo.com/odoo/all-tasks/4690326) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212488 Forward-Port-Of: odoo/odoo#208828
Original PR description
**Current behavior before PR:** Link Preview is deletable for only editable messages **Desired behavior after PR is merged:** Link Preview will be deletable for all messages task-[4690326](https://www.odoo.com/odoo/all-tasks/4690326) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212488 Forward-Port-Of: odoo/odoo#208828
## Description of the issue/feature this PR addresses: This PR is about fixing this issue: https://github.com/odoo/odoo/issues/182777 to avoid SMTPServerDisconnected ## Current behavior before PR: With some race condition got SMTPServerDisconnected ## Desired behavior after PR is merged: Do not get SMTPServerDisconnected while quitting non connect session and avoid to get non connected session using google oauth2 connection. --- I confirm I have signed the CLA and read the P
Original PR description
## Description of the issue/feature this PR addresses: This PR is about fixing this issue: https://github.com/odoo/odoo/issues/182777 to avoid SMTPServerDisconnected ## Current behavior before PR: With some race condition got SMTPServerDisconnected ## Desired behavior after PR is merged: Do not get SMTPServerDisconnected while quitting non connect session and avoid to get non connected session using google oauth2 connection. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212336 Forward-Port-Of: odoo/odoo#182817
Scenario: add a mega menu, in mobile scroll to not be at top of page, and click to open hamburger menu then click to open mega menu content. Result: the mega menu is mostly shown thanks to 579160b08c6e73d809be79f561214118f1284532 but a small part at the bottom is inaccessible. Reason: the height needs to take into account the margin bottom so it can be shown fully on the page. Fix: add a calc to remove the height of the margin-top. opw-4737577 opw-4737823 opw-4738673 __PR NO
Original PR description
Scenario: add a mega menu, in mobile scroll to not be at top of page, and click to open hamburger menu then click to open mega menu content. Result: the mega menu is mostly shown thanks to…
Scenario: add a mega menu, in mobile scroll to not be at top of page,
and click to open hamburger menu then click to open mega menu content.
Result: the mega menu is mostly shown thanks to
579160b08c6e73d809be79f561214118f1284532 but a small part at the bottom
is inaccessible.
Reason: the height needs to take into account the margin bottom so it
can be shown fully on the page.
Fix: add a calc to remove the height of the margin-top.
opw-4737577
opw-4737823
opw-4738673
__PR NOTE__: I'm not sure if all browser support of using calc with different units (maybe I'm confusing it with some less calculation), if the solution was not acceptable for that, the only other way I see to solve this, would be to put "position: relative" to the `#top_menu_collapse_mobile .offcanvas-body` element and let the mega menu take the whole space, i.e. something like that:
```diff
diff --git a/addons/website/static/src/scss/website.scss b/addons/website/static/src/scss/website.scss
index 16fdd05e006f..05c9dbbc88cd 100644
--- a/addons/website/static/src/scss/website.scss
+++ b/addons/website/static/src/scss/website.scss
@@ -1629,6 +1629,9 @@ header {
}
// Offcanvas mega menu on mobile or in sidebar/hamburger header
+#top_menu_collapse_mobile .offcanvas-body {
+ position: relative;
+}
.o_mega_menu_is_offcanvas {
.o_mega_nav, .o_mega_menu {
@include transition(opacity $offcanvas-transition-duration ease-in-out, visibility $offcanvas-transition-duration ease-in-out);
@@ -1664,7 +1667,6 @@ header {
inset: 0 0 0 auto !important;
display: block;
visibility: hidden;
- margin-top: $o-mega-menu-nav-height !important;
border: none;
max-height: 100vh;
background-color: o-color('menu-custom') or o-color('menu');
```
Forward-Port-Of: odoo/odoo#207013Currently, an error occurs when the replenish wizard is unable to find the default 'Buy' route, which the user may have deleted. Steps to produce: - Install the `purchase_stock` module. - Activate `Multi-Step Routes` from Settings. - Navigate to `Inventory > Configuration > Warehouse Management > Routes (list)`. - Delete the `Buy` route record. - Create a new product without adding vendors or defining routes. - Click on the `Replenish` button. - Observe the error. `AttributeError: '
Original PR description
Currently, an error occurs when the replenish wizard is unable to find the default 'Buy' route, which the user may have deleted. Steps to produce: - Install the `purchase_stock` module. - Activate…
Currently, an error occurs when the replenish wizard is unable to find the default 'Buy' route, which the user may have deleted. Steps to produce: - Install the `purchase_stock` module. - Activate `Multi-Step Routes` from Settings. - Navigate to `Inventory > Configuration > Warehouse Management > Routes (list)`. - Delete the `Buy` route record. - Create a new product without adding vendors or defining routes. - Click on the `Replenish` button. - Observe the error. `AttributeError: 'NoneType' object has no attribute 'id'` The issue occurs when attempting to access the `id` of the 'Buy' route `purchase_stock.route_warehouse0_buy` - [1], without verifying if it exists. If this route is missing, `self.env.ref(...)` returns `None` which leads to an `AttributeError`. This commit resolves the issue by checking whether the `purchase_stock.route_warehouse0_buy` route exists before attempting to access its `id`. This prevents errors when the route is missing. [1] - https://github.com/odoo/odoo/blob/58f4b01dda6ba2e67c21663399aab1c189f4a312/addons/purchase_stock/wizard/product_replenish.py#L108 Sentry-6275025957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196959
Added `no_create` option to the `pos_rounding_method` field to enforce use of predefined `cash.rounding.method` form, avoiding bypass of required Profit & Loss accounts setup (which cause some issue when trying to cash in/out in POS or when trying to close the session). task-id: 4805617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211403
Original PR description
Added `no_create` option to the `pos_rounding_method` field to enforce use of predefined `cash.rounding.method` form, avoiding bypass of required Profit & Loss accounts setup (which cause some issue when trying to cash in/out in POS or when trying to close the session). task-id: 4805617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211403
Before this commit, if a user is typing without interrupt for more than 1 minute, other members stop seeing this person from about 40 seconds. As a reminder, the "is typing..." feature in discuss is implemented as follow: - when typing, notify `is_typing: true` once every 50 seconds. - when stop typing for 5 seconds, notify `is_typing: false`. - other members assume stop typing if nothing received after 60 seconds. This logic is good, but there was a problem with current implementation:
Original PR description
Before this commit, if a user is typing without interrupt for more than 1 minute, other members stop seeing this person from about 40 seconds. As a reminder, the "is typing..." feature in discuss is…
Before this commit, if a user is typing without interrupt for more than 1 minute, other members stop seeing this person from about 40 seconds. As a reminder, the "is typing..." feature in discuss is implemented as follow: - when typing, notify `is_typing: true` once every 50 seconds. - when stop typing for 5 seconds, notify `is_typing: false`. - other members assume stop typing if nothing received after 60 seconds. This logic is good, but there was a problem with current implementation: members only send and receive `isTyping: true` through `mail.record/insert` notification. This means a long typer is seen as follow ``` - time: 0sec. -> is_typing: true sent + received - time: 50sec. -> is_typing: true sent + received - time: 60sec. -> is_typing: false (assuming stop typing) - time: 100sec. -> is_typing: true sent + received ``` This is the case because the notification is `mail.record/insert` so from the store data, data of `isTyping` is unchanged. The timeout was made through a change of `isTyping` status, which doesn't in this scenario, hence the problem of assuming stop typing. This commit fixes the issue by sending the datetime of notified `is_typing` and linking the timeout to the datetime of last notified of `is_typing` of this member. This fix ensures that at the 50sec, the timeouts are refreshed and they have to wait until time 110sec. to assume stop typing, which is good in case the message is very long as typer will warn again at time 100sec. with refreshed datetime. runbot-223760 Forward-Port-Of: odoo/odoo#212422 Forward-Port-Of: odoo/odoo#211961
### Before this PR The PUSH notifications on Edge PWA are not working. This is caused by the TTL 0 . Edge PUSH are not working if TTL 0 is used. ### After This PR I set the TTL to 1. It is a tricky way to make it work on Edge and also other browser. It is 1 seconds instead of 0(that means only if the browser is connected) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211074 Forward-Port-Of: odoo/odoo#199943
Original PR description
### Before this PR The PUSH notifications on Edge PWA are not working. This is caused by the TTL 0 . Edge PUSH are not working if TTL 0 is used. ### After This PR I set the TTL to 1. It is a tricky way to make it work on Edge and also other browser. It is 1 seconds instead of 0(that means only if the browser is connected) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211074 Forward-Port-Of: odoo/odoo#199943
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/odoo#211296 Forward-Port-Of: odoo/odoo#127190
**Before this PR:** The button label in the popup does not update when a user tries to edit a review. **Technical**- The button label updates only during the widget initialization, as it is handled in the willStart function. https://tinyurl.com/2derk498 **After this PR:** The button label in the popup correctly updates to 'Update Review' when a user edits a review. **Task**-4677251 Forward-Port-Of: odoo/odoo#212164 Forward-Port-Of: odoo/odoo#211417
Original PR description
**Before this PR:** The button label in the popup does not update when a user tries to edit a review. **Technical**- The button label updates only during the widget initialization, as it is handled in the willStart function. https://tinyurl.com/2derk498 **After this PR:** The button label in the popup correctly updates to 'Update Review' when a user edits a review. **Task**-4677251 Forward-Port-Of: odoo/odoo#212164 Forward-Port-Of: odoo/odoo#211417
**Before this PR:** When a user attempts to add a review, the label on the "Review tab" doesn't update, and the portal chatter fails to display the review message. https://youtu.be/H1XRamn9Koc **Technical:** The code related to these features was removed in commit 368eb78a9cedfce0802b64fd2782e1c018541e40, but it was never addressed afterward. **After this PR:** Adding a review updates the tab label and displays the message in portal chatter. **Task**-4677251 Forward-Port-Of: odoo/
Original PR description
**Before this PR:** When a user attempts to add a review, the label on the "Review tab" doesn't update, and the portal chatter fails to display the review message. https://youtu.be/H1XRamn9Koc **Technical:** The code related to these features was removed in commit 368eb78a9cedfce0802b64fd2782e1c018541e40, but it was never addressed afterward. **After this PR:** Adding a review updates the tab label and displays the message in portal chatter. **Task**-4677251 Forward-Port-Of: odoo/odoo#212081 Forward-Port-Of: odoo/odoo#207242
The `all_l10n` standalone test started to fail on 2025-06-01 when installing `l10n_in_hr_payroll`. Forward-Port-Of: odoo/odoo#212500
Original PR description
The `all_l10n` standalone test started to fail on 2025-06-01 when installing `l10n_in_hr_payroll`. Forward-Port-Of: odoo/odoo#212500
Required for fixes in 18.0+ branches Forward-Port-Of: odoo/odoo#212403
Original PR description
Required for fixes in 18.0+ branches Forward-Port-Of: odoo/odoo#212403
## opw-4812933 feedback > When attachments were exported from Studio Export, they got exported in descending order by id (from highest id to lowest id). This caused a problem during import: if an attachment referred to an earlier one using a "Resource ID" (meaning it depended on a previously created attachment), the dependent attachment would try to import before the one it needed. This led to an error because the referenced attachment didn't exist yet. ## found issue The exported data
Original PR description
## opw-4812933 feedback > When attachments were exported from Studio Export, they got exported in descending order by id (from highest id to lowest id). This caused a problem during import: if an attachment referred to an earlier one using a "Resource ID" (meaning it depended on a previously created attachment), the dependent attachment would try to import before the one it needed. This led to an error because the referenced attachment didn't exist yet. ## found issue The exported data is sorted to ensure import order is correct, but for inter-record dependencies on a same model many2one_reference fields are not taken into account. This PR fixes that. Also while analyzing this issue another small issue was spotted regarding base.automation.url field. See commits. Forward-Port-Of: odoo/enterprise#86407 Forward-Port-Of: odoo/enterprise#86204
The `all_l10n` standalone test started to fail on 2025-06-01 when installing `l10n_in_hr_payroll`. A first attempt was made to blacklist the module in the test itself. This attemps failed as the module is auto_install on `hr_payroll` and most of `l10n_hr*` modules depend on `hr_payroll`. Forward-Port-Of: odoo/enterprise#86758
Original PR description
The `all_l10n` standalone test started to fail on 2025-06-01 when installing `l10n_in_hr_payroll`. A first attempt was made to blacklist the module in the test itself. This attemps failed as the module is auto_install on `hr_payroll` and most of `l10n_hr*` modules depend on `hr_payroll`. Forward-Port-Of: odoo/enterprise#86758
The "Fetch from CodaBox" link displayed on the accounting dashboard had no gap between it and the button at the left of it, and wasn't aligned horizontaly with the other buttons next to it making it look out of place. It is now displayed as a link button, which solve both problems. task-4671468 Purpose The fetch from CodaBox is too sticky to the upload button  After this commit :  After this commit :  Forward-Port-Of: odoo/enterprise#84858
Fix qty_delivered when a rental order is processed through the PoS. This commit ensure that the PoS qty_delivered computation is done after the other calculation Steps to reproduce: ------------------- * Make a rental for 1 product * Open the sale order in PoS * Pay for the rental > Observation: The qty_delivered is set to 2 instead of 1 on the rental Why the fix: ------------ When the order is a rental processed through the PoS, we recompute the rental qty and add the PoS quantity
Original PR description
Fix qty_delivered when a rental order is processed through the PoS. This commit ensure that the PoS qty_delivered computation is done after the other calculation Steps to reproduce: ------------------- * Make a rental for 1 product * Open the sale order in PoS * Pay for the rental > Observation: The qty_delivered is set to 2 instead of 1 on the rental Why the fix: ------------ When the order is a rental processed through the PoS, we recompute the rental qty and add the PoS quantity to make sure that the value is correct. The computation is actually just the fusion of the PoS and rental _compute_qty_delivered methods. opw-4582505 Forward-Port-Of: odoo/enterprise#86266 Forward-Port-Of: odoo/enterprise#84768
Needed internally where the cart is not always in the company of the website. Forward-Port-Of: odoo/enterprise#86236
Original PR description
Needed internally where the cart is not always in the company of the website. Forward-Port-Of: odoo/enterprise#86236
How to reproduce: - Install document in v17.0 with demo data - In the kanban view, upload an image in Marketing folder - The image is displayed as thumbnail in the kanban card - Upgrade to saas-17.4 - Open Document and go to marketing folder There is no thumbnail for the uploaded image. In v17, _compute_thumbnail_status write a False status when the thumbnail is updated because when it is trigerred the attachment is not yet created. So the thumbnail is present but its status is inco
Original PR description
How to reproduce: - Install document in v17.0 with demo data - In the kanban view, upload an image in Marketing folder - The image is displayed as thumbnail in the kanban card - Upgrade to saas-17.4…
How to reproduce: - Install document in v17.0 with demo data - In the kanban view, upload an image in Marketing folder - The image is displayed as thumbnail in the kanban card - Upgrade to saas-17.4 - Open Document and go to marketing folder There is no thumbnail for the uploaded image. In v17, _compute_thumbnail_status write a False status when the thumbnail is updated because when it is trigerred the attachment is not yet created. So the thumbnail is present but its status is incorrect. It works in v17 because the status is ignored by the view for images but in v17.4, the status is not ignored and the thumbnail is then not displayed. This temporary fix allows already migrated user to see thumbnail (as the view could not be modified in stable without an upgrade). We force the status of the thumbnail to "present" when there is no status for a thumbnail of an image which should cover the case where the status was not updated after the thumbnail creation. We have chosen this solution as the thumbnail will be updated in the upgrade and the URL returns anyway a placeholder image if the image is not present. We modify some tests to check that the patch is applied. As the kanban test data includes an image with a False status, the patch turns automatically the status to "present". So instead of having the generic mime type thumbnail, we get the actual thumbnail of the image. We change the assertions accordingly to test the new behavior and test the generic mime type thumbnail in the pdf case of the test "document inspector: document preview". Task-4642866 Forward-Port-Of: odoo/enterprise#85751 Forward-Port-Of: odoo/enterprise#81558
Update on the filterExchangeRate function. The text input allowed users to enter non-numeric characters, which led to float conversion errors during processing. Now we parse the string into a float, catch errors and notify the user that the number was not valid. It also enables the user to use the thousands and decimal separators based on the language of the user. opw-4788246 Forward-Port-Of: odoo/enterprise#85857
Original PR description
Update on the filterExchangeRate function. The text input allowed users to enter non-numeric characters, which led to float conversion errors during processing. Now we parse the string into a float, catch errors and notify the user that the number was not valid. It also enables the user to use the thousands and decimal separators based on the language of the user. opw-4788246 Forward-Port-Of: odoo/enterprise#85857
<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#83777
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/enterprise#86240 Forward-Port-Of: odoo/enterprise#43574
Since we only update the fiscal positions for newly created taxes, there is nothing to update in the mapping when nothing will be created. upg-2769042 Forward-Port-Of: odoo/odoo#207700
Original PR description
Since we only update the fiscal positions for newly created taxes, there is nothing to update in the mapping when nothing will be created. upg-2769042 Forward-Port-Of: odoo/odoo#207700
- Updated UK localization template handling to avoid automatic recreation of accounts, taxes, and fiscal positions when upgrading. - Added `force_create = "0"` parameter to `try_loading` to ensure that existing configurations are retained and no new records are created unless explicitly required. - Fixed a similar issue for all impacted localizations, following the discussion in the previous task (https://www.odoo.com/odoo/project/967/tasks/4556250). task-4712602 Description of the issue
Original PR description
- Updated UK localization template handling to avoid automatic recreation of accounts, taxes, and fiscal positions when upgrading. - Added `force_create = "0"` parameter to `try_loading` to ensure that existing configurations are retained and no new records are created unless explicitly required. - Fixed a similar issue for all impacted localizations, following the discussion in the previous task (https://www.odoo.com/odoo/project/967/tasks/4556250). task-4712602 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#205211