Tuesday, April 9, 2024
27 changes
2 changes
Resolved issues and error corrections
Uploading a file in a newly opened live chat now works reliably instead of causing an error. The system now saves the chat on the server before starting the upload, improving the support experience for users and agents.
Original PR description
Before this PR, uploading a file to a temporary thread would lead to errors because the thread only exists locally. This PR ensures the thread is saved on the server before uploading like it's done when a message is posted. This PR adapts the attachment upload service to rely on models instead of components: - Service should not be coupled to views - Thread is updated when calling `uploadFile` so the hook passed to this function is outdated and we cannot access the new thread hook (it's not even mounted yet). Steps to reproduce the issue: - Log in as admin - Go to the live chat support page - Open a chat - Click on upload file and upload one - Crash occurs https://github.com/odoo/enterprise/pull/60165
Reloading a product page opened from Physical Inventory no longer triggers an error page. This keeps inventory workflows stable and prevents customers from being interrupted by a traceback when refreshing the browser.
Original PR description
When the customer opens the product from Physical Inventory and tries to reload the page, a traceback will appear. Steps to reproduce the error: - Go to Inventory > Operations > Physical Inventory -…
When the customer opens the product from Physical Inventory and tries to reload
the page, a traceback will appear.
Steps to reproduce the error:
- Go to Inventory > Operations > Physical Inventory
- Open any product > reload the page
Traceback:
```
KeyError: 'display_name'
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, 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 1825, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = 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 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/action.py", line 74, in load_breadcrumbs
name = act['display_name'] if any(view[1] != 'form' and view[1] != 'search' for view in act['views']) else None
```
https://github.com/odoo/odoo/blob/853bd97eda1f4eca5f9f63ef1c5909fddaa98d27/addons/stock/models/stock_quant.py#L388-L396
Here, 'display_name' key is not present.
https://github.com/odoo/odoo/blob/853bd97eda1f4eca5f9f63ef1c5909fddaa98d27/addons/web/controllers/action.py#L74 When Customer reloads the page,
It will try to access 'display_name' here, but it is not present.
So, It will lead to the above traceback.
sentry-5132471164
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr23 changes
Resolved issues and error corrections
This fix improves how payment registrations are handled when dealing with invoices in different currencies. Instead of creating write-offs, the system now intelligently uses exchange rate adjustments to fully reconcile payments without leaving unpaid balances. This ensures cleaner financial records and more accurate payment processing for businesses operating with multiple currencies.
Original PR description
When a register payment is made with a writeoff in foreign currency and when the user set manually an exchange difference account, don't create a write-off. Instead, 2 cases to consider: - When the payment is expressed in a foreign currency different than the invoice's one, play with the rate between amount_currency and balance and let odoo making an exchange difference accordingly. That way, the payment has no write-off and the invoice is fully paid. - When the payment is expressed in company currency but the invoice has a foreign currency, force the exchange difference to use a rate that will fully paid the invoice without creating any write-off line on the payment. task_id: 3717436
This fix resolves a system error that occurred when customers removed pickup or return dates from rental products in their shopping cart. The issue has been corrected so customers can now modify rental dates without encountering errors, improving the rental checkout experience.
Original PR description
… the cart -> 17.0 Steps to reproduce : -> Add a rental product to your cart with a rental period -> Go to the cart -> Remove one of the date from the rental period (either pickup date or return date) Issue : -> Get this traceback Cause: -> when we remove the date from the cart we find a traceback of 'start_date'. Solution: -> Added the condition so if the we remove the start date or end date we not get the traceback. opw-3638268
This fix resolves an issue where rental products with serial number tracking were not displaying correctly in the Schedule view when the Rental Transfers feature is enabled. The system now properly captures and displays serial number information for all rental orders, allowing users to accurately group and organize rentals by serial number in the Gantt view.
Original PR description
**Current behavior:** The `rental.schedule` model/view does not have serial number data for order lines which are constructed while the `Rental Transfers` config option is active. This prevents the…
**Current behavior:** The `rental.schedule` model/view does not have serial number data for order lines which are constructed while the `Rental Transfers` config option is active. This prevents the view from accurately grouping by serial number. **Expected behavior:** The schedule view will correctly group the records in this gantt view. **Steps to reproduce:** 1. Create a new rental product, ensure it has the 'By Unique Serial Number' tracking option 2. Create an on hand instance of this product with a serial number 3. In Rental settings, enable the `Rental Transfers` option 3. Create a new rental order for this product, go to the `Schedule` view in the Rental app, select Group By Serial Number, observe that the new order is listed as having an undefined serial number **Cause of the issue:** When the Rental Transfers option is enabled, the wizard which normally tracks rental pickups/returns gets circumvented to instead get organized via stock. The SQL view for the schedule model only looks in the tables managed by this wizard to find lot_ids of products included in rental orders. So when we don't use the wizard, that information never makes it to the proper place. **Fix:** Union the current view's table result with another query which will select the data for the excluded records. opw-3754422
This fix resolves a crash that occurred when users in Philippine companies tried to change filter options in the Sales and Purchases summary report. The issue was caused by the system not properly handling empty data fields during report formatting, which has now been corrected to prevent the error.
Original PR description
### Steps to reproduce 1. Install "l10n_ph" 2. Switch to PH Company 3. Accounting / Reporting / Partner Reports / Summary Lists of Sales and Purchases 4. In the options/filters, change the "In" field You will be met with a traceback: `KeyError: 'no_format'` opw-3805585
The Profit and Loss report for Belgium was showing too much detail by breaking down the "Profit (Loss) of the Preceding Period Brought Forward" line into individual accounts. This change simplifies the report to display only the total amount, making it cleaner and easier to read for users.
Original PR description
In the "Profit and Loss" report, the `14P - Profit (Loss) of the Preceding Period Brought Forward (+)/(-)` line is grouped by account_id, showing then all the accounts from the preceding period that impact the final amount. Which provides a lot of information that may be too much. Only the total amount should be displayed. opw-3810161
This fix corrects how the progress percentage is calculated for resource schedules in the Planning module's Gantt view. Previously, the percentage calculation was incorrect and always displayed as 0%. Now the percentages will display accurately, helping managers better track resource utilization and scheduling progress.
Original PR description
**Steps to reproduce:** 1- Install Planning module 2- Go to gantt view for Schedule by Resource 3- Check percentage for any row that has planned shift **Current behavior before PR:** The percentage of progress of each resource is calculated in a wrong way https://github.com/odoo/enterprise/blob/17.0/planning/static/src/views/planning_gantt/planning_gantt_model.js#L135 The ratio is already the value of the decimal multiplied by 100 so when divide it again by 100 then round it, it will always give 0 **Desired behavior after PR is merged:** Since ratio is already multiplied by 100 and it will be formatted as percentage by multiply it again by 100 through 'formatPercentage' so we divide it by 100 without rounding it. opw-3796124
This fix removes the 'Request EDI Cancellation' button that was incorrectly appearing on Colombian invoices after they were sent through the EDI system. Since Colombian tax regulations do not allow cancellations of invoices that have been submitted to the government, users will no longer see this button or encounter errors when attempting to use it. Instead, they will need to follow the proper process of creating a credit note.
Original PR description
Currently, when a Colombian invoice has been sent through the EDI, a 'Request EDI Cancellation' button appears on the form view. This button shouldn't be there, as the cancellations process is not…
Currently, when a Colombian invoice has been sent through the EDI, a 'Request EDI Cancellation' button appears on the form view. This button shouldn't be there, as the cancellations process is not allowed in Colombia. ### Steps to reproduce * install `l10n_co_edi` * switch to a Colombian company and set up the EDI * create, confirm, and send an invoice * once the invoice has been successfully sent, attempt to cancel it using the 'Request EDI Cancellation' button. The invoice will be marked as `to cancel`. Odoo will then periodically try to cancel it, but it will never succeed because Colombian invoices that have been sent to the government cannot be reset to draft. If the cancellation process is initiated by the user (either by manually running the EDI services cron, or using the 'Process Now' button on the form view) the following error message appears: > You can't edit the following journal entry [journal name] because an electronic document has already been sent to Carvajal. To edit this entry, you need to create a Credit Note for the invoice and create a new invoice. opw-3754395 Forward-Port-Of: odoo/enterprise#59749
Fixed a bug in Ecuador's tax withholding system that was causing errors when users accidentally added multiple withholdings to the same vendor invoice. The system now prevents users from linking more than one withholding to a single invoice, ensuring accurate tax reporting and preventing system crashes when generating tax reports.
Original PR description
With an EC company setup Create a vendor bill Add 2+ withholding via the 'Add Withhold' Go to Accounting > Reports > Tax Report Set the month to this month, make sure report 103 is selected, then click the drop down menu for the PDF to select ATS Issue: Traceback It occurs because the user should not be able to add multiple posted withholds to the same invoice opw-3793714 Forward-Port-Of: odoo/enterprise#59679
This fix ensures that when messages are updated in Discuss channels, the information sent to users is read directly from the database rather than from temporary values. This prevents users from seeing outdated or incorrect message information and improves the reliability of the messaging system.
Original PR description
When writing in a discuss channel, the updated value sent to the client should be read from the database, not directly from the values passed to the write method. Partially backport of https://github.com/odoo/odoo/pull/139563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users were unable to smoothly type URLs when adding media to content blocks because the interface kept re-rendering and losing focus on the input field. This fix resolves the focus loss issue that occurred after a recent migration from jQuery to Owl components, making it much easier for users to enter media URLs without interruption.
Original PR description
Video to reproduce on runbot odoo CE 17: https://github.com/odoo/odoo/assets/56789189/dcece1e9-9f33-4734-8cfa-aac012ec71e5 -Step to reproduce: + Add a block contain media + click on it and try to set…
Video to reproduce on runbot odoo CE 17: https://github.com/odoo/odoo/assets/56789189/dcece1e9-9f33-4734-8cfa-aac012ec71e5 -Step to reproduce: + Add a block contain media + click on it and try to set url for it to redirect + when typing the ui keep rerender and after render the autocomplete element it not focus back to the url input which cause user really struggle in typing unless they have a very quick hand -Reason: Since [1] we have migrated jQueryUI `urlautocomplete` to owl component , this add multiple event for the input element which the 'input' event is fire first when user type for url then it will try to trigger change for the url to include 'http' or 'https' after the change the element won't focus on the input itself which is a very bad behaviour [1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bed 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
This fix resolves an issue where expense reports were generating duplicate log notes every time the page was refreshed. The problem was caused by unnecessary quantity assignments in the expense module that were triggering unwanted system logs. This fix ensures that expense reports display cleanly without spurious activity logs.
Original PR description
Steps to reproduce: - with demo data - go on expense report - open the report from marc demo - refresh Issue: New log note on each refresh Note: Issue happening only in 17 commit introducing the bug: https://github.com/odoo/odoo/commit/f261c83b0dbc27dacc9cd0e0d935d52626723dac opw-3817367
This update fixes how the system handles electronic invoices for customers located in San Marino. Previously, San Marino customers were treated as non-EU countries, resulting in incorrect destination codes and VAT numbers in generated invoices. The system now correctly applies San Marino's specific destination code (2R4GTO8) as required by Italian tax regulations since October 2021, ensuring compliance with electronic invoicing requirements.
Original PR description
Steps to reproduce: - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts and create a contact from San Marino: * Name: SM customer *…
Steps to reproduce: - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts and create a contact from San Marino: * Name: SM customer * Country: San Marino * Street, City, ZIP: [any] * Destination Code: [any] - Create an invoice: * Customer: [the created contact from San Marino] * Product: [any] - Confirm the invoice - Generate E-invoice XML via "Send & Print" button Issue: In the XML, the destination code (i.e. CodiceDestinatario) is the default one for non-Italian customer (i.e. XXXXXXX). Also, the VAT number (i.e. IdFiscaleIVA) is the default value for countries that are not in the European Union (i.e. OO99999999999). However, since October 2021, San Marino should be handled differently for Italian electronic invoices. A specific destination code (i.e. 2R4GTO8) should be used for all customers from San Marino. Source: https://www.credemtel.it/fattura-elettronica/fattura-elettronica-san-marino/ Solution: For customers from San Marino: - Keep VAT number - Set "2R4GTO8" as destination code opw-3819054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an illogical configuration in the time off accrual system where capping accrued time with zero maximum days would block all future allocations. The system now enforces that when capping accrued time is enabled, a meaningful maximum leave value must be set to ensure employees continue to receive time off allocations.
Original PR description
Steps to reproduce:
-------------------
- create a time off accrual plan with:
- cap accrued time equals to `True`
- maximum leave equals to `0 days`
- create an allocation with this accrual plan
- run the scheduled action "Accrual Time Off: Updates the number of time off"
(make sure you have the right "lastcall" and "nextcall")
Issue:
------
The number of days of the allocation is set to zero. This scenario makes no sense from a business point of view. In effect, we are blocking the accumulation of allocations at zero. The result is that there will never be any days allocated to these allocations.
Solution:
---------
Add a constraint to force a maximum leave number when cap accrued time is set.
opw-3847408This fix ensures that when creating product documents in the PDF Quote Builder, only PDF files can be saved. Previously, the validation check only occurred when editing existing documents, allowing non-PDF files to be saved during creation. This update closes the gap and maintains data integrity across all document operations.
Original PR description
When creating a product document, it was still possible to save something that wasn't a pdf. The check only happened when modifying it. opw-3802795
This fix prevents an error message from appearing when users click the confirm button while creating a time off request that doesn't require validation. The confirm button is now hidden during the creation process, ensuring users can only confirm after the request is properly saved, which eliminates unnecessary error messages.
Original PR description
Description of the issue/feature this PR addresses: In odoo V17 if a user is creating a holiday request for a time of type that requires no validation, the confirm button is visible during the…
Description of the issue/feature this PR addresses: In odoo V17 if a user is creating a holiday request for a time of type that requires no validation, the confirm button is visible during the creation process due to this line https://github.com/odoo/odoo/blob/2876b8300d1f9a740deb0faa02399df2426df402/addons/hr_holidays/views/hr_leave_views.xml#L248 in prior versions this was not the case https://github.com/odoo/odoo/blob/391a427620b6aec690481fe7c7d0b0326b95ee8c/addons/hr_holidays/views/hr_leave_views.xml#L238 So due to this change in Odoo V17 the confirm button is visible to the user while creating (before saving) so if the user clicks on the confirm button the behavior is it will save the record then set its state to confirm then will call action validate (all in the create function) after the execution of the create is finished it will call `action_confirm` which in turn will raise the user error. I added a check in the action confirm function to check if the time off requires no validation. alternatively I can revert the changes and add the `id == False` in the condition for the `action_confirm` button action. Current behavior before PR: A user error message is raised if the user clicks on the confirm button. see issue #160831 Desired behavior after PR is merged: No user error message that happens if the user clicks on the confirm button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents support tickets from different customers using generic email providers (like @proton.me, @cegetel.net, and @dbmail.com) from being incorrectly grouped together. The system now recognizes these as personal email domains rather than company domains, ensuring that tickets from different customers are properly kept separate.
Original PR description
## Issue: - When we have open tickets from anyone with the email domain @proton.me, they are linked together even though this domain is generic, not a private one. same issue with @cegetel.net and…
## Issue: - When we have open tickets from anyone with the email domain @proton.me, they are linked together even though this domain is generic, not a private one. same issue with @cegetel.net and @dbmail.com ## Steps To Reproduce: - Create three tickets with "@proton.me" domain but different addresses. - See that in the smart button, the tickets are linked to each other even though the customers are different. ## Solution: - in `_compute_partner_ticket_count` we check if the email domain of the partner is in `iap_tools._MAIL_DOMAIN_BLACKLIST `, if not, we considers the email to be a company email which tickets can be grouped by. - the `_MAIL_DOMAIN_BLACKLIST` is a list of generic email providers on which IAP services should not run. Retrieving company information from them makes no sense. - To fix this issue I added `proton.me` , `cegetel.net` and `dbmail.com` to `_MAIL_DOMAIN_BLACKLIST` opw-3786308 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159321
This fix corrects an issue where journal entries created from company-paid expense reports were all assigned the same date, regardless of when individual expenses occurred. Now each journal entry will properly reflect the actual date of the corresponding expense, ensuring accurate financial records and better audit trails.
Original PR description
Before when we create an expense report paid by company with multiple expenses of different dates then we posted the expense report. The journal entries had all the same date. Now journal entries will match the date of the expense when it is an expense paid by company. Signed, Logan Staelens lost@odoo.com https://github.com/lost-odoo Forward-Port-Of: odoo/odoo#159083
This update improves the error messages displayed when users encounter issues on public discussion pages. Instead of cryptic technical errors that are difficult to understand and report, users will now see clearer, more user-friendly messages that help them better understand what went wrong.
Original PR description
Before this PR, the error displayed in the public page was quite cryptic. It was hard for the user to understand that error and even harder to report it if needed. This PR makes the error more user friendly. task-3850559
This fix resolves an issue where document headers in boxed layout PDFs were overlapping and cropping the body content on pages after the first page. By reducing unnecessary whitespace in the header design, the header now fits within the standard page margins, ensuring all document content displays correctly across all pages.
Original PR description
### Steps to reproduce issue: 1. Select a boxed layout document 2. Create an invoice and add lines until the pdf version is on two pages 3. Print the pdf 4. On every page except the first one, the body of the document is cropped by the header ### Explanation: The PDF consists of three parts: the header, the footer and the body, and they are added separately. The body is delimited by the paper format and margins. Those do not depend on the size of the header and the footer. In the boxed layout, the height of the header is bigger than the default size of the top margin of the body. Because of that, it covers a part of the body. ### Suggested fix: By removing some whitespace, the header size has been reduced to a size smaller than the default margins of the document while keeping every information readable. opw-3768511 Forward-Port-Of: odoo/odoo#160770 Forward-Port-Of: odoo/odoo#159125
This fix corrects a language inconsistency on the email unsubscribe page where some text was displaying in the user's language instead of the website's language. The fix ensures all content on the unsubscribe page displays in the correct language by properly setting the language attribute, providing a consistent user experience for customers in different regions.
Original PR description
### Steps to reproduce issue: 1. Download two languages, set one as the user's language, the other as the website's 2. Make sure MailHog is running 3. Create a Mailing Contact with two different…
### Steps to reproduce issue: 1. Download two languages, set one as the user's language, the other as the website's 2. Make sure MailHog is running 3. Create a Mailing Contact with two different Mailing Lists 4. Create a mail with a link to unsubscribe 5. Send mail to one of the Contact's Mailing lists 6. Through MailHog, click on the subscription cancelling link 7. The first line is in the user's language and the others in the website's language ### Explanation: While most of the webpage originates from an XML file, translated using the language of the website. https://github.com/odoo/odoo/blob/2ad911dab1f34b1b6dda1016cc189f0fea64b12c/addons/mass_mailing/views/mass_mailing_templates_portal.xml#L118 The first line is passed through javascript and translated on the fly. https://github.com/odoo/odoo/blob/efd178daee689192d4e930a075475587038b3e0d/addons/mass_mailing/static/src/js/unsubscribe.js#L50-L55 The line is translated thanks to an object fetched at the load of the page. The url where the object is located can receive parameters including the language, but defaults to the user's and is not set in our case. https://github.com/odoo/odoo/blob/0ca2ca9e8914dda77166b62dc8c2e9dc1ca1d3a4/addons/web/static/src/legacy/js/core/translation.js#L73-L78 ### Suggested fix: The language can be passed through the attribute `lang` of the document. https://github.com/odoo/odoo/blob/658bc65b22dba86a35f6bba0f892427e1be4aed1/addons/web/static/src/legacy/js/core/session.js#L205-L211 https://github.com/odoo/odoo/blob/e251354ce4b7df1763247385413e98f975981479/addons/web/views/webclient_templates.xml#L10 This option is already used in `website` and, [since 16.0](https://github.com/odoo/odoo/commit/5136ac7e4daaadda396c45c8538a81f8d6c44c0e), is inherited once `website` is installed. https://github.com/odoo/odoo/blob/c3c8003c6d1c4d694531c93e803e7e9cd7ebaa83/addons/website/views/website_templates.xml#L39-L50 opw-3748027 Forward-Port-Of: odoo/odoo#160697 Forward-Port-Of: odoo/odoo#159341
Fixed a visual bug where spaces between rating icons would disappear when users changed the score in the rating snippet. The issue was caused by a jQuery library update that changed how HTML tags are processed. The fix ensures proper spacing is maintained between icons regardless of score changes.
Original PR description
To reproduce the issue: -Drag and drop the rating snippet. -Change the score from options. -Notice that spaces between icons disappear. Specification: In the release notes[[1]](…
To reproduce the issue: -Drag and drop the rating snippet. -Change the score from options. -Notice that spaces between icons disappear. Specification: In the release notes[[1]]( https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/) of jQuery 3.5.0, it's stated that security fixes related to the HTML parser were implemented. Consequently, self-closing e.g. `<i/>` tags inside function arguments were replaced with e.g. `<i></i>`. As a result, trailing spaces lost significance, causing icons to stick together. Prior to Odoo 16.2, jQuery 3.3.1 was utilized, which allowed the use of self-closing tags in the append function. This behavior was as expected.However, starting from Odoo 16.2, jQuery version 3.6.3 was adopted. After this PR: Instead of using self-closing `<i/>` tags, `<i></i> ` with a trailing space was used. This trailing space gained significance due to the prefilter no longer ignoring it. Consequently, icons no longer stick together after changing the score. task-3576760 Forward-Port-Of: odoo/odoo#160061
Mauritius phone numbers were not being recognized correctly, causing WhatsApp messages to fail with an "Invalid number" error. This fix updates the phone number parsing library to properly handle Mauritius phone numbers, allowing users to successfully send WhatsApp messages to contacts in Mauritius.
Original PR description
When the user adds a valid Mauritius phone number, it is not correctly parsed by the phonenumbers library, resulting in a user error while sending a WhatsApp message to that number. Steps to produce: - Create a new contact with the Mauritius country selected. - Add a phone number (e.g., '+23057654321'). - Try to send WhatsApp messages using this phone number. - This will throw an Invalid number error. Problem: `phonenumbers==8.12.1` python library is used in odoo for parsing phone numbers. The `8.12.1` version is too old and cannot parse Mauritius phone numbers correctly. Solution: The `8.12.13` version accurately parses Mauritius phone numbers. Currently, The latest version of the phonenumbers library is `8.13.31`. Hence, the latest code from the latest version of the phonenumbers library is monkey-patched into the system. Task - 3799632 Forward-Port-Of: odoo/odoo#160956 Forward-Port-Of: odoo/odoo#157504
This fix improves the reliability of deleting messages and attachments in the mail system. Previously, items would disappear from the user's screen before being confirmed deleted in the database, which could cause confusion if the deletion failed. Now the system confirms the deletion in the database first before removing items from the screen, ensuring a more reliable user experience.
Original PR description
**Current Status** - when remove attachment or message, The system will perform deletion on the interface before performing deletion in the DB. However, in some situations, exceptions will occur during the deletion process. So it will happen that the attachment or message has been deleted on the interface but still exists under the database. From a function that helps optimize user experience, it will cause a worse situation with user experience **Solution** - Make rpc calls before deleting messages or attachments on the interface 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