Wednesday, July 10, 2024
27 changes · saas-17.1
Resolved issues and error corrections
The project onboarding tour no longer shows sub-task guidance in every launch scenario. This keeps the guided experience focused by only showing those steps when the tour starts automatically.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: - In the onboarding tour, a step guides users in creating sub-tasks. Desired behavior after PR is merged: - Launch the sub-task steps only when the tour is automatically started. task-3990244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an intermittent issue in automated point-of-sale loyalty checks where the reward line was verified before it finished appearing. The change makes the test wait for the reward line to render first, reducing false failures and improving release reliability.
Original PR description
The step to check the reward line added was sometimes happening before it had time to render. Changed the order of the step to allow the reward line to be rendered before checking it. runbot error: 69954
Miscellaneous changes
stdnum library incorrectly sets zeep Transport timeout, resulting in some requests hanging for 15 minutes. With this monkeypatch the timeout will be set correctly. Zeep github issue: mvantellingen/python-zeep#140 opw-3980718 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#172080 Forward-Por
Original PR description
stdnum library incorrectly sets zeep Transport timeout, resulting in some requests hanging for 15 minutes. With this monkeypatch the timeout will be set correctly. Zeep github issue: mvantellingen/python-zeep#140 opw-3980718 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#172080 Forward-Port-Of: odoo/odoo#171722
Before this commit, the POS loyalty program allowed the partial rewards which was inconsistent with the sale module's behavior. This change aligns the POS module with the sale module's behavior as updated in the following commit: https://github.com/odoo/odoo/commit/5188566444df102561b9d3e58f6671f60c61ffc3 opw-4000589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171746
Original PR description
Before this commit, the POS loyalty program allowed the partial rewards which was inconsistent with the sale module's behavior. This change aligns the POS module with the sale module's behavior as updated in the following commit: https://github.com/odoo/odoo/commit/5188566444df102561b9d3e58f6671f60c61ffc3 opw-4000589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171746
Description of the issue/feature this PR addresses: Transactions which are "locked" should not be edited through the UI Current behavior before PR: Locking a picking allowed you to change details via the smart button Desired behavior after PR is merged: Locked down more. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172041
Original PR description
Description of the issue/feature this PR addresses: Transactions which are "locked" should not be edited through the UI Current behavior before PR: Locking a picking allowed you to change details via the smart button Desired behavior after PR is merged: Locked down more. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172041
Uninstall l10n_ar_withholding Install again l10n_ar_withholding Issue: Reinstall will fail with error odoo.exceptions.ValidationError: Invoice and credit note distribution should each contain exactly one line for the base. This occurs because the system attempt to create a tax repartition line in existing tax instead of updating the data opw-3946193 Forward-Port-Of: odoo/odoo#172093
Original PR description
Uninstall l10n_ar_withholding Install again l10n_ar_withholding Issue: Reinstall will fail with error odoo.exceptions.ValidationError: Invoice and credit note distribution should each contain exactly one line for the base. This occurs because the system attempt to create a tax repartition line in existing tax instead of updating the data opw-3946193 Forward-Port-Of: odoo/odoo#172093
Steps to reproduce: - Go to Shop page on website - Enable edit mode - Pick a product and create a new Badge/Ribbon - Change the background color - Bug -> the bg-color is not set. Issue : ribbon bg-color is not set on the product. Cause : The !important attribute has been duplicated in the CSS rule since [1] and [2]. As a result, the background colour CSS rule for the ribbon is broken due to having !important twice. [1]: https://github.com/odoo/odoo/commit/c6f4929f65b899736c556f
Original PR description
Steps to reproduce: - Go to Shop page on website - Enable edit mode - Pick a product and create a new Badge/Ribbon - Change the background color - Bug -> the bg-color is not set. Issue : ribbon bg-color is not set on the product. Cause : The !important attribute has been duplicated in the CSS rule since [1] and [2]. As a result, the background colour CSS rule for the ribbon is broken due to having !important twice. [1]: https://github.com/odoo/odoo/commit/c6f4929f65b899736c556f8f0bb7824883a6d893 [2]: https://github.com/odoo/odoo/commit/9ee115b58342b3e0dbc11081e7ff752c10f8bfa9 fix : After removing the '!important' attribute from the create and write methods, we only encounter the '!important' attribute once. As a result, the ribbon background color is applied to the product. opw-3964071 Forward-Port-Of: odoo/odoo#168265
This commit optimizes the `_accumulate_amounts` method. Previously, when there were many stock moves per PoS order, the '_compute_average_price' would be called for each move, resulting in multiple identical queries for each valuation layer in each stock move. Now, the stock moves and valuation layers for an order are prefetched at once, significantly reducing the number of database queries. This results in a performance improvement, especially when processing a large number of PoS orders and
Original PR description
This commit optimizes the `_accumulate_amounts` method. Previously, when there were many stock moves per PoS order, the '_compute_average_price' would be called for each move, resulting in multiple identical queries for each valuation layer in each stock move. Now, the stock moves and valuation layers for an order are prefetched at once, significantly reducing the number of database queries. This results in a performance improvement, especially when processing a large number of PoS orders and stock moves. | Scenario | Before Optimization (seconds) | After Optimization (seconds) | |----------|------------------------------|-----------------------------| | 100 orders, 1,000 stock moves | 20 | 5 | | 300 orders, 100,000 stock moves | 617 | 23 | opw-3980597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171955 Forward-Port-Of: odoo/odoo#168963
Since unlinking `ir.attachment` is done after removing the record from the database, and the cache is already invalidated, we cannot browse `res_id` anymore. Also improve the prefetching for all messages being unlinked at the same time if related to different moves. Forward-Port-Of: odoo/odoo#172228
Original PR description
Since unlinking `ir.attachment` is done after removing the record from the database, and the cache is already invalidated, we cannot browse `res_id` anymore. Also improve the prefetching for all messages being unlinked at the same time if related to different moves. Forward-Port-Of: odoo/odoo#172228
When customer pay using viva wallet, a traceback will appear. First, the method was called from the public controller at line [1]. From the public controller, the method from model was called at [2], where access right was checked by the code. But since the method was called from the controller, we do not have any users in the environment, so the below error will occur. Traceback: ``` ValueError: not enough values to unpack (expected 1, got 0) File "odoo/models.py", line 5851, in
Original PR description
When customer pay using viva wallet, a traceback will appear. First, the method was called from the public controller at line [1]. From the public controller, the method from model was called at [2],…
When customer pay using viva wallet, a traceback will appear.
First, the method was called from the public controller at line [1].
From the public controller, the method from model was called at [2],
where access right was checked by the code.
But since the method was called from the controller,
we do not have any users in the environment,
so the below error will occur.
Traceback:
```
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5851, in ensure_one
_id, = self._ids
ValueError: Expected singleton: res.users()
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1966, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/pos_viva_wallet/controllers/main.py", line 24, in notification
payment_method_sudo._retrieve_session_id(data_webhook)
File "addons/pos_viva_wallet/models/pos_payment_method.py", line 115, in _retrieve_session_id
data = self._call_viva_wallet(endpoint, 'get')
File "addons/pos_viva_wallet/models/pos_payment_method.py", line 99, in _call_viva_wallet
session.headers.update(self._bearer_token(session))
File "addons/pos_viva_wallet/models/pos_payment_method.py", line 58, in _bearer_token
if not self.env.user.has_group('point_of_sale.group_pos_user'):
File "odoo/addons/base/models/res_users.py", line 1120, in has_group
self.ensure_one()
File "odoo/models.py", line 5854, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
[1] https://github.com/odoo/odoo/blob/5d065006005a18836b83e7309193864ac6e303f7/addons/pos_viva_wallet/controllers/main.py#L24
[2]- https://github.com/odoo/odoo/blob/5d065006005a18836b83e7309193864ac6e303f7/addons/pos_viva_wallet/models/pos_payment_method.py#L58-L59
sentry-5563172568
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#171874An error occurs when the system tries to retrieve 'session_id' at [1] from 'MerchantTrns' but it is not available. Because of failed transactions (Ref: https://developer.viva.com/webhooks-for-payments/transaction-failed/#response-example) link [1]: https://github.com/odoo/odoo/blob/319cf81da8f16df21900f26bd6d8b4fc686e72eb/addons/pos_viva_wallet/models/pos_payment_method.py#L113 To resolve this issue, add a condition to check if 'MerchantTrns' is not available in 'data_webhook' then raise a
Original PR description
An error occurs when the system tries to retrieve 'session_id' at [1] from 'MerchantTrns' but it is not available. Because of failed transactions (Ref: https://developer.viva.com/webhooks-for-payments/transaction-failed/#response-example) link [1]: https://github.com/odoo/odoo/blob/319cf81da8f16df21900f26bd6d8b4fc686e72eb/addons/pos_viva_wallet/models/pos_payment_method.py#L113 To resolve this issue, add a condition to check if 'MerchantTrns' is not available in 'data_webhook' then raise an error as send notification. Sentry - 5466498742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171764
Steps to reproduce: ------------------- - Install `Project` and `Field Service Reports` modules (for testing purpose) - Go to `Project` and select `Field Service` project - Open `Boiler Maintenance` task - Add some Timesheets (ensure `Hours spent` is set) and save - Click on `Sign Report` - Scroll to ensure that the `Communication History` is in the middle of the page but still can click on `Sign` button - Click on Sign Issue: ------ The message section is on top of the Sign pop
Original PR description
Steps to reproduce: ------------------- - Install `Project` and `Field Service Reports` modules (for testing purpose) - Go to `Project` and select `Field Service` project - Open `Boiler Maintenance`…
Steps to reproduce: ------------------- - Install `Project` and `Field Service Reports` modules (for testing purpose) - Go to `Project` and select `Field Service` project - Open `Boiler Maintenance` task - Add some Timesheets (ensure `Hours spent` is set) and save - Click on `Sign Report` - Scroll to ensure that the `Communication History` is in the middle of the page but still can click on `Sign` button - Click on Sign Issue: ------ The message section is on top of the Sign pop-up. Same issue with attachment if we post a comment with attachment. Cause: ------ There is a conflict with the `Stacking Context` of the modal, added inside the portal sidebar who have `position:sticky`, and the message section, that is inside a seperate div (the portal content) who have `position:relative`. Solution: --------- Add a `z-index` to the sticky sidebar. Fore more info: https://web.dev/learn/css/z-index#stacking_context https://talk.tiddlywiki.org/t/minimal-css-a-fix-for-dropdown-popup-hidden-by-position-sticky-title/9338 opw-3917549 Forward-Port-Of: odoo/odoo#170077
When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount. Added a check to differentiate fixed taxes from other and adapt display accordingly. Since the function modified has been updated in 17.2, another PR will be necessary. See https://github.com/odoo/odoo/pull/168634 task-3964942 Forward-Port-Of: odoo/odoo#170741 Forward-Port-Of: odoo/odoo#168638
Original PR description
When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount. Added a check to differentiate fixed taxes from other and adapt display accordingly. Since the function modified has been updated in 17.2, another PR will be necessary. See https://github.com/odoo/odoo/pull/168634 task-3964942 Forward-Port-Of: odoo/odoo#170741 Forward-Port-Of: odoo/odoo#168638
This commit adds a check to prevent errors when a reward product is archived. opw-4012282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171175
Original PR description
This commit adds a check to prevent errors when a reward product is archived. opw-4012282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171175
Related ticket: 4000939 Forward-Port-Of: odoo/enterprise#66407
Original PR description
Related ticket: 4000939 Forward-Port-Of: odoo/enterprise#66407
The Company Identification field was incorrectly formatted as a numeric field. It is specified as numeric by some banks [^1], but the official specification is alphanumeric [^2]. On top of that the alphanumeric Company Discretionary Data field was right-justified. A minority of banks don't handle this correctly. There's no official specification on how to align alphanumeric fields [^1]. The decision to left-justify is based on the following: - Chase specifies to left-justify them [^3]
Original PR description
The Company Identification field was incorrectly formatted as a numeric field. It is specified as numeric by some banks [^1], but the official specification is alphanumeric [^2]. On top of that the…
The Company Identification field was incorrectly formatted as a numeric field. It is specified as numeric by some banks [^1], but the official specification is alphanumeric [^2].
On top of that the alphanumeric Company Discretionary Data field was right-justified. A minority of banks don't handle this correctly.
There's no official specification on how to align alphanumeric fields [^1]. The decision to left-justify is based on the following:
- Chase specifies to left-justify them [^3]
- The most extensive open-source ACH library left-justifies them [^4]
- Another Python ACH library left-justifies them too [^5]
- Online images of ACH files seem to left-justify them as well
The only two remaining fields that are right-justified with spaces ({:>...}) are Immediate Destination and Immediate Origin. This is on purpose. Although they are numeric fields and thus right aligned, they are specified to start with a blank space, not a leading 0 [^2].
[^1]: https://web.archive.org/web/20230624090124/https://files.nc.gov/ncosc/documents/eCommerce/bank_of_america_nacha_file_specs.pdf
[^2]: https://achdevguide.nacha.org/ach-file-overview
[^3]: https://www.chase.com/content/dam/chaseonline/en/demos/cbo/pdfs/cbo_nacha_filespecs.pdf
[^4]: https://github.com/moov-io/ach/blob/073d011f811605e1b6051792163159a55feca533/converters.go#L81-L94
[^5]: https://github.com/travishathaway/python-ach/blob/cc8b6448d75f3815c91d3b8a5dadd6731aa96e71/ach/data_types.py#L57-L76
opw-4033830
Forward-Port-Of: odoo/enterprise#66286Steps to reproduce: - create a spreadsheet document - insert an image in the spreadsheet - hit the Share button - open the link in an incognito window => the image is not displayed Task: 4037385 opw-4035835 Forward-Port-Of: odoo/enterprise#66152
Original PR description
Steps to reproduce: - create a spreadsheet document - insert an image in the spreadsheet - hit the Share button - open the link in an incognito window => the image is not displayed Task: 4037385 opw-4035835 Forward-Port-Of: odoo/enterprise#66152
Steps to reproduce: ------------------- - Install 'Documents' and 'Accounting' modules - Go to document settings > Activate Accounting + go to "Journal" smart link then create a synchronized with Vendor Bills journal - Go to accounting setting > Activate "Document Digitization" and select "Digitize automatically" for bills - Send a PDF to the Vendor bill mail alias - Open the created bill Issue: ------ Error in the chatter. Cause: ------ We try to set on the document an att
Original PR description
Steps to reproduce: ------------------- - Install 'Documents' and 'Accounting' modules - Go to document settings > Activate Accounting + go to "Journal" smart link then create a synchronized with Vendor Bills journal - Go to accounting setting > Activate "Document Digitization" and select "Digitize automatically" for bills - Send a PDF to the Vendor bill mail alias - Open the created bill Issue: ------ Error in the chatter. Cause: ------ We try to set on the document an attachment already linked to it, and because it goes through the versioning code, it will first link the new attachment to the record (who was already the case), and then link the old attachment (who is the same attachment as the new) to the document. Solution: --------- If trying to set the same attachment already linked to the document, we skip the versioning code. opw-4034699 Forward-Port-Of: odoo/enterprise#66361
Before this commit, when dragging documents including one or more locked documents to another workspace, only the unlocked documents are effectiveley moved and no message were shown to alert the user although the code exists but is never triggered. This commit, fix this by displaying the notification alerting the user that the locked files haven't been moved. Task-3992114 Forward-Port-Of: odoo/enterprise#65723 Forward-Port-Of: odoo/enterprise#64670
Original PR description
Before this commit, when dragging documents including one or more locked documents to another workspace, only the unlocked documents are effectiveley moved and no message were shown to alert the user although the code exists but is never triggered. This commit, fix this by displaying the notification alerting the user that the locked files haven't been moved. Task-3992114 Forward-Port-Of: odoo/enterprise#65723 Forward-Port-Of: odoo/enterprise#64670
Forward-Port-Of: odoo/enterprise#66315
Original PR description
Forward-Port-Of: odoo/enterprise#66315
Before this commit: When the user chooses a pickup point, the res.partner of the sale order is replaced with data from the pickup point, while the previously set customer's data is set as the partner's parent. And Sendcloud relies on a service_point_id field in its API rather than a raw address. Which causes double printing of the service point address on the label. Moreover, Sendcloud explicitly requires the customer's (and not the pickup point) address in its API. After this commit:
Original PR description
Before this commit: When the user chooses a pickup point, the res.partner of the sale order is replaced with data from the pickup point, while the previously set customer's data is set as the partner's parent. And Sendcloud relies on a service_point_id field in its API rather than a raw address. Which causes double printing of the service point address on the label. Moreover, Sendcloud explicitly requires the customer's (and not the pickup point) address in its API. After this commit: Both the service_point_id and the customer's delivery address are sent to Sendcloud. Both addresses are printed on the label correctly. opw-3977565 Forward-Port-Of: odoo/enterprise#65354
Issue ===== When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity. How to reproduce ================ - Enable "Product Packagings" and "Units of Measure"; - Select GS1 nomenclature as the Barcode Nomenclature; - Create a product with a packaging for multiple quantity (e.g.: 4 Units) and with a valid GTIN (e.g.: 12345600012349); - In the Barcode app, create a new receipt;
Original PR description
Issue ===== When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity. How to reproduce…
Issue ===== When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity. How to reproduce ================ - Enable "Product Packagings" and "Units of Measure"; - Select GS1 nomenclature as the Barcode Nomenclature; - Create a product with a packaging for multiple quantity (e.g.: 4 Units) and with a valid GTIN (e.g.: 12345600012349); - In the Barcode app, create a new receipt; - Scan a GS1 barcode containing both the packaging barcode and a weight (e.g.: 10123456000123493103001500) => The scanned weight is used as the quantity and is multiplied by the packaging quantity (in this example, the quantity will be 6, because 4 units x 1.5 kg = 6 units) Expected Behavior ================= Since the associated product uses Units as UoM, the scanned weight can't be converted into quantity (we can't convert g or kg into units), so this information should be ignored and the packaging quantity should be used alone instead. Note that the packaging quantity will still multiply the scanned quantity if the share the same UoM category. This behavior is still supported to be able to scan multiple packagings at once. That said, this use case make sense for products using Units only. [OPW-3988826](https://www.odoo.com/odoo/11258/tasks/3988826?cids=1) Forward-Port-Of: odoo/enterprise#66244 Forward-Port-Of: odoo/enterprise#65073
Since the audit trail is mandatory in Germany, we cannot remove moves or any documents related. We only need to remove the moves linked to the company of the tour. Forward-Port-Of: odoo/enterprise#66226
Original PR description
Since the audit trail is mandatory in Germany, we cannot remove moves or any documents related. We only need to remove the moves linked to the company of the tour. Forward-Port-Of: odoo/enterprise#66226
With this PR, the actions to open all journal items have been removed from all GSTR sections of the GST return Period. This change helps streamline the GST Return by eliminating unnecessary actions, ensuring a more focused and efficient reporting process. **task**-3908555 Forward-Port-Of: odoo/enterprise#64442
Original PR description
With this PR, the actions to open all journal items have been removed from all GSTR sections of the GST return Period. This change helps streamline the GST Return by eliminating unnecessary actions, ensuring a more focused and efficient reporting process. **task**-3908555 Forward-Port-Of: odoo/enterprise#64442
*l10n_account_customer_statements,l10n_my_reports,l10n_us_reports Currently some reports add buttons on their lines to perform some action on them. However, when prefix groups are used, the buttons are also shown on these lines, but refer to nothing and will thus either cause an error when clicked or lead to a new record. This commit fixes that by providing a generic hook in the `line_name` template to inject buttons. This generic hook checks whether the line is a prefix group line and doe
Original PR description
*l10n_account_customer_statements,l10n_my_reports,l10n_us_reports Currently some reports add buttons on their lines to perform some action on them. However, when prefix groups are used, the buttons are also shown on these lines, but refer to nothing and will thus either cause an error when clicked or lead to a new record. This commit fixes that by providing a generic hook in the `line_name` template to inject buttons. This generic hook checks whether the line is a prefix group line and doesn't render the buttons if it is. All other reports were adapted to use this hook now. task-3932945 Forward-Port-Of: odoo/enterprise#65270
before this commit: Insurance amount was sent in rating request but not in shipping request. Resulting in no insurance amount being printed on label. After this commit: If the insurance amount is sent, it is added to the shipping request and gets printed on label. opw-3845693 Forward-Port-Of: odoo/enterprise#66036
Original PR description
before this commit: Insurance amount was sent in rating request but not in shipping request. Resulting in no insurance amount being printed on label. After this commit: If the insurance amount is sent, it is added to the shipping request and gets printed on label. opw-3845693 Forward-Port-Of: odoo/enterprise#66036
Related to : https://github.com/odoo/odoo/pull/170741 When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount. Added a check to differenciate fixed taxes from other and adapt display accordingly. This specific PR intends to stop a test in tax_external taking the new field into account. Since the function modified has been updated in 17.2, another PR will be necessary.
Original PR description
Related to : https://github.com/odoo/odoo/pull/170741 When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount.
Added a check to differenciate fixed taxes from other and adapt display accordingly.
This specific PR intends to stop a test in tax_external taking the new field into account.
Since the function modified has been updated in 17.2, another PR will be necessary.
See https://github.com/odoo/odoo/pull/168634
task-3964942
X-original-commit: b4c0aa0b00892b87da0c3bf6815cb0f575c216b2
Forward-Port-Of: odoo/enterprise#65505