Thursday, February 27, 2025
40 changes · 18.0
Enhancements to existing features
Task Adhoc side: 44224 Update l10n_ar_withholding translations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Task Adhoc side: 44224 Update l10n_ar_withholding translations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Long website names now display more cleanly in the website selector, systray item, and analytics page button. This prevents oversized names from disrupting the interface by shortening them neatly with an ellipsis.
Original PR description
This commit enhances the display of the website name in the dropdown menu and the website systray item by utilizing the `text-truncate` class to manage long names more effectively. task-4069591
Users exporting Dutch SBR tax reports now receive a clear warning and a link to Accounting settings when the required certificate or key is missing. This prevents an unexpected error screen and helps users quickly fix the configuration before exporting.
Original PR description
This PR adds a redirect warning sending the user to the Accounting settings when the certificate or the key is missing before an xbrl export to avoid a traceback and give a friendlier feedback to the user. --- linked to opw-4563442
Update l10n_ar_reports and l10n_uy_edi translations. Task Adhoc side: 44224
Original PR description
Update l10n_ar_reports and l10n_uy_edi translations. Task Adhoc side: 44224
Resolved issues and error corrections
This fix ensures that documents selected for a sales PDF quote remain available when preparing or generating the quote. It helps sales teams avoid missing attachments or incomplete customer-facing quotation packages.
Original PR description
opw-4464701
Miscellaneous changes
This commit fixes an issue where the partner assigned to a booth could be incorrect based on the provided email. Indeed, we don't want to assign an existing partner when non-logged, as it could conflict when trying to checkout the order and providing another one. In addition, it just does not make much sense. Instead we now suggest to login before booking your booths. Task-4163951 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior a
Original PR description
This commit fixes an issue where the partner assigned to a booth could be incorrect based on the provided email. Indeed, we don't want to assign an existing partner when non-logged, as it could conflict when trying to checkout the order and providing another one. In addition, it just does not make much sense. Instead we now suggest to login before booking your booths. Task-4163951 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#198670 Forward-Port-Of: odoo/odoo#179083
The website shop test was adjusted to match the updated version 18 Buy Now behavior, which now sends shoppers to the cart instead of directly to payment. This helps keep automated checks reliable without changing the customer-facing shopping experience.
Original PR description
Before this commit: This test was ignored by the runbot platform as the test was consistently failing. Starting version 18, the flow of the "Buy Now" button did change to redirect to the card after being pressed rather than the payment page as intended in the PR: https://github.com/odoo/odoo/pull/149020 After this commit: Remove irelevant part of the test to make it successful rb-56459
Fixes the chat call participant card so users on smaller screens can drag and reposition it correctly. The card is also moved slightly upward so it no longer covers the End Call button, making calls easier to control.
Original PR description
**Before this PR:** - Users could not drag and drop the call participant card in the chat window due to incorrect position computations. - Participant card was positioned at bottom right, causing the "End Call" button to be hidden behind it. **This PR:** - Fixes the drag-and-drop issue by correcting the position calculations. - Adds 5vh bottom offset for card so it doesn't overlap "End Call" button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that pressing Ctrl + K still opens the command palette even when the user is focused on a chat window. It restores a consistent keyboard shortcut experience and avoids confusion for users who rely on quick navigation.
Original PR description
**Current behavior before PR**: Pressing Ctrl + K while focused on the chat window did not open the command palette, as the event was captured by the chat window and prevented from propagating further. **Desired behavior after PR is merged**: Ctrl + K is now properly handled when the chat window is focused, allowing the command palette to open as expected. task-id:4593364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The purchase portal no longer shows a message or button promoting UBL purchase order imports unless the UBL module is installed. This avoids confusing users with an option they cannot actually use.
Original PR description
The text advertising the UBL functionality is in purchase rather than in the UBL module itself. This way if someone have purchase but not UBL, which is the actual case in internal, one will see a button on how to import the PO when he actually can't. This PR makes the button in the portal PO view invisible and set it visible in an inherited view that is created once the UBL module is installed, preventing this way the message to display when it should not opw-4465049 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 export wizard now hides External ID fields when they cannot actually be exported from certain database-backed views. This prevents users from selecting fields that would fail or produce confusing export results.
Original PR description
…wizards - In the wizard of exporting data there are fields that may be not in our data base with attribute _table_query not set to none. -I have modified the export.py file to make the field of id in our fild dict only if the _table_query is set to None. task-4592514 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 expired lot warning in the lot kanban view now keeps the alert icon next to the date instead of splitting it onto a separate line. This makes expiry information easier to read at a glance and improves the visual clarity of inventory lot cards.
Original PR description
Before this commit, in the lot kanban view, if a lot was expired, the alert icon and the overpass days were on different lines. This commit fixes that so the alert icon is just beside the date. Before / After:   Enterprise PR: odoo/enterprise#80338
The checkout page no longer shows the same billing and delivery address warning while a customer is creating a new address. This prevents confusion during checkout and keeps the warning limited to cases where it is actually relevant.
Original PR description
Steps: - Install Ecom. - Go to shop page. - Add a product in cart goto address section in checkout. - Try to add new address. Issue: - Warning displaying for of same address for billing and delivery even though we are create new address Cause: - Missing condition to check if address is existing or new one. Fix: - Add condition on warning section to display it only for existing addresses. opw-4522138
This update makes an internal automated test for landed costs more consistent by ensuring records are checked in a predictable order. It helps prevent false test failures without changing how users work with Odoo.
Original PR description
This commit orders the stock valuation layer of multiple stock moves by product to make sure the assert targets the right layer index in the loop. runbot: 99086 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 community edition call menu in the top navigation now displays with the correct styling. This makes the calling interface look consistent and avoids visual confusion for users.
Original PR description
**Current behavior before PR:** The Systray Call menu in the community edition displayed incorrect styles due to improperly written CSS. **Desired behavior after PR is merged:** The issue is resolved by applying the correct conditions in the CSS. Before / After   Task-[4458263](https://www.odoo.com/odoo/my-tasks/4458263) Enterprise-https://github.com/odoo/enterprise/pull/76910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Live chat system notifications now display the visitor's live chat name when their regular author name is unavailable. This prevents blank names in messages like join, leave, or channel invite notifications, making conversations clearer for users and support teams.
Original PR description
For visitors, the name of the author might not be known, only their live chat user name. Use the getter that takes this into account when displaying the author name of notifications such as "join", "left" or "invited to the channel" to actually display the live chat user name rather than nothing. task-4433078
This change fixes the positioning of wave and bubble graphics in report layouts so they display correctly in the report editor preview. It keeps generated PDF reports working as before while preventing decorative elements from appearing in the wrong place during editing.
Original PR description
Before this commit the wave and bubble layouts did not play well in the report editor. The svg was set to be an overlay, in fixed position, with a top = 0 property. In wkhtmltopdf it did work because…
Before this commit the wave and bubble layouts did not play well in the report editor. The svg was set to be an overlay, in fixed position, with a top = 0 property. In wkhtmltopdf it did work because we render the header and footer in their own viewport. In the report editor however, the viewport is unique and the svg was then fixed to the top of the page. After this commit, the report layouts continue to work in wkhtmltopdf, but we removed the top = 0 attribute. Following https://stackoverflow.com/a/12282107 it should work in the contexts: (TLDR: in position fixed, if top and bottom are not specified, the default position is the one the block should have taken if it were staticly positioned) - wkhtmltopdf: the footer is rendered in its own viewport and consequently the top of the viewport is also the top of the footer and thus the original static position - action report of type HTML: no worries here, this fix doesn't apply because of ifs in the qweb expressions - report editor in edition mode: The SVG is inisible anyway because it needs a fill value which is not present in that context. The svg is located outside of the iframe's port in practice with the fix. - report editor in preview mode: works because the iframe cannot be interacted with and that the default static position is within the footer opw-4508900 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
Archived products are now hidden when configuring combo products in sales orders. This prevents sales teams from accidentally selecting unavailable or discontinued items, keeping orders cleaner and more accurate.
Original PR description
steps: - create a combo product with 1 or more combo items - archive a product part of this combo - create an SO and add this combo product issue: - it shows archived product cause: - combo_configurator_get_data loops through all products part of the combo fix: - added an active condition in the loop opw-4579038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could block product exchanges when the original incoming shipment had no origin reference. The system now handles missing origin information safely, allowing the exchange process to continue without interruption.
Original PR description
Steps to reproduce: 1. Create a storable product. 2. Link a vendor to the product. 3. Create and validate an incoming picking from the vendor for the product. 4. Initiate an exchange. Issue: A traceback occurs during exchange creation when the original picking lacks an "origin." The system attempts to parse a False value as a string, causing an error. Solution: Ensure the origin is populated before running the procurement. If no origin is set, pass an empty string instead of False. opw-4556305 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change ensures a manufacturing work order test runs reliably even when demo data is not installed. It helps prevent false build failures, improving confidence in the release process without changing customer-facing behavior.
Original PR description
### Issue: The test `test_add_component_from_shop_foor` fails the first step of the tour if run without demo data's since the user admin does not belong to the group `mrp.group_mrp_routing`. With demo data it is automatically added to the default via these lines: https://github.com/odoo/odoo/blob/42b43bad2978d6f809f9210753e2e4d06e00d436/addons/mrp/data/mrp_demo.xml#L9-L12 runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/116698
This fix makes automated checks wait until document folders are fully loaded before continuing. It reduces random test failures when opening folders, helping keep spreadsheet-related document workflows more stable during validation.
Original PR description
Sometimes, when opening the documents folder, folders were not being completely loaded, which gave errors. This fix checks if the folders are properly loaded on the page and only then lets tours continue. Runbot build errors [1](https://runbot.odoo.com/odoo/action-573/109605), [2](https://runbot.odoo.com/odoo/action-573/109607), [3](https://runbot.odoo.com/odoo/action-573/113711), [4](https://runbot.odoo.com/odoo/action-573/113712)
Installing Helpdesk no longer fails when the default periodic digest email was previously deleted. This prevents an installation-blocking error and lets businesses add Helpdesk without restoring that optional digest record first.
Original PR description
Currently a `ParseError` arises when the user installs the `helpdesk` module after deleting `Your Odoo Periodic Digest` from the `Digest Emails` in Settings. Steps to reproduce: --- - Install…
Currently a `ParseError` arises when the user installs the `helpdesk` module after deleting `Your Odoo Periodic Digest` from the `Digest Emails` in Settings.
Steps to reproduce:
---
- Install `digest` module (without demo data)
- Settings > Technical > Email > Digest Emails > Delete `Your Odoo Periodic Digest`
- Now install `helpdesk` module
Traceback:
---
```
Exception: Cannot update missing record 'digest.digest_digest_default'
ParseError: while parsing /home/odoo/src/enterprise/saas-18.1/helpdesk/data/digest_data.xml:4, somewhere inside <record id="digest.digest_digest_default" model="digest.digest">
<field name="kpi_helpdesk_tickets_closed">True</field>
</record>
```
The error occurs because the user deleted `Your Odoo Periodic Digest` and then installed the `helpdesk` module. which requires a particular record.
This commit solves the above issue by using `forcecreate="False"` to bypass record creation if it violates checks.
https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/odoo/tools/convert.py#L364-L366
sentry-5731062091This fixes an issue where users adding favorite filters inside embedded Knowledge views saw a shared option that should not appear there. The change keeps the filter setup clearer and prevents users from selecting an option that is not applicable in embedded views.
Original PR description
Steps to reproduce: 1. Add a embedded view in Knowledge, like a kanban view. 2. Add a new favorite filter. 3. The shared checkbox is shown. To address this issue, we need to use the `.context` since in owl the `._context` is giving inconsistent results, this due to how the rendering is being done, we sometimes will try to access the context before it is actually set, and we'll get a null value. With the `.context` we are sure that the context is set and we can access the `knowledgeEmbeddedViewId` properly. opw
The accounting reconciliation process now checks whether predefined model lines should actually be used before applying them. This prevents hidden or outdated rule lines from affecting reconciliations unexpectedly, helping keep accounting entries aligned with the current configuration.
Original PR description
This fix will add a check that if the line_ids of a reco model should or not apply before using them. At the moment, even if the line_ids are hidden in the view due to the settings of the reco model, as long as lines were defined before the list is hidden they will still be used.
The Systray Call menu now displays with the intended styling in the community edition. This fixes a visual issue caused by incorrect style conditions, helping users see a cleaner and more consistent call menu.
Original PR description
**Current behavior before PR:** The Systray Call menu in the community edition displayed incorrect styles due to improperly written CSS. **Desired behavior after PR is merged:** The issue is resolved by applying the correct conditions in the CSS. Task-[4458263](https://www.odoo.com/odoo/my-tasks/4458263) Community-https://github.com/odoo/odoo/pull/192862
during refactoring of `hr_holidays` for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a), the `_get_days_request` function has been removed in the `hr_holidays` module, but it is still overridden in `hr_holidays_attendance` Forward-Port-Of: odoo/odoo#190472
Original PR description
during refactoring of `hr_holidays` for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a), the `_get_days_request` function has been removed in the `hr_holidays` module, but it is still overridden in `hr_holidays_attendance` Forward-Port-Of: odoo/odoo#190472
This commit:https://github.com/odoo/odoo/commit/134324c5cf0e2e62f02d212ac27a9442e1f7a824 removed the auto-install for l10n_fr. Which has the consequence of not having l10n_fr_account installed when we have account and l10n_fr. This commit will reintroduce that but also removing the countries since it depends on l10n_fr that already has the country set up. task: 4296946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odo
Original PR description
This commit:https://github.com/odoo/odoo/commit/134324c5cf0e2e62f02d212ac27a9442e1f7a824 removed the auto-install for l10n_fr. Which has the consequence of not having l10n_fr_account installed when we have account and l10n_fr. This commit will reintroduce that but also removing the countries since it depends on l10n_fr that already has the country set up. task: 4296946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197269
Currently, searching for `Resume's Content` on applicants uses the domain `attachment_ids.index_content`, which searches the `index_content` of all attachments, ignoring the model they are linked to. This update modifies the domain to include a `res_model` filter, ensuring the search is limited to applicants' attachments, which are typically CVs added by recruiters. opw-4558352 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: od
Original PR description
Currently, searching for `Resume's Content` on applicants uses the domain `attachment_ids.index_content`, which searches the `index_content` of all attachments, ignoring the model they are linked to. This update modifies the domain to include a `res_model` filter, ensuring the search is limited to applicants' attachments, which are typically CVs added by recruiters. opw-4558352 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199288
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#199359 Forward-Port-Of: odoo/odoo#197001
Original PR description
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#199359 Forward-Port-Of: odoo/odoo#197001
steps to reproduce: ------------------------ 1. Install a localization module that does not use `anglo_saxon_accounting` in 17.0 (Ex:l10n_in) 2. Enable the "Anglo-Saxon Accounting" option. 3. Migrate to 18.0 version. Issue: ------- Commit c2d0251 , sets a default value when changing the CoA. However, during migration, when the `_pre_load_data` function runs, it overrides the customer's selection even if the CoA is not changed and assigns the default value to the `anglo_saxon_account
Original PR description
steps to reproduce: ------------------------ 1. Install a localization module that does not use `anglo_saxon_accounting` in 17.0 (Ex:l10n_in) 2. Enable the "Anglo-Saxon Accounting" option. 3. Migrate…
steps to reproduce: ------------------------ 1. Install a localization module that does not use `anglo_saxon_accounting` in 17.0 (Ex:l10n_in) 2. Enable the "Anglo-Saxon Accounting" option. 3. Migrate to 18.0 version. Issue: ------- Commit c2d0251 , sets a default value when changing the CoA. However, during migration, when the `_pre_load_data` function runs, it overrides the customer's selection even if the CoA is not changed and assigns the default value to the `anglo_saxon_accounting` field, ignoring the customer's preference. **Original DB:** ```psql bona_2515224=> select id,name,anglo_saxon_accounting from res_company; id | name | anglo_saxon_accounting ----+--------------------------------+------------------------ 6 | Handful of Health Pvt Ltd - TN | t 4 | Handful of Health Pvt Ltd - KA | t 8 | Handful of Health Pvt Ltd - GJ | t 2 | Handful of Health Pvt Ltd - MH | t 7 | Handful of Health Pvt Ltd - GA | t 5 | Handful of Health Pvt Ltd - RJ | t 3 | Handful of Health Pvt Ltd - UP | t 1 | Handful of Health Pvt Ltd - DL | t (8 rows) ``` **Without fix:** ```psql bona_2515224_upg=> select id,name,anglo_saxon_accounting from res_company; id | name | anglo_saxon_accounting ----+--------------------------------+------------------------ 1 | Handful of Health Pvt Ltd - DL | f 2 | Handful of Health Pvt Ltd - MH | f 3 | Handful of Health Pvt Ltd - UP | f 4 | Handful of Health Pvt Ltd - KA | f 5 | Handful of Health Pvt Ltd - RJ | f 6 | Handful of Health Pvt Ltd - TN | f 7 | Handful of Health Pvt Ltd - GA | f 8 | Handful of Health Pvt Ltd - GJ | f (8 rows) ``` **With fix:** ```psql bona_2515224_18.0=> select id,name,anglo_saxon_accounting from res_company; id | name | anglo_saxon_accounting ----+--------------------------------+------------------------ 7 | Handful of Health Pvt Ltd - GA | t 8 | Handful of Health Pvt Ltd - GJ | t 4 | Handful of Health Pvt Ltd - KA | t 2 | Handful of Health Pvt Ltd - MH | t 5 | Handful of Health Pvt Ltd - RJ | t 6 | Handful of Health Pvt Ltd - TN | t 3 | Handful of Health Pvt Ltd - UP | t 1 | Handful of Health Pvt Ltd - DL | t (8 rows) ``` opw-4542300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198011
Steps to reproduce: - Add an snippet. - Click the "show/hide on desktop" button of visibility option. - Click on the little eye on the "hidden elements" section to have it displayed again. - Go to mobile preview mode. - Come back to desktop view by toggling off mobile preview button. - An empty overlay appears on the left of the screen. With dimensions similar to snippet in mobile view. After this commit: Empty overlays no longer appear when switching between preview modes. task-32
Original PR description
Steps to reproduce: - Add an snippet. - Click the "show/hide on desktop" button of visibility option. - Click on the little eye on the "hidden elements" section to have it displayed again. - Go to mobile preview mode. - Come back to desktop view by toggling off mobile preview button. - An empty overlay appears on the left of the screen. With dimensions similar to snippet in mobile view. After this commit: Empty overlays no longer appear when switching between preview modes. task-3270034 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198521 Forward-Port-Of: odoo/odoo#173328
CUP and CIG fields for the Italian Localization are available in account moves and are used when the buyer is a Public Administration or utilizes public funds for payment. However, in some cases, these fields are already necessary in the Sales Order. Therefore, this commit adds the CUP and CIG fields to eligible Sales Orders and automatically adds said fields to the Invoice generated from the SO. The fields Origin Document Type, Origin Document Name, Origin Document Date are also added to
Original PR description
CUP and CIG fields for the Italian Localization are available in account moves and are used when the buyer is a Public Administration or utilizes public funds for payment. However, in some cases, these fields are already necessary in the Sales Order. Therefore, this commit adds the CUP and CIG fields to eligible Sales Orders and automatically adds said fields to the Invoice generated from the SO. The fields Origin Document Type, Origin Document Name, Origin Document Date are also added to the Sales Order. If the fields are filled, then the values are passed to the invoice. If the fields are empty, then the Origin Document fields in the invoice are filled with information about the SO which originated it. Task [link](https://www.odoo.com/odoo/project/967/tasks/4290997) task-4290997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197267
This PR removes empty replace possibly breaking view inheritence Forward-Port-Of: odoo/enterprise#80200
Original PR description
This PR removes empty replace possibly breaking view inheritence Forward-Port-Of: odoo/enterprise#80200
Have a field in a view like this ```<field name="" options="{ some_boolean: 1 }" />``` And have the corresponding supportedOption (defined on the field widget): ```{ somme_boolean: { type: "boolean" } }``` Open studio and click on that field, in debug mode. Before this commit, there was a crash because 1 or 0 were directly passed to a component which expected a boolean value. After this commit, before displaying the options we convert 0 or 1 to the corresponding boolean. Forw
Original PR description
Have a field in a view like this
```<field name="" options="{ some_boolean: 1 }" />```
And have the corresponding supportedOption (defined on the field widget):
```{
somme_boolean: {
type: "boolean"
}
}```
Open studio and click on that field, in debug mode.
Before this commit, there was a crash because 1 or 0 were directly passed to a component which expected a boolean value. After this commit, before displaying the options we convert 0 or 1 to the corresponding boolean.
Forward-Port-Of: odoo/enterprise#80014**Issue:** The COA for the French localization has been updated in 2025. Some accounts have been replaced or removed and the reports have been updated with the new formulas. However, the reports from 2024 are still needed for those who need to print a report for 2024. **Solution:** Restore the old reports from 2024 as variants. opw-4566689 opw-4590293 opw-4572865 Forward-Port-Of: odoo/enterprise#80297 Forward-Port-Of: odoo/enterprise#79946
Original PR description
**Issue:** The COA for the French localization has been updated in 2025. Some accounts have been replaced or removed and the reports have been updated with the new formulas. However, the reports from 2024 are still needed for those who need to print a report for 2024. **Solution:** Restore the old reports from 2024 as variants. opw-4566689 opw-4590293 opw-4572865 Forward-Port-Of: odoo/enterprise#80297 Forward-Port-Of: odoo/enterprise#79946
**To reproduce:** 1. Create two branches within a company. 2. Set a bank account linked to the journal defined in the parent company 3. Create one payment, such as a SEPA payment or check, to be batched later, in each branch. 4. Selecting both branches and the parent company, create a batch payment with both payments. 5. The error "All payments in the batch must belong to the same company." is raised. **Desired behavior:** The payments in different companies that are branches of a commo
Original PR description
**To reproduce:** 1. Create two branches within a company. 2. Set a bank account linked to the journal defined in the parent company 3. Create one payment, such as a SEPA payment or check, to be…
**To reproduce:** 1. Create two branches within a company. 2. Set a bank account linked to the journal defined in the parent company 3. Create one payment, such as a SEPA payment or check, to be batched later, in each branch. 4. Selecting both branches and the parent company, create a batch payment with both payments. 5. The error "All payments in the batch must belong to the same company." is raised. **Desired behavior:** The payments in different companies that are branches of a common head office should not trigger the error. They should be allowed to be batched. **Cause:** The function `_check_payments_constrains()` in account_batch_payments raises an error if more than one company_id is present in the payments being batched. **Solution:** Change the check in `_check_payments_constrains()` to raise an error only if more than one root_id for the companies in the payments is present. This way, payments from several companies, branches of the same head office, can be batched. Payments from companies that do not share the same root_id, however, still raise an error when attempting to batch them. task-4568317 Forward-Port-Of: odoo/enterprise#80184 Forward-Port-Of: odoo/enterprise#79359
A previous commit[^1] disabled the rollback of the subtests. This was leading to the creation of multiple times the same data inside of the same sub transaction, raising a constraint on the company name, which should be unique. runbot-135304 [^1]: 8f50521be74d0cf858beea3b0aeb59760264ac4d Forward-Port-Of: odoo/enterprise#80224
Original PR description
A previous commit[^1] disabled the rollback of the subtests. This was leading to the creation of multiple times the same data inside of the same sub transaction, raising a constraint on the company name, which should be unique. runbot-135304 [^1]: 8f50521be74d0cf858beea3b0aeb59760264ac4d Forward-Port-Of: odoo/enterprise#80224
The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock. Notes: We spotted a lot of deadlock in or lock due to that CRON. We saw that it could rollback the write on a lot of row at the same time and could prevent the cron to call itself for the next execution. Traceback: (VALUES where removed for readability, there were 100 of them) ``` 2025-01-27 12:00:39,276 3822296 ERROR openerp odoo.sql_db: bad query: b'UPDATE "accoun
Original PR description
The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock. Notes: We spotted a lot of deadlock in or lock due to that CRON. We saw that…
The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock.
Notes:
We spotted a lot of deadlock in or lock due to that CRON. We saw that it could rollback the write on a lot of row at the same time and could prevent the cron to call itself for the next execution.
Traceback: (VALUES where removed for readability, there were 100 of them)
```
2025-01-27 12:00:39,276 3822296 ERROR openerp odoo.sql_db: bad query: b'UPDATE "account_bank_statement_line"
SET "cron_last_check" = "__tmp"."cron_last_check"::timestamp, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (...), (...), (...), (...), ) AS "__tmp"("id", "cron_last_check", "write_date", "write_uid")
WHERE "account_bank_statement_line"."id" = "__tmp"."id"'
ERROR: deadlock detected
DETAIL: Process 934692 waits for ShareLock on transaction 2414965881; blocked by process 932819.
Process 932819 waits for ShareLock on transaction 2414966299; blocked by process 934692.
HINT: See server log for query details.
CONTEXT: while updating tuple (10685,6) in relation "account_bank_statement_line"
2025-01-27 12:00:39,277 3822296 ERROR openerp odoo.addons.base.models.ir_cron: Job 'Try to reconcile automatically your statement lines' (297) server action #4952 failed
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_cron.py", line 572, in _callback
self.env.flush_all()
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 833, in flush_all
self[model_name].flush_model()
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6707, in flush_model
self._flush(fnames)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6784, in _flush
model.browse(some_ids)._write_multi(vals_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4881, in _write_multi
self.env.execute_query(SQL(
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 962, in execute_query
self.cr.execute(query)
File "/home/odoo/src/odoo/18.0/odoo/sql_db.py", line 373, in execute
res = self._obj.execute(query, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.DeadlockDetected: deadlock detected
DETAIL: Process 934692 waits for ShareLock on transaction 2414965881; blocked by process 932819.
Process 932819 waits for ShareLock on transaction 2414966299; blocked by process 934692.
HINT: See server log for query details.
CONTEXT: while updating tuple (10685,6) in relation "account_bank_statement_line"
```
task-id: 4393854
Forward-Port-Of: odoo/enterprise#80059As we support two more states (Alabama and Colorado), this commit adapts the W2 report to include information about those two states. task-4557365 Forward-Port-Of: odoo/enterprise#79684
Original PR description
As we support two more states (Alabama and Colorado), this commit adapts the W2 report to include information about those two states. task-4557365 Forward-Port-Of: odoo/enterprise#79684
We cannot properly handle the case where one line is shipped from multiple addresses. But we gave up too early: just because one sale line is linked to multiple stock moves doesn't necessarily mean that's the case. Here's an example that uses a single warehouse: 1/ create a sale order with one line with qty 2 2/ confirm the sale order 3/ validate the picking with qty 1 and create backorder for the other 4/ create the invoice from the sale order 5/ compute taxes No line-level address
Original PR description
We cannot properly handle the case where one line is shipped from multiple addresses. But we gave up too early: just because one sale line is linked to multiple stock moves doesn't necessarily mean that's the case. Here's an example that uses a single warehouse: 1/ create a sale order with one line with qty 2 2/ confirm the sale order 3/ validate the picking with qty 1 and create backorder for the other 4/ create the invoice from the sale order 5/ compute taxes No line-level address is sent because len(line.sale_line_ids.move_ids) is 2. This causes Avatax to calculate taxes based on the company address which could result in wrong taxes. After this commit, we only set None if a line was sent from warehouses with different addresses (partner_id). opw-4486746 Forward-Port-Of: odoo/enterprise#78556