Daily updates from Odoo
Thursday, January 15, 2026
24 changes · saas-18.3
Resolved issues and error corrections
This update resolves a migration issue preventing the Odoo 18.3 version from properly updating from 16.0 for Italian businesses. The fix adds a missing column, 'l10n_it_exempt_reason', required during the migration process. This ensures a smooth and successful upgrade for Odoo's Italian localization.
Original PR description
Migration from 16.0 fails because l10n_it_exempt_reason column does not exist Forward-Port-Of: odoo/odoo#240862
This update resolves a technical issue that prevented the creation of payroll rule parameters with future dates, resulting in a system error. The fix ensures that the system correctly handles these parameters, improving the stability and usability of the payroll configuration. This change avoids potential disruptions to payroll processing.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500
Forward-Port-Of: odoo/enterprise#102924This update fixes a display issue in the restaurant order preparation screen (PDIS) where the first course's timer incorrectly showed 0 until the second course was initiated. Now, each course accurately reflects its preparation time when it's added to the order, ensuring accurate timing for kitchen staff and customers.
Original PR description
Before this commit: -- - In the preparation display (PDIS), the first course shows a preparation time of 0 untill the second course is fired. - After course 2 fired, course 1 and course 2 have same preparation time value. After this commit: -- - Each course shows its correct preparation time when fired. task-5421616 Forward-Port-Of: odoo/odoo#241251
This update corrects an issue where product references were appearing in the names of products displayed on the website's product carousel. This change ensures that product names are clean and accurate, improving the user experience for customers browsing our online store. The fix was triggered by a specific configuration with a single value in a free text attribute.
Original PR description
**Issue**
When a product has a free text attribute with one value, the product reference appears in the name of the product on the product carousel.
**Expected behavior**
The product reference should not appear in the name of the product on the product carousel.
**Steps to reproduce**
1. Create a product to be sold online
2. Give it an internal reference
3. Add a free text attribute with one value
4. Set a product carousel on a website page
5. Disable "show variants" in the settings of the carousel
=> The product reference appears in the name of the product
**Note**
The issue happened only if the free text attribute has only one value, with more than one value, the product reference did not appear.
**Fix**
Updated the QWeb template to use the prepared clean title with data.get('display_name') instead of record.display_name
opw-5410822
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242791This update adds two missing Unit of Measure (UoM) codes – MIN (Minute) and KWH (Kilowatt hour) – to Odoo, aligning with UNECE Recommendation No. 20 for Peppol. This ensures proper support for UBL/CII electronic invoices, resolving an issue where the default 'Units' code was used instead, and addresses a need identified by localization modules.
Original PR description
**Issue:** 2 UoM that is in the UNECE Recommendation No.20 for Peppol don't exist in Odoo: - MIN: Minute - KWH: Kilowatt hour Even if they are created manually, they are not used in the UBL/CII electronic invoices. Instead, the default code (i.e. "C62" for "Units" is used). Some localization modules create the "Kilowatt hour" UoM as they need it. (l10n_cl and l10n_tr_nilvera) So it's better to have a "generic" one available for every module. opw-5269119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243535 Forward-Port-Of: odoo/odoo#238342
This update fixes a validation error that occurred when creating partial backorders within wave transfers. The issue stemmed from the system incorrectly identifying an active batch as a candidate for new backorders, leading to a user error. This change ensures that the current batch is excluded during the auto-batch process, resolving the validation conflict.
Original PR description
## How to reproduce: - Enable Wave transfert in setting - Go to the Receipt Operation type: - Create Backorder: always - Automatic Batches: Enabled - Wave Grouping: Products - Create and confirm…
## How to reproduce:
- Enable Wave transfert in setting
- Go to the Receipt Operation type:
- Create Backorder: always
- Automatic Batches: Enabled
- Wave Grouping: Products
- Create and confirm (don't validate) 2 Receipts for 10 units of a storable product P
- The 2 receipt should have been added to a new wave transfer with 2 lines for P
- On the first line, set the quantity to 0
- On the second line, set the quantity to 1
- Try to validate the wave transfer ==>> UserError "The following transfers cannot be added to batch transfer WAVE/XXXX. Please check their states and operation types."
## Issue:
Backorders are generated before the current batch is marked 'done' (it waits for empty pickings to be detached). The auto-batch logic incorrectly identifies the current 'in_progress' batch as a candidate for the new backorders, attempting a merge that violates validation constraints.
## Solution:
Exclude the current wave/batch from the auto_wave search domain using a context variable passed during validation.
OPW-5413921
---
Test result before fix:
```
2026-01-13 10:37:26,541 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: Starting TestAutoWaving.test_auto_wave_skip_current_batch ...
2026-01-13 10:37:26,820 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ======================================================================
2026-01-13 10:37:26,820 27952 ERROR oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ERROR: TestAutoWaving.test_auto_wave_skip_current_batch
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/tests/test_auto_waving.py", line 440, in test_auto_wave_skip_current_batch
wave.action_done()
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 264, in action_done
return pickings.with_context(**context).button_validate()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 145, in button_validate
res = super().button_validate()
^^^^^^^^^^^^^^^^^^^^^^^^^
...
File "/home/odoo/Odoo/src/18.0/odoo/odoo/fields.py", line 1418, in __set__
records.write({self.name: write_value})
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 112, in write
self.batch_id._sanity_check()
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 323, in _sanity_check
raise UserError(_(
odoo.exceptions.UserError: The following transfers cannot be added to batch transfer WAVE/00012. Please check their states and operation types.
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243519This update corrects a bug where clicking 'Back' in the cart sometimes caused unexpected product additions. The fix clarifies the trigger used to add products, preventing duplicate actions and ensuring consistent cart behavior. This improves the overall user experience and reduces potential errors during checkout.
Original PR description
Before this commit, trigger to click on a product in the product list was the same trigger to click on a product in a cart list ... With the following scenario, step CartPage.clickBack() can take few…
Before this commit, trigger to click on a product in the product list was the same trigger to click on a product in a cart list ...
With the following scenario, step CartPage.clickBack() can take few times to show the back screen, but as the trigger is the same for clickProduct on a product list screen than a cart screen, the last step clik on "o_self_product_box" ... but in the cart (and not in the product list)
ProductPage.clickProduct("Coca-Cola"), => OK
ProductPage.clickProduct("Coca-Cola"), => OK
Utils.clickBtn("Checkout"), => OK
CartPage.checkProduct("Coca-Cola", "5.06", "2"), => OK CartPage.clickBack(), => OK
ProductPage.clickProduct("Coca-Cola"), => NOK
To fix it, it is enought to just be more precise on the trigger to avoid confusions.
This fix fixes probably a pair of tours.
error-runbot-id~227669
(and probably others)
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-prThis update fixes an issue where the DDT number was missing from delivery confirmation reports for Italian companies. The change ensures the DDT number is generated and included before the email is sent, resolving a reporting discrepancy. This improves the accuracy and completeness of delivery documentation.
Original PR description
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending…
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending the email. Steps to reproduce: - Create a database with an Italian company and the `l10n_it_stock_ddt` module installed - Turn on `Settings > Inventory > Shipping > Email Confirmation` - Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates` - Edit the `Shipping: Send by Email` template - Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`. - Create a SO, validate it - On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery. - In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name. - If you open the report, the title of the PDF is also missing the DDT name. Ticket [link](https://www.odoo.com/odoo/project.task/5364265) opw-5364265 Forward-Port-Of: odoo/odoo#243492
This update automatically corrects discrepancies between check amounts and payment amounts when using third-party checks for vendor payments. Previously, users had to manually adjust payment amounts, leading to errors and delays. This change ensures accurate payment processing and eliminates manual intervention.
Original PR description
Current behavior: when using third-party checks to create vendor payments, withholding amounts are creating a difference between the checks amount and the payment amount, resulting in a warning and requiring manual adjustment of the payment amount until the amount minus withholdings matches checks amount. Solution: adding an automated adjustment algorithm to the wizard. task-4257629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219922
This update resolves an issue where group chat channels (group DMs) were displaying incorrect status information, leading to confusing user experiences like a 'back on' banner and incorrect IM status. The fix removes a calculation that caused this behavior, ensuring group DMs display their status accurately.
Original PR description
Before this commit, the "correspondent" property of Thread would be computed for channels of type group (group DMs) having less than 3 members. This would lead to various confusing behaviours, including: 1. The "back on" banner being shown. 2. The chat bubble showing an IM status. 3. The notification item not showing the message author's name. This commit fixes the issues by not computing `correspondent` for channels of type group. task-5462395 Forward-Port-Of: odoo/odoo#243628 Forward-Port-Of: odoo/odoo#242058
This update resolves an issue where users were blocked from settling customer balances in Point of Sale when ZATCA integration was active. The fix removes the forced invoice requirement for settlement orders, allowing users to complete payments without generating duplicate e-invoices to ZATCA.
Original PR description
## Dependent PR https://github.com/odoo/enterprise/pull/98463 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale…
## Dependent PR https://github.com/odoo/enterprise/pull/98463 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled. ## Current behavior before PR: When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA. However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because: - Settlement orders do not contain any lines, so a new invoice cannot be generated. - The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice. Thus, the user cannot proceed with the settlement. ## Desired behavior after PR is merged: After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243604 Forward-Port-Of: odoo/odoo#233769
This update resolves an issue where a Point of Sale order incorrectly remained flagged as a 'settlement' after a user canceled a payment attempt. By resetting the order flag, this prevents incorrect processing and ensures compliance with integration rules. This improves order accuracy and avoids potential errors.
Original PR description
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current…
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current behavior before PR: When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True. This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this. ## Desired behavior after PR is merged: After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. task-id - 5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#104197 Forward-Port-Of: odoo/enterprise#98463
This update fixes a reporting issue related to Bebat, a Belgian organization recycling batteries. It ensures that recycling taxes are correctly identified as 'Special Agreement' (64) or 'Battery Collection and Recycling' (CAV) instead of the previous 'New Outlet Discount' (66) or 'Collection and recycling' (AEO) classifications, aligning with regulatory requirements.
Original PR description
[FIX] account_edi_ubl_cii: EPD allowance/charge code should be 64, not 66 64 stands for "Special agreement" 66 stands for "New outlet discount" opw-5478324 [FIX] account_edi_ubl_cii: Bebat allowanceChargeReasonCode should be CAV Bebat is a non-profit organization in Belgium that collects, sorts, and recycles used batteries. Currently, whatever the recycling tax applied, we report is as AEO for "Collection and recycling - The service of collection and recycling products." However, since Bebat is about recycling batteries, we have to use CAV instead for "Battery collection and recycling - The service of collecting and recycling batteries." opw-5474752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243064
This update ensures that rating cards are only shown in the portal chatter for modules that specifically request their display. Previously, rating cards were sometimes shown even when not intended, leading to a cluttered user experience. This change improves the portal's clarity and relevance by aligning rating displays with module functionality.
Original PR description
*: test_mail_full Modules using portal rating can set an `data-display_rating` attribute when calling the portal chatter template to indicate whether they want the rating feature displayed. Currently, only two modules have this attribute set to true: ecommerce and elearning. For other modules that don't set this attribute, even if there is a rating, such as when rating a ticket in the helpdesk module, we don't want the rating card feature to be shown in portal chatter. This change ensures that the feature is only available if the module requests it. task-5347848 Forward-Port-Of: odoo/odoo#243495 Forward-Port-Of: odoo/odoo#243255
This update resolves an issue where the HTML editor was incorrectly adding tab characters to content, particularly when users selected mixed block types. The fix now ensures that tabs are only applied to contenteditable paragraph blocks (like headings and paragraphs), improving the editor's consistency and usability. This prevents unexpected indentation and ensures a smoother editing experience.
Original PR description
#### Description of the issue this PR addresses: - Tab indentation was applied to non-paragraph and non-contenteditable blocks, leading to incorrect indentation behavior when a selection contained mixed block types. #### Desired behavior after PR is merged: - Filter selected blocks to indent only contenteditable paragraph-related elements (h1–h6, p, pre, blockquote, and div.o-paragraph), while excluding blocks marked as contenteditable="false". #### Steps to Reproduce: - Open a new to-do record. - Insert: Table, Table of Content, Banners, attachment, (18.2 - Toggle List) - Select all editor content using Ctrl + A. - Press the Tab key multiple times. => Multiple editor tab characters are inserted at unintended positions. task-5452410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241806
This update fixes an issue where products created through the website automatically appeared as published, even without a category assigned. The change removes a setting that forced publication and ensures products remain unpublished until a category is selected, aligning with the user's expected experience. This improves the consistency and usability of the website's product creation process.
Original PR description
**Description:** Products created from the website frontend were automatically published even without a category assigned, contradicting the "Unpublished" placeholder expectation. The issue had three root causes: 1. JavaScript (new_content.js) forced default_is_published: true 2. XML action context contained website_published: True 3. Both caused products to be published regardless of category **Fixed by:** - Removed default_is_published from JS product creation handler - Removed website_published from action context. **After this PR:** Now products remain unpublished until a category is assigned, matching the intended UX indicated by the placeholder text. opw-5408903 SEE ALSO: Enterprise PR:https://github.com/odoo/enterprise/pull/103778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242779
This update ensures the website's product barcode lookup functionality correctly handles products created without a category selection. It aligns the test with a recent community change, preventing issues where newly created products weren't automatically published. This ensures a smoother user experience for customers creating products through the website.
Original PR description
Align barcodelookup website test with the community change where products created from the website are not auto-published when no category is selected. opw:5408903 SEE ALSO: Community PR:https://github.com/odoo/odoo/pull/242779 Forward-Port-Of: odoo/enterprise#103778
A technical issue with WebKit was preventing users from properly scanning barcodes on iOS devices. This resulted in a white square obscuring the scanning area. This update resolves the problem by addressing a bug in WebKit's blend-mode functionality, ensuring accurate barcode scanning.
Original PR description
Issue ----- There is an issue in WebKit with mix-blend-mode https://bugs.webkit.org/show_bug.cgi?id=286619 Because of this issue, in barcode, the user gets a solid white square over the scanning zone, so they don't see the barcode being scanned. ----- Ticket: opw-5386846 Forward-Port-Of: odoo/odoo#243486
This update resolves an issue where URLs were appearing twice in WhatsApp messages due to a formatting error in how the Odoo UI's HTML was converted to plain text. The fix prevents this duplication, ensuring users receive messages with URLs as intended. This improves the clarity and usability of WhatsApp communications.
Original PR description
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises within the `_send_message` method, where we are taking the Markup body that we use within the Odoo UI to have a clickable URL, like `<a href="https://example.com">https://example.com</a>`. Then, the html2plaintext function duplicates by adding the footnote for the anchor tag, which "duplicates" the URL since the text within the anchor tag is the same as the URL itself. This results in a message body that contains the URL twice, leading to confusion for the user. Solution: This commit addresses the issue by backporting the solution to this problem introduced in odoo/odoo@a152910 and using the `include_references` parameter of the `html2plaintext` function to exclude footnotes from the conversion. opw-4936400 Forward-Port-Of: odoo/enterprise#101083
This update fixes a bug that occurred when users attempted to apply a zero-amount discount in sales orders. The issue stemmed from a division-by-zero error. The fix ensures the system handles zero discounts gracefully, preventing errors and maintaining data integrity.
Original PR description
The system raises an error when the user tries to apply a fixed amount discount of 0.0. **Steps to produce:** - Install `Sales` module with demo data. - From the settings enable `discount`. - Make a sale order with product > click on Discount > click Fixed Amount and set amount as `0.0` > click on apply. **Error:** `ZeroDivisionError : float division by zero` **Cause:** - When the discount amount is set to 0.0, at [1] we attempt to compute the factor, which causes an error due to a division by zero. **Solution:** - Added a condition to check that current_base_amount_currency is not zero, and if it is, set the factor to 0.0. [1]: https://github.com/odoo/odoo/blob/10887c3081afbfd0734c6a3ac24301c94d14bc24/addons/account/models/account_tax.py#L3718-L3720 **sentry-6967181350** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where tax names and invoice labels were displayed in English for Vietnamese users. By adding the necessary Vietnamese translations to the chart template CSV, users will now see tax information in their preferred Vietnamese language, improving the user experience and ensuring accurate reporting.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields 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#241681 Forward-Port-Of: odoo/odoo#236502
This update fixes an issue where only the first attachment from an expense was included in the generated journal entry. The change ensures that all attachments associated with an expense are correctly copied, improving accuracy and providing complete financial records. This resolves a previous reporting discrepancy.
Original PR description
**Steps to reproduce:** * Install **hr_expense** and **accounting** modules. * Create two or more expenses, each with **multiple attachments**. * Submit and approve the expenses. * Create the **journal entry** of all approved expenses. * Open the generated journal entry and review its attachments. **Observed behavior:** * Only the **first attachment** from each expense is present on the journal entry. * Additional attachments are missing. **Cause:** * while creating journal entry, the logic of expense iterate on `message_main_attachment_id`. * `message_main_attachment_id` stores only a **single attachment**, so only one file per expense is copied. **Fix:** * Iterate on `attachment_ids` instead of `message_main_attachment_id`. * Ensures **all attachments** from each expense are included in the generated journal entry. opw-5414834 Forward-Port-Of: odoo/odoo#243962 Forward-Port-Of: odoo/odoo#241044
This update resolves an issue where scheduled email notifications and activity updates continued to run even after records were deleted. The fix prevents errors related to attempting to send messages to non-existent records, improving notification reliability and preventing confusing error messages for users. It ensures that deleted records don't cause disruptions in email workflows.
Original PR description
RATIONALE When a cascade delete occurs in DB, ORM methods are not called. More specifically loosely connected records using res_model / res_id pair are not removed when unlink override exists. SPECIFICATIONS Fix various use case in mail * notifications sent for scheduled messages; * failure notifications management; * activities mark as done; Task-5138556 Forward-Port-Of: odoo/odoo#243693 Forward-Port-Of: odoo/odoo#233071
This update addresses a potential issue where deleted records in Odoo could still be accessed, leading to errors. The fix ensures that related records are checked for existence before accessing data from deleted records, primarily due to how cascade deletions are handled in the database. This improves stability and prevents unexpected behavior when records are removed.
Original PR description
In order to be defensive we have to check records linked to messages, notifications or activities exist before checking related information like display_name, or even to skip them in various flows. This happens notably due to DB-level cascade deletion that does not remove side records linked through (model, res_id) pairs. It implies some additional exist queries. Task-5138556 Forward-Port-Of: odoo/enterprise#104243 Forward-Port-Of: odoo/enterprise#101185