Daily updates from Odoo
Thursday, November 6, 2025
31 changes · saas-18.3
Resolved issues and error corrections
This update fixes tax report returns so they no longer repeat the same closing entry content across different reports in the same country. It also adjusts some reports to use a review step instead of generating a closing entry when that is the correct business flow, helping avoid incorrect return outputs.
Original PR description
It's possible for different tax reports to exist in the same country, each with its own return type. However, this is an issue when they aren't configured to generate closing entries with distinct contents, since each of them will then repeat the content of the other. To fix this, when it's legitimate to make multiple closing entries, we make sure the closing entry only considers the tax move lines linked to the report's tax tags. If multiple reports must generate the same closing entry (typically because one of them is a simplified version of the other), we disable the generation of the return for one of them. Some reports also didn't need to generate a closing entry and were switched to a 'review_submit' state. task-5123564
Users can now search for a message in mailboxes and jump directly to it. This fixes a limitation that previously blocked navigation to messages when they were not in their original conversation, making mailbox search more reliable and easier to use.
Original PR description
Before this commit, we could not jump to messages in mailboxes. This happens because the `useMessageHighlight()` hook prevented jumping to messages in thread that were not their origin thread. This commit fixes the issue by removing this limitation specifically for mailboxes. opw-4948798 opw-5087102 Forward-Port-Of: odoo/odoo#234526
This fix prevents a customer’s bank account holder name from being overwritten when they update their profile on the website. It ensures that saving address details does not unintentionally replace a manually set account holder name with the partner’s name.
Original PR description
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a…
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a Bank Account with a custom Account Holder Name. 4. Log in to the Website using the Test User. 5. Navigate to My Account and click Edit Information. 6. Fill in the address details (without changing the Name) and click Save. 7. Go back to the Employee’s Bank Account and check the Account Holder Name. Observation: ------------------------- The Account Holder Name was overwritten to the partner's name. Issue: ------------------------- In `_compute_account_holder_name` method, https://github.com/odoo/odoo/blob/c3b543631bde96260082484a3baac19d942f6b9f/odoo/addons/base/models/res_bank.py#L104-L107 The Account Holder Name is always recomputed using the Partner’s name. When submitting the form from the frontend, the name field is included in the values sent to update the Partner, even if the user did not actually change the name. https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/portal/controllers/portal.py#L196-L205 which re-triggers this compute and as a result, the Partner’s name overwrites the Account Holder Name on the linked Bank Account Solution: ------------------------- Prevent the Account Holder Name compute method from being triggered when updating information from the frontend if the Partner’s name has not been changed. opw-5059247 Forward-Port-Of: odoo/odoo#232723 Forward-Port-Of: odoo/odoo#229210
This update prevents users from editing stages in the Kanban view of shared projects. It avoids a crash that could happen when they tried to search for more projects, improving stability and making shared project access behave as expected.
Original PR description
Steps to reproduce: - 1. Install the Project module. 2. Create a new project and share it with a user. 3. Log in as that user. 4. Open the shared project Kanban view and try to edit a stage. 5. Try to search for more projects. Issue: - A traceback occurs when clicking on 'Search More'. Fix: - Prevent stage editing in shared project Kanban view. task-5176630 Forward-Port-Of: odoo/odoo#233557
This update corrects how downpayment invoice lines are sent to ECPay by converting negative quantities into valid values. It prevents incorrect invoice data from being transmitted and helps ensure Taiwan electronic invoicing works reliably for sales with down payments.
Original PR description
When an invoice is created from a sale order with a downpayment, the invoice line for the downpayment typically has a negative quantity and a positive unit price. However, ECPay does not accept negative quantities, and this also leads to incorrect price values being sent in the JSON payload. To address this, when an invoice line has a negative quantity, it is inverted to ensure the data sent to ECPay is valid and consistent. **task**-5211264 Forward-Port-Of: odoo/odoo#233359
The Australian TPAR report now exports correctly by using the proper country name text instead of a stored data structure. It also fixes PDF generation so reports can be downloaded without errors, improving reliability for businesses using this filing format.
Original PR description
Behavior before: Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'})…
Behavior before:
Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'}) instead of plain text, resulting in incorrect line lengths. Additionally, PDF export failed with a KeyError for the missing 'level' key, as dynamically generated report lines did not include a level field, which the QWeb template requires.
Behavior after:
SQL query uses the JSONB text extraction operator (->>) to retrieve only the country name string (e.g., 'Australia'), ensuring correct line lengths during export. All dynamic report lines are assigned 'level': 1 so that PDF export works correctly without errors.
Root cause:
Country names are stored as translatable JSONB fields, and the previous query did not extract the localized text, returning the full JSON structure. Dynamic report lines for partners did not include a level key by default, causing the PDF template rendering to fail.
Ticket [link](https://www.odoo.com/odoo/project.task/5148697)
opw-5148697
Forward-Port-Of: odoo/enterprise#98020
Forward-Port-Of: odoo/enterprise#97990The VIES summary report now correctly converts invoice amounts into the company currency when invoices are issued in another currency. This ensures the reported totals are accurate and match accounting expectations.
Original PR description
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in…
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in incorrect totals in the report. **Steps to Reproduce:** 1. Install the Accounting app and the l10n_cz_reports_2025 module. 2. Go to Accounting > Customers > Invoices. 3. Create a new invoice using a currency other than CZK. 4. Add a product with Code Supply set to Gold and Transaction Code set to 0 Goods. Confirm the invoice. 5. Navigate to Accounting > Reporting > VIES Summary Report. 6. Observe that the total value is not correctly converted to the company currency. **Expected Behavior:** The total amounts in the VIES summary report should be correctly converted to the company currency if the invoice was created in a foreign currency. **Actual Behavior:** Amounts are displayed in the invoice currency without conversion, leading to incorrect totals when the invoice currency differs from the company currency. **Root Cause** The report fetches raw invoice data without handling currency conversion. Specifically, it retrieves the unconverted total value, even when the invoice currency differs from the company’s. **Fix** To solve the issue the balance field is used, which correctly reflects the value in the company currency. opw-4688638 Forward-Port-Of: odoo/enterprise#97894 Forward-Port-Of: odoo/enterprise#82978
This fix prevents a frontend crash when a Point of Sale is switched from a setup without employee login to one that uses it. If the local POS data is outdated, the system now clears it and reloads so the correct employee data can be loaded safely.
Original PR description
Before this fix, a traceback occurred on the frontend when switching from a POS configuration without the “Log in with employees” option enabled to one that had it enabled. Steps to reproduce : 1. Open a PoS without "Log In With Employees" option activated 2. Close Register and go to the backend 3. Enable the "Log in with employees option" for this PoS and set some users 4. Re-open the PoS with a user and close it 5. A TB occured This traceback occurred because the IndexedDB did not include the "hr.employee" module required by the "Log in with employees" option. The fix was to delete the IndexedDB when the error is caught and refresh the page to trigger the IndexedDB upgrade process. task: 5223393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where a one-day time off request could appear as spanning multiple days in the Calendar app for some time zones. This makes the calendar view match the actual leave dates, reducing confusion for managers and employees.
Original PR description
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC.…
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. **After fix:** - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 **Steps to Reproduce:** 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817 Forward-Port-Of: odoo/odoo#230079 Forward-Port-Of: odoo/odoo#224298
Boleto payments are now treated as one-time payment methods and can no longer be stored for reuse. This avoids inconsistent behavior across payment providers and prevents checkout issues for customers using Boleto.
Original PR description
## Versions 17.0+ ## Issue Boleto is an offline, one-time-use payment method and cannot be tokenized with most payment providers (e.g., Adyen: https://docs.adyen.com/payment-methods/boleto-bancario/, Nuvei: https://www.nuvei.com/apm/boleto). ## Exception Stripe allows a form of tokenization by storing the customer's billing information and regenerating a new Boleto for each payment (cf. https://docs.stripe.com/payments/boleto). Technically, the Boleto itself is not reusable — Stripe simulates tokenization by associating customer info with new Boleto transactions. ## Fix To maintain consistent behavior and avoid provider-specific edge cases, tokenization is disabled for Boleto payments globally. opw-5156718 Forward-Port-Of: odoo/odoo#234373
The event form now displays the currency symbol next to ticket prices. This makes pricing clearer for users and reduces the risk of confusion when setting up event tickets.
Original PR description
Add missing currency symbol next to the event ticket price in the event form view. Task-5114075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233470
Fixed an issue in Barcode operations where available stock was not refreshed after changing the product or source location. This ensures users see the correct stock quantities when creating or editing internal transfers.
Original PR description
Issue: In this bug, stock quants are not being updated when product_id or location_id is updated. To reproduce: 1- Create a db with demo database and barcode installed 2- Enable storage locations 3- Open barcode -> operations -> Internal transfers -> New 4- Add a product -> e.g. Drawer which there are quants in demo 5- As you see quants are not shown Cause and Fix: This is a partial backport of: #55917 `_compute_product_stock_quant_ids` should depend on `product_id` and `parent_location_id` to be recomputed when product or source location is updated. opw-5065624 Forward-Port-Of: odoo/enterprise#98850 Forward-Port-Of: odoo/enterprise#95906
In dark mode, the debug popup in account reports now shows formulas with a readable text color. This makes it easier for users to inspect report details without straining to read the content.
Original PR description
When using the dark mode, the popover available only in debug mode on the account reports (when pressing the info button on the right of each line) used to display the formula with a dark color, making it hard to read. Forward-Port-Of: odoo/enterprise#98905
The appointment booking flow no longer uses a hard-coded limit for resource capacity. Businesses can now set a global maximum allowed capacity, so customers can book resources with higher capacities when needed.
Original PR description
**Steps to reproduce:** - Install Appointment and Website apps - Create a resource with capacity above 12 - Create an appointment_type on `Resources` - Check `Manage Capacities` - Set its assignment method to `Select Time then auto-assign` - Go to the website and select the new resource - The maximum capacity you can book in the drop-down list is stuck to 12 **Issue:** Arbitrary maximum value (12) seemed to be used in the appointment website and controllers, for the resource capacity which can be booked by someone. **Fix:** Added `resource_max_capacity_allowed` setting to configure the maximum allowed value globally. related: https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc related: https://github.com/odoo/enterprise/commit/db36b59c80b45c6df1da3ac9dc876e79121e5e5e opw-5059177 Forward-Port-Of: odoo/enterprise#94935
This change prevents an error when a purchase warning is shown for a contact that does not have a name. Users can now create purchase orders and related invoices for these contacts without the process crashing.
Original PR description
When creating a purchase order for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install purchase with demo data - Enable purchase warning from settings - Open `Azure…
When creating a purchase order for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install purchase with demo data - Enable purchase warning from settings - Open `Azure Interior` Contact > In Contact, Add Contact > Type: invoice > Save & close - Add warning in newly created contact - Create a purchase order with the newly created partner and create an invoice with the newly created partner Traceback: `TypeError: unsupported operand type(s) for +: 'bool' and 'str'` https://github.com/odoo/odoo/blob/96887e0b9e7a9b01482b9dc1fcf99040e9de6b2c/addons/purchase/models/purchase_order.py#L298 https://github.com/odoo/odoo/blob/96887e0b9e7a9b01482b9dc1fcf99040e9de6b2c/addons/purchase/models/account_invoice.py#L131 Here, `partner_id.name` is `False`, which leads to string concatenation with a boolean in purchase warning messages and results in the above traceback. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes issues that could leave the system in an inconsistent state after uninstalling a module. It ensures affected models and fields are refreshed correctly so database rules and field settings are restored properly, avoiding uninstall errors and stale configuration data.
Original PR description
When we uninstall a module, we never reflect impacted models or fields on ir.model or ir.model.fields. That can lead to an inconsistent state after uninstallation: For example, the…
When we uninstall a module, we never reflect impacted models or fields on ir.model or ir.model.fields. That can lead to an inconsistent state after uninstallation:
For example, the 'appointment_account_payment' module that makes `calendar_event_id` not required anymore. After uninstalling it, the ORM will complain that the not-null constraint doesn't exist ("Missing not-null constraint on appointment.answer.input.calendar_event_id"). Also, if we look at the `ir.model.fields` record for `calendar_event_id`, it shows that the field isn't required, but it should be required again (with the correct constraints too).
Add the information of impacted models for the 'to remove' modules, and force the new registry to call `init_models` on them. This will handle constraints and reflection on `ir.model`/`ir.model.fields`. We can then remove the call to `check_tables_exist` (see 3058ca4121048796c38aad78e3e4f5ffde3530f5) since `init_models` will do the job correctly for impacted models.
Also remove a part of the uninstall hook of website because it forces reloading the registry too soon (warning of missing not-null constraint) and the uninstallation manages the case genericly (remove correctly `ir.model.fields` record of `res.config.settings.website_id`)
runbot-error-233770This update restores menu mode in the self-ordering flow so customers can browse and order as expected. It helps prevent ordering interruptions and improves the reliability of the self-service experience.
Original PR description
Menu mode was broken in self ordering. This commit fix it. Forward-Port-Of: odoo/odoo#234019 Forward-Port-Of: odoo/odoo#232503
This update fixes floating-point rounding issues that could cause DHL shipment validation to fail for otherwise valid orders. It helps ensure prices and weights are sent in a format DHL accepts, reducing delivery errors at confirmation time.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#98819 Forward-Port-Of: odoo/enterprise#96012
This update prevents sign request emails from being resent when a contact’s email address is changed only in letter case, such as upper- or lowercase. It avoids sending unnecessary duplicate emails to the same recipient and reduces confusion for users.
Original PR description
Before this commit, when changing the partner email to uppercase or lowercase, it would resend sign requests emails for each previously sent signed request to that email. After this commit, we don't resend anymore the sign requests emails after a case sensitive email change of a partner. task-4844230 Forward-Port-Of: odoo/enterprise#87112
This change removes an unnecessary test flag from the self-order kiosk tour. It prevents a debug-mode issue in local environments, helping the test flow run cleanly without affecting normal use.
Original PR description
In this commit: - Removed the `test: true` flag from the `test_kiosk_cart_restore_and_cancel` tour. - The flag is not required for tours and can cause issues when running in debug mode. - This issue only occurs in local environments when debug mode is enabled. - After this fix, no issue is generated in debug mode.
This fix prevents an error when users open the AI chat from the email composer and their profile has no timezone set. If no timezone is available, the system now safely uses UTC instead, avoiding a broken compose experience.
Original PR description
Currently, an error occurs when opening the AI chat from the mail composer if the user's timezone has been removed. **Steps to Reproduce:** 1. Install AI and Purchase modules. 2. In the user's profile, remove the 'TimeZone'. 3. Open any purchase order and click on _Send PO_. 4. In the _Compose Email_ form, click on AI icon. **Error:** `AttributeError - 'bool' object has no attribute 'upper'` **Cause:** The issue occurs because `self.env.user.tz` returns False when the user's timezone is not set, causing an error when it tries to use `upper()` method on bool value. **Fix:** This commit fixes the issue by defaulting to the UTC timezone when the user's timezone is not set. **Ref:** https://github.com/odoo/odoo/blob/0f40ea82a1332f0e7168d861ad446b7316ab03de/odoo/addons/base/models/res_partner.py#L225-L228 sentry-6961379038
The employee time off dashboard now correctly displays Extra Hours allocations when an employee has attendance-based overtime. This fixes a visibility issue so managers and employees can see the full balance available to them.
Original PR description
### Steps to reproduce: - Install Attendance and Time off apps - Create some attendance with extra hours for the employee - Go to the employee's time off dashboard - Notice Extra Hours allocation is not shown ### Cause: When we are getting the allocation data we check for the leave types that require allocation https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/hr_holidays/models/hr_leave_type.py#L473 And then when checking the types that doesn't require allocation we are looping on the res that we got from the super which already excluded those types https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/hr_holidays_attendance/models/hr_leave_type.py#L41-L43 ### Fix: We loop over the self leave types to make sure we are getting all of the employee's leave data whether the type requires allocation or not. opw-5042325 Forward-Port-Of: odoo/odoo#225015
This change prevents the expense report title from appearing twice when printing PDFs for the DIN5008 format. It does this by providing the correct document title for expense reports, so the printed output looks clean and professional.
Original PR description
Issue: Expense title is duplicated when printing an expense report for localizations using the DIN5008 standard. Steps to reproduce: - Install German localization - Create a new expense report - Print the expense report PDF -> Title is duplicated Cause: DIN5008 reports tries to load a value `din5008_document_title` in their header and fallbacks to report's name With this commit, we add a bridge module to extend the expense sheet report and set the `din5008_document_title` to `Expenses Report`. opw-4314414 Forward-Port-Of: odoo/odoo#234348 Forward-Port-Of: odoo/odoo#212923
This fix prevents the chat hub from becoming hidden behind newly opened chat windows. It also stops the hub from being dragged while chats are open, making chat navigation more reliable for users.
Original PR description
Prior to this commit, moving the chat hub could cause newly opened chat windows to appear on top of it, rendering the hub invisible and unusable. This commit fixes the issue by resetting the chat hub's position whenever a chat window opens and disabling its drag functionality while any chat window remains open. task-5227499
Completed manufacturing orders can no longer be canceled by mistake. If a user tries to cancel one, the system now shows an error instead of canceling the related stock transfer, which avoids confusion and protects the integrity of manufacturing records.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/odoo#234126This fix restores employee selection in forms for users who do not have full Employees access, especially in mobile and Studio-created fields. It prevents the employee picker from showing no results when employee photos or avatar fields are involved.
Original PR description
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to…
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to select an employee. -> No records found. Note: the many2one_avatar_employee widget used in HR apps avoid this problem. **Cause** Issue since https://github.com/odoo/odoo/commit/e962860c6f0d8ec9e50bb376e1faab5c7bc69374 The `web_search_read` on the private employee model returns no records when an `image_*` or `avatar_*` field is part of the requested fields. This is because we try to fetch these fields https://github.com/odoo/odoo/blob/188a3fe45fb41463ff86d1fa5e930ab43fb70d0e/addons/hr/models/hr_employee.py#L240 but they are not stored on the public employee model, and will not be put in cache. When performing a read after that, these fields are missing from cache. We try to fetch them from the db https://github.com/odoo/odoo/blob/e962860c6f0d8ec9e50bb376e1faab5c7bc69374/odoo/models.py#L3185 but this fetch is again done using the public employee. This results in missing values and is interpreted as an access error, no data is returned in `web_search_read`. **Solution** Read the problematic fields to make them present in cache when the cache of the public employee is copied to the one of the private employee. opw-4297115 Forward-Port-Of: odoo/odoo#197575
Completed manufacturing orders can no longer be canceled by mistake. If a user tries to cancel one, the system now shows a clear error instead of canceling a related stock transfer, which avoids confusing and incorrect inventory actions.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/enterprise#98758This update corrects how text highlighting behaves when a course is shown in fullscreen. It ensures the highlight interaction restarts properly in fullscreen mode, so the feature works reliably for learners.
Original PR description
**Issue:** `this.websiteAnimateWidget` is undefined Also the fix wasn't working properly in later versions. This is due to an incorrect conflict resolution in the forward port of the related fix. **Fix:** The fix for websiteAnimateWidget was made obsolete in these versions with: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba But the original issue of `textHighlightWidget` was still present and not properly caught by the tour. The new fix add the fullscreen slide to the selector of the TextHighlight interaction which is restarted when fullscreen is enabled. related: https://github.com/odoo/odoo/commit/184c6f855f703239864f482ff252beb1293c343d opw-4978798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234107
This update changes the test setup so a new loyalty program is created from scratch instead of reactivating an old one. It prevents previously disabled reward items from coming back unexpectedly, which keeps the test behavior stable and reliable.
Original PR description
## Versions 18.3+ ## Issue Tests fail due to free product rewards being reintroduced when a loyalty program is reactivated. ## Cause Reactivating a loyalty program also reactivates its child records, including default rewards. See: https://github.com/odoo/odoo/blob/f03ff6d9b727a22e3b250a5c9cc875b9f1f16263/addons/loyalty/models/loyalty_program.py#L513-L518 ## Fix Create a new loyalty program instead of reactivating an existing one. runbot-232709
Fixed an issue where opening the avatar popover for an archived employee in Planning could fail. The system now correctly reads archived records, so users can view employee details smoothly without encountering an error.
Original PR description
**Steps to reproduce:** - Open the Planning app. - Archive an employee. - Open the archived employee's avatar popover. **Current behavior before PR:** Opening the popover raised an error because `get_avatar_card_data` returned an empty list for archived records. This occurred since `search_read` ignored inactive records by default. **Desired behavior after PR is merged:** The method now uses `read` instead, ensuring archived records are properly handled without error. enterprise PR: https://github.com/odoo/enterprise/pull/98230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231184
This change prevents an error that could appear when users open the avatar popover for an archived employee in Planning. It adds a safeguard so the system handles missing data gracefully instead of showing a traceback, improving reliability for everyday use.
Original PR description
Purpose of this PR: A guard has been added in the override of `get_avatar_card_data` to handle empty results and prevent traceback errors when data is missing. community PR: [odoo/odoo#231184](https://github.com/odoo/odoo/pull/231184) Forward-Port-Of: odoo/enterprise#98230