Monday, November 25, 2024
28 changes · saas-17.2
Resolved issues and error corrections
Links from many-to-one fields in grid views have been updated to match Odoo's newer URL format. This prevents broken navigation when users click related records from grid rows, keeping workflows smooth in affected grid screens.
Original PR description
The links created with the many2OneGridRow widget won't work correctly. This commit, will change the link to the new format. This commit is a followup of https://github.com/odoo/odoo/commit/98f748603ed7677265280d33b0b4750010f71fe0
Miscellaneous changes
…o studio Have a flow where active_ids is in the url and is used by the action itself (with a dynamic context key for example). Enter studio and reload. Before this commit, this flow crashed, because active_ids was not present. After this commit it doesn"t crash. opw-4296198 Forward-Port-Of: odoo/enterprise#74341 Forward-Port-Of: odoo/enterprise#74291
Original PR description
…o studio Have a flow where active_ids is in the url and is used by the action itself (with a dynamic context key for example). Enter studio and reload. Before this commit, this flow crashed, because active_ids was not present. After this commit it doesn"t crash. opw-4296198 Forward-Port-Of: odoo/enterprise#74341 Forward-Port-Of: odoo/enterprise#74291
Issue ----- With helpdesk_fsm installed, uninstall helpdesk_fsm or any module that will trigger its uninstallation (e.g. helpdesk): Error: ``` in fields.py: fields = records.pool.field_computed[self] KeyError: 'helpdesk.team.fsm_project_id' ``` Cause ----- Issue since 1da1467115726263e5cdc50354b4413f8bb7ca7d and the addition of `use_fsm` as a dependency of `_compute_fsm_project_id` When we uninstall any helpdesk module, we set to False the associated fields of all helpdesk team
Original PR description
Issue ----- With helpdesk_fsm installed, uninstall helpdesk_fsm or any module that will trigger its uninstallation (e.g. helpdesk): Error: ``` in fields.py: fields = records.pool.field_computed[self]…
Issue ----- With helpdesk_fsm installed, uninstall helpdesk_fsm or any module that will trigger its uninstallation (e.g. helpdesk): Error: ``` in fields.py: fields = records.pool.field_computed[self] KeyError: 'helpdesk.team.fsm_project_id' ``` Cause ----- Issue since 1da1467115726263e5cdc50354b4413f8bb7ca7d and the addition of `use_fsm` as a dependency of `_compute_fsm_project_id` When we uninstall any helpdesk module, we set to False the associated fields of all helpdesk teams (mapped in `_get_field_modules`) for all uninstalled modules. https://github.com/odoo/enterprise/blob/9fba5f841c3c0710eb0cce00263bf914dac03dc6/helpdesk/models/ir_module.py#L13-L16 The change of `use_fsm` means `fsm_project_id` is marked as a field to be recomputed. This happens at some point during a `flush_all`, but after the field has been deleted in DB and a new registry has been loaded without that field. Change ----- Force a recomputation by flushing the records. opw-4338172 opw-4339801 Forward-Port-Of: odoo/enterprise#74255
Before this commit, when the user alters the unit_amount field of an analytic account line which is not a timesheet and the amount has more than 6 digits then the user will get a user error saying he cannot encode a number with more than 6 digits for the unit amount field. This commit makes sure the check made on the unit amount is only made when the analytic line altered is a timesheet. closes odoo/odoo#174964 Forward-Port-Of: odoo/enterprise#73399
Original PR description
Before this commit, when the user alters the unit_amount field of an analytic account line which is not a timesheet and the amount has more than 6 digits then the user will get a user error saying he cannot encode a number with more than 6 digits for the unit amount field. This commit makes sure the check made on the unit amount is only made when the analytic line altered is a timesheet. closes odoo/odoo#174964 Forward-Port-Of: odoo/enterprise#73399
The FormatAddressMixin implements a feature that will replace some parts of a view with some other when having no_address_format in the context. commit 28d8ee5ea27106bf21e5a25c3fce48d39ffed4fd partially solved the problem, but not for all the spots where we need to do a `get_view` without being parasited with the foreign tree parts. opw-4335439 Forward-Port-Of: odoo/enterprise#74257
Original PR description
The FormatAddressMixin implements a feature that will replace some parts of a view with some other when having no_address_format in the context. commit 28d8ee5ea27106bf21e5a25c3fce48d39ffed4fd partially solved the problem, but not for all the spots where we need to do a `get_view` without being parasited with the foreign tree parts. opw-4335439 Forward-Port-Of: odoo/enterprise#74257
In case we are not in a multi currency environment the currency of the journal is falsy, so if there is not a currency set, we take the one from the company task: 4293986 Forward-Port-Of: odoo/enterprise#73006
Original PR description
In case we are not in a multi currency environment the currency of the journal is falsy, so if there is not a currency set, we take the one from the company task: 4293986 Forward-Port-Of: odoo/enterprise#73006
Currently, when an operation is loaded in the barcode app, the frontend executes a request to get_barcode_data which will perform a read on all relevant barcode data from the backend to cache it on the frontend. The problem is, when loading the records of `stock.quant.packages`, it will attempt to read all empty packages with no location id. There are cases where these packages are way too many i.e. 500K and thus to read fields on these records, it would be terribly slow. As this is done upon op
Original PR description
Currently, when an operation is loaded in the barcode app, the frontend executes a request to get_barcode_data which will perform a read on all relevant barcode data from the backend to cache it on…
Currently, when an operation is loaded in the barcode app, the frontend executes a request to get_barcode_data which will perform a read on all relevant barcode data from the backend to cache it on the frontend. The problem is, when loading the records of `stock.quant.packages`, it will attempt to read all empty packages with no location id. There are cases where these packages are way too many i.e. 500K and thus to read fields on these records, it would be terribly slow. As this is done upon opening every operation in the barcode app, it's making the app feel sluggish. To workaround the problem, this PR introduces a config paramter `stock_barcode.usable_packages_limit` which will limit the total number of empty packages being read to feed the frontend cache. This gives the option to tradeoff between cache locality and network connection. Setting this limit to a smaller number will result in more rpc calls instead of suffering a slowdown on one big rpc call to load all data once. Benchmarks: This will totally depend on the configured limit. Lower limit would mean higher speedup and vice versa. As an example, setting a limit of 1000 cut down the loading of get_barcode_data from 13.87 s to 768 ms opw-4245980 Forward-Port-Of: odoo/enterprise#74096
Users have encountered invoice rejections from the ISS due to an incompatible document type when creating automatic invoices. This modification ensures that the correct document type is assigned based on the customer's taxpayer type, allowing the invoice to be approved by the ISS. task-4299210 Forward-Port-Of: odoo/enterprise#73945
Original PR description
Users have encountered invoice rejections from the ISS due to an incompatible document type when creating automatic invoices. This modification ensures that the correct document type is assigned based on the customer's taxpayer type, allowing the invoice to be approved by the ISS. task-4299210 Forward-Port-Of: odoo/enterprise#73945
[FIX] documents{_sign}: fix access error applying sign action How to reproduce: - Install documents_sign and log as admin - In documents, create an action (Workspace: Finance, Create: PDF to Sign) - Then upload a pdf in the workspace Finance - Log as Marc Demo - In documents, select the PDF uploaded as admin - Click on the action created You get the error: "Sorry, you are not allowed to access this document." while the expected behavior is that users who have access to the document a
Original PR description
[FIX] documents{_sign}: fix access error applying sign action How to reproduce: - Install documents_sign and log as admin - In documents, create an action (Workspace: Finance, Create: PDF to Sign) -…
[FIX] documents{_sign}: fix access error applying sign action
How to reproduce:
- Install documents_sign and log as admin
- In documents, create an action (Workspace: Finance, Create: PDF to Sign)
- Then upload a pdf in the workspace Finance
- Log as Marc Demo
- In documents, select the PDF uploaded as admin
- Click on the action created
You get the error: "Sorry, you are not allowed to access this document." while the expected behavior is that users who have access to the document and to Sign should be able to use the action. We solve that in this commit.
We also add a test checking that applying an action to sign a pdf document not owned by the user that perform the action, doesn't duplicate the attachment if the attachment is owned by the document (res_id and res_model pointing to the document; the ownership is transferred to the sign.template created) and duplicate it otherwise.
Technical note: the error was caused by the trick used in the override of sign_template.create in documents_sign which was setting the res_model to False and res_id to 0 for attachment linked to document to allow the super method to link that attachment to the created sign_template (by releasing the ownership of the attachment from the document). But as ir_attachment prevents to link an attachment with res_id = 0 to a record if it is not done by the owner of that
attachment, there was an error. We remove that tricks by defining a method that determine if sign_template can take the ownership of the attachment or not which we override in document_sign and make it return True when the attachment is owned by a document.
Task-4000988
Forward-Port-Of: odoo/enterprise#73338
Forward-Port-Of: odoo/enterprise#65206Issue: In the subscription order user portal, the anticipate payment included products with the invoice policy set to delivered quantity that were not delivered yet. -Enable online payment and demo payment provider in the configuration. -Create a new subscription order in the subscription module. -Add a product with its invoice policy set to ordered quantity. -Add another product with its invoice policy set to delivered quantity. -Confirm the order and click on preview to access the user
Original PR description
Issue: In the subscription order user portal, the anticipate payment included products with the invoice policy set to delivered quantity that were not delivered yet. -Enable online payment and demo payment provider in the configuration. -Create a new subscription order in the subscription module. -Add a product with its invoice policy set to ordered quantity. -Add another product with its invoice policy set to delivered quantity. -Confirm the order and click on preview to access the user portal. -Proceed with the payment through the portal. It is now not possible to pay in advance through the user portal for recurring products with an invoice policy set to delivered quantity if they haven't been delivered yet. We still allow advance payments for partially delivered products. opw-3775930 Forward-Port-Of: odoo/enterprise#72578
Users require the name of the invoice report to be the same as the xml. task-4284482 Forward-Port-Of: odoo/enterprise#73335
Original PR description
Users require the name of the invoice report to be the same as the xml. task-4284482 Forward-Port-Of: odoo/enterprise#73335
Before this commit: duplicate words appeared in the GST state validation warning. After this commit: the duplicate words have been removed from the GST state validation warning. Forward-Port-Of: odoo/odoo#187986
Original PR description
Before this commit: duplicate words appeared in the GST state validation warning. After this commit: the duplicate words have been removed from the GST state validation warning. Forward-Port-Of: odoo/odoo#187986
### Steps to reproduce: - Install "l10n_sa" and the Arabic language - Create a product and translate its name to Arabic - Create an invoice and print it - In the invoice lines under the description column only one translation displays and not both as it should. ### Cause: The code was changed to only display the current language in this [commit](https://github.com/odoo/odoo/commit/67b041521d05cbcf5adaf04998278c10fa046790). The goal of this commit was to prevent the duplication of the pro
Original PR description
### Steps to reproduce: - Install "l10n_sa" and the Arabic language - Create a product and translate its name to Arabic - Create an invoice and print it - In the invoice lines under the description…
### Steps to reproduce: - Install "l10n_sa" and the Arabic language - Create a product and translate its name to Arabic - Create an invoice and print it - In the invoice lines under the description column only one translation displays and not both as it should. ### Cause: The code was changed to only display the current language in this [commit](https://github.com/odoo/odoo/commit/67b041521d05cbcf5adaf04998278c10fa046790). The goal of this commit was to prevent the duplication of the product name because it is already contained in line.name. ### Solution: The way line.name is computed is by taking the sales description (or purchase one) and concatenating it with the product name. It can also be changed manually in the invoice form view under "label". So to display the product name in both languages and this label without any duplicate this commit adds conditions: - the label is always displayed - the Arabic name is displayed if the label does not contains it - the English name is displayed if the label does not contains it and if it is different from the Arabic one (ie if it is translated) opw-4187577 Forward-Port-Of: odoo/odoo#188140 Forward-Port-Of: odoo/odoo#186449
When a SO is partially invoiced, and we change the 'Invoicing Switch Threshold' such that the partial invoices are before the new threshold, the SO will not take invoices into account for computation of amount to invoice / invoiced. Steps to reproduce (needs account_accountant installed): - Create a SO with a line having prod invoiced on delivery and qty 3 - Set delivered quantity to 1 - Click Create Invoice > create the draft invoice, set a date (date1) in the past - set a date2 Settin
Original PR description
When a SO is partially invoiced, and we change the 'Invoicing Switch Threshold' such that the partial invoices are before the new threshold, the SO will not take invoices into account for computation of amount to invoice / invoiced. Steps to reproduce (needs account_accountant installed): - Create a SO with a line having prod invoiced on delivery and qty 3 - Set delivered quantity to 1 - Click Create Invoice > create the draft invoice, set a date (date1) in the past - set a date2 Settings > Accounting > Invoicing Switch Threshold later than date1 - Back to the SO, set delivered quantity to 2 - Click Create Invoice > create a new invoice and confirm it Issue: Sale order amount invoiced will take into account only the latest invoice, while it should account also for the legacy invoices opw-4295531 Forward-Port-Of: odoo/odoo#187211
Steps to reproduce: - Go to a Website page. - Enable the "Mobile" preview. - Click on the "Edit" button to enter in edit mode. - Bug: When entering edit mode, the toolbar briefly appears and then disappears on the page. To fix this, we move the line that adds a "d-none" class to this toolbar earlier in the "start" of "snippetMenu". opw-4321865 opw-4232082 Forward-Port-Of: odoo/odoo#188075
Original PR description
Steps to reproduce: - Go to a Website page. - Enable the "Mobile" preview. - Click on the "Edit" button to enter in edit mode. - Bug: When entering edit mode, the toolbar briefly appears and then disappears on the page. To fix this, we move the line that adds a "d-none" class to this toolbar earlier in the "start" of "snippetMenu". opw-4321865 opw-4232082 Forward-Port-Of: odoo/odoo#188075
_*=payment_razorpay In This PR Razorpay payment onboarding form to take advantage of the Razorpay Connect Onboarding Flow. It integrates the Razorpay Onboarding using the IAP proxy. **Purpose** ======== Help users easily onboard with Razorpay by using the Razorpay Connect API. **Specification** =========== **1.Connect and authorized the razorpay account.** - To connect to a sub-merchant's Razorpay account, the application redirects the user to a Razorpay-hosted webpage. The
Original PR description
_*=payment_razorpay In This PR Razorpay payment onboarding form to take advantage of the Razorpay Connect Onboarding Flow. It integrates the Razorpay Onboarding using the IAP proxy. **Purpose**…
_*=payment_razorpay In This PR Razorpay payment onboarding form to take advantage of the Razorpay Connect Onboarding Flow. It integrates the Razorpay Onboarding using the IAP proxy. **Purpose** ======== Help users easily onboard with Razorpay by using the Razorpay Connect API. **Specification** =========== **1.Connect and authorized the razorpay account.** - To connect to a sub-merchant's Razorpay account, the application redirects the user to a Razorpay-hosted webpage. The user can approve or deny the authorisation request on this page. **2.Get an access token.** - After you obtain an access token, you can use it to access the sub-merchant data on Razorpay APIs. The access is controlled based on the scope requested for and granted by the user during the authorization process. **3.Get a refresh token.** - You can use refresh tokens to generate a new access token. If your access token expires, you will receive a 4XX response from the API. You can make a request using your refresh token to generate a new access token. **4.Revoke token.** - The API supports token revocation to enhance security and manage access. If needed, tokens can be revoked through this mechanism. **5.Create & update webhook.** - This method is responsible for creating or updating the Razorpay webhook associated with the current Odoo instance.The webhook is crucial for updating payment states within Odoo when changes occur in Razorpay. **6.Revoke the application from Razorpay.** - User can initiate the revocation of their application from the Razorpay side facilitating a seamless process for application revocation. task-3537535 Forward-Port-Of: odoo/odoo#158578
Steps to reproduce the bug: - Create storable products “P1,” “P2,” and “P3,” and update their quantities in stock. - Create a picking for one unit of P1 and P2. - Create a second picking for one unit of “P3.” - Mark both pickings as "To Do." - Set the move of P1 as "Picked." - Add both pickings to a new batch. - Try to validate the batch. - A wizard to create a backorder is triggered. - Discard the wizard Problem: The picking for P3 is detached from the batch. When validating th
Original PR description
Steps to reproduce the bug: - Create storable products “P1,” “P2,” and “P3,” and update their quantities in stock. - Create a picking for one unit of P1 and P2. - Create a second picking for one unit…
Steps to reproduce the bug: - Create storable products “P1,” “P2,” and “P3,” and update their quantities in stock. - Create a picking for one unit of P1 and P2. - Create a second picking for one unit of “P3.” - Mark both pickings as "To Do." - Set the move of P1 as "Picked." - Add both pickings to a new batch. - Try to validate the batch. - A wizard to create a backorder is triggered. - Discard the wizard Problem: The picking for P3 is detached from the batch. When validating the batch, empty or non-picked pickings are checked for detachment. Since the picking for P3 is not picked, it is marked to be detached: https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock_picking_batch/models/stock_picking_batch.py#L213-L214 https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock_picking_batch/models/stock_picking_batch.py#L201-L202 Afterward, we check if the other pickings can be validated. Since one move (P1) is picked and the other (P2) is not, the wizard to create a backorder is triggered, but the result is not checked, and detachment continues regardless: https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock_picking_batch/models/stock_picking.py#L125-L126 opw-4320352 Forward-Port-Of: odoo/odoo#187256
Versions -------- - 16.0+ Steps (16.0+) ------------- 1. Create a no-variant attribute with multiple values; 2. Create a product and assign it those attributes; 3. Add an extra product media from the sales tab; 4. Go to the website and add an extra image through the web editor; 5. Go back and check the extra product media field. The only image displayed is the one you uploaded in step 3. Issue ----- Both images should be shown as this product only has no-variant attributes so th
Original PR description
Versions -------- - 16.0+ Steps (16.0+) ------------- 1. Create a no-variant attribute with multiple values; 2. Create a product and assign it those attributes; 3. Add an extra product media from the sales tab; 4. Go to the website and add an extra image through the web editor; 5. Go back and check the extra product media field. The only image displayed is the one you uploaded in step 3. Issue ----- Both images should be shown as this product only has no-variant attributes so they don't create product variants. Cause ----- In Step 4, the uploaded image is saved to the product variant based on the evaluation of the `has_configurable_attributes` field on the product template and the presence of the variant. Solution -------- Check if the attributes are all `no_variant`. In that case, no product variant is created, so the images should be saved on the product template. opw-4174331 Forward-Port-Of: odoo/odoo#188019 Forward-Port-Of: odoo/odoo#187544
* Deferred expense: 110300 Prepayments (current assets) * Deferred revenue: 210900 Accruals (current liabilities) task-4338265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187704
Original PR description
* Deferred expense: 110300 Prepayments (current assets) * Deferred revenue: 210900 Accruals (current liabilities) task-4338265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187704
Before this commit, a KeyError would occur if 'entryPointType' was missing in the entryPoints dictionary. opw-4009884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188002
Original PR description
Before this commit, a KeyError would occur if 'entryPointType' was missing in the entryPoints dictionary. opw-4009884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188002
Before this commit, the profile picture of a user would affect the dimensions of the image element. This commit fixes the issue by enforcing an aspect ratio of 1. Forward-Port-Of: odoo/odoo#187830
Original PR description
Before this commit, the profile picture of a user would affect the dimensions of the image element. This commit fixes the issue by enforcing an aspect ratio of 1. Forward-Port-Of: odoo/odoo#187830
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#188235
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#188235
This PR fixes readability issues within the forecast details table. Prior to this PR, the table was using arbitrary color that were out of our color maps, meaning that they were not dark mode proof by default. As no variation was defined for these color in dark mode, some readability issues would occur in some cases (e.g link color over that background in dark mode). To handle this issue, we go back to basics and use Bootstrap default table utility classes, easing the maintenance and pr
Original PR description
This PR fixes readability issues within the forecast details table. Prior to this PR, the table was using arbitrary color that were out of our color maps, meaning that they were not dark mode proof by default. As no variation was defined for these color in dark mode, some readability issues would occur in some cases (e.g link color over that background in dark mode). To handle this issue, we go back to basics and use Bootstrap default table utility classes, easing the maintenance and preventing. readability issues. | 16.0 | This PR | |--------|--------| | <img width="459" alt="image" src="https://github.com/user-attachments/assets/571d9dea-2f42-479d-9fb1-85c9e1afbc76"> | <img width="451" alt="image" src="https://github.com/user-attachments/assets/121ec777-5a24-48da-912e-41f51e662e7a"> | task-4344045 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188308 Forward-Port-Of: odoo/odoo#187719
Steps to reproduce the issue: 1. Navigate to the Events page. 2. Activate the Web Editor. 3. Attempt to edit the Event's short description. Issue: The short description of the event was previously not editable directly from the Events page. the reason behind that is they have used `t-out` instead of `t-field` in template. `t-out` lacks the necessary attributes to enable field updates. Solution: This PR adds the necessary attributes to the short description element, making it editable
Original PR description
Steps to reproduce the issue: 1. Navigate to the Events page. 2. Activate the Web Editor. 3. Attempt to edit the Event's short description. Issue: The short description of the event was previously not editable directly from the Events page. the reason behind that is they have used `t-out` instead of `t-field` in template. `t-out` lacks the necessary attributes to enable field updates. Solution: This PR adds the necessary attributes to the short description element, making it editable from the Events page. Updated the tour functionality to test the latest changes of Event's short description. task-4014153 Forward-Port-Of: odoo/odoo#184263
Based on the received OXP feedback we are: * Activating cash basis by default. * All taxes are based on payment. task-4226448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188106
Original PR description
Based on the received OXP feedback we are: * Activating cash basis by default. * All taxes are based on payment. task-4226448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188106
Return newly created leaves after calling `hr.leave._split_leaves()` to improve inheritability by other modules --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186948
Original PR description
Return newly created leaves after calling `hr.leave._split_leaves()` to improve inheritability by other modules --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186948
Before this commit: Some logger.error(...) were ambigious and would just catch the exception to log it's error name without much details. Therefore it was wasting time trying to figure the cause of the error as we lack the traceback details After this commit: Most of them were switch to logger.exception which does add the Exception information to the logging messages automatically. Which include the error message alongside the full traceback. Log messages were also rewrote to be more
Original PR description
Before this commit: Some logger.error(...) were ambigious and would just catch the exception to log it's error name without much details. Therefore it was wasting time trying to figure the cause of the error as we lack the traceback details After this commit: Most of them were switch to logger.exception which does add the Exception information to the logging messages automatically. Which include the error message alongside the full traceback. Log messages were also rewrote to be more comprehensive than the: "An error encountered" Example of logs that would be improved: ``` 2024-11-19 07:19:50,611 1138 ERROR ? odoo.addons.hw_drivers.tools.helpers: Unable to load file: PrinterInterface_L.py 2024-11-19 07:19:50,612 1138 ERROR ? odoo.addons.hw_drivers.tools.helpers: An error encountered : (1280, 'Success') ``` Forward-Port-Of: odoo/odoo#187959 Forward-Port-Of: odoo/odoo#186162
It is not necessary useful to prevent the event in our case, so we can just stop doing it while maintaining the same functionality. Preventing the event writes a log in the console, and we prefer to avoid having a log if we can keep the service without it. Forward-Port-Of: odoo/odoo#188418
Original PR description
It is not necessary useful to prevent the event in our case, so we can just stop doing it while maintaining the same functionality. Preventing the event writes a log in the console, and we prefer to avoid having a log if we can keep the service without it. Forward-Port-Of: odoo/odoo#188418