Daily updates from Odoo
Thursday, November 6, 2025
33 changes · saas-18.4
Resolved issues and error corrections
Users can now search for a message and jump directly to it in mailboxes. This fixes a previous limitation that prevented opening the right message from search results in mailbox threads, making message lookup faster and more reliable.
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 change prevents portal users from accidentally overwriting a bank account’s custom account holder name when they update their profile details online. It keeps existing banking information intact unless the user actually changes their name, avoiding unexpected data loss.
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
The Australian TPAR report now exports correctly in both text and PDF formats. This fixes an error caused by country names being pulled in the wrong format and ensures report lines include the information needed for PDF generation.
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#97990This update corrects the invoice data sent to ECPay when a sales downpayment is billed. It ensures negative quantities are converted into valid values, preventing rejected invoices and incorrect pricing in the transmitted JSON data.
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
When a project is shared with another user, the Kanban view now prevents editing stages in that shared context. This avoids an error that could appear when users tried to search for more projects, making shared project navigation more reliable.
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 stops the same customer invoice from being settled more than once from the Point of Sale flow. It also keeps the selected customer in place if a second settlement attempt triggers an error, making the process clearer and avoiding duplicate accounting actions.
Original PR description
Steps to reproduce: ------------------------- - Install POS. - Create an invoiced order and pay with customer account. - Settle the created invoices from customers list. - Try to settle the invoice again from the same order. Issue: ------- - The system allows settling the same invoice multiple times. Cause: --------- - There is no check in place to verify whether the invoice has already been under settlement process before settling it again. Fix: ----- - Add a validation step to ensure that if the same invoice is selected again, the system prevents duplication and it will show that already being settled. - Also if error occured due to second try of settlment will not lose the selected partner. task: 5028009 related PR: [227971](https://github.com/odoo/odoo/pull/227971) Forward-Port-Of: odoo/enterprise#95156
Event ticket prices now display the currency symbol in the event form view. This makes pricing clearer at a glance and helps avoid confusion when working with tickets in different currencies.
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
The VIES summary report now shows invoice amounts in the company’s currency when invoices are issued in a different currency. This prevents incorrect totals and helps ensure the report is accurate for tax and compliance review.
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
The system now prevents customers from saving Boleto as a reusable payment method. This avoids failed or inconsistent payment setups because Boleto is a one-time offline payment method in most providers.
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
When a graph view search returns no matching records, Odoo now shows the custom no-content message configured for that action instead of the generic default message. This makes the empty-state message more relevant and consistent with the setup chosen by the user.
Original PR description
Before this commit: In the graph view, when performing a search that yields no matching data, the default no content helper is shown even if a custom no content helper has been provided for that action window. After this commit: The provided no content helper for the action window is displayed instead. task-5136801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes the text color in the account reports debug popover when dark mode is enabled. The formula is now easier to read, improving usability for users who inspect report details.
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 setting formerly called a “reminder” has been renamed to “deadline” to better match how it is actually used. This makes the tax return settings clearer and helps avoid confusion when configuring default filing deadlines.
Original PR description
This field is not a reminder anymore and is used to compute the default deadline from the end of the tax return. task-5153900 Forward-Port-Of: odoo/enterprise#96651
Fixed an issue where stock availability in the Barcode app did not refresh when a product or source location was changed. This ensures users see the correct stock quants when creating or editing internal transfers, reducing confusion and preventing incomplete picking decisions.
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
This fix ensures that linked fields coming from inherited models are checked correctly for indexing when they connect to other records. As a result, the system can better detect missing indexes and help keep searches and data access efficient.
Original PR description
Many2one fields that originated from an `inherits` model were not linted for indexing if they were an inverse to a One2many field, because those fields on the inverse model have `store=False`. The Many2one field that needs to be indexed is the one on the delegated model. This commit fixes this by always getting the `base_field` for the inverse field - if it's an inherited field, it will use the source field; if not, it will use the field itself. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234530
This update corrects how the rental website sends customers to the next page after an action. It helps ensure users are redirected reliably, improving the checkout and browsing experience on rental pages.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/233842 Forward-Port-Of: odoo/enterprise#98760 Forward-Port-Of: odoo/enterprise#98492
This update corrects how several website shopping actions send users to a new page after an action is completed. It helps ensure customers are redirected reliably when updating the cart, wishlist, comparison, pricing options, or related website actions.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/98492 Forward-Port-Of: odoo/odoo#234297 Forward-Port-Of: odoo/odoo#233842
Archiving an employee with a departure reason now works without triggering an error. This fixes a traceback caused by tracking a rich text field, so HR users can complete the archive process reliably.
Original PR description
Steps to Reproduce: - Try to archive employee with departure reason. Issue: - `tracking=True` is not supported for fields.Html Fix: - Removed tracking on "departure_description" field. task-5164266 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes the total amount shown on export invoices for Turkish e-invoicing. For invoices marked "Registered For Export," the payable amount now correctly reflects the VAT deduction, so the generated XML matches the expected legal amount.
Original PR description
When the invoice's type is "Registered For Export", the total of the invoice which is shown in the cbc:PayableAmount node in XML, has to reflect the VAT deducted amount. This PR fixes the given issue. task-5159638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231221
This update prevents an error that could happen when scheduling or editing a meeting for an applicant if the user has no timezone set. If no timezone is available, the system now safely uses UTC so the meeting can be saved normally.
Original PR description
Currently, an error occurs when scheduling or updating a meeting for an applicant if the user's timezone is not set.
**Steps to Reproduce:**
1. In the user's profile, remove the TimeZone.
2. Now, install the "**Recruitment**" module.
3. Create an application and schedule a meeting for the applicant.
4. After saving the record, change the start time and try to save the record.
**Error:**
`AttributeError - 'bool' object has no attribute 'upper'`
**Cause:**
At [1], system gets the timezone from the context, but in this case, `'tz'` is `False`. As a result, `user_tz` becomes False, and using `upper()` method on a bool value triggers an error.
**Fix:**
This commit ensures that the 'UTC' timezone is assigned when the context does not include a valid timezone ('tz' is missing or False).
[1] - https://github.com/odoo/odoo/blob/78bd84c7b91f11780f152c29c8f595e3d9ed3d68/addons/calendar/models/mail_activity.py#L23
sentry-6952137101The website editor now prevents users from accidentally typing into the search bar input while editing a page in Firefox. This keeps the search bar behaving consistently across browsers and avoids unintended changes while designing pages.
Original PR description
Since the [html_builder refactoring], it's possible to type something inside of an input while in the edit mode on Firefox, which is not the expected behavior and which is not the case in other browsers, for example, Chrome. Steps to see the issue: - Open Website and start editing - Drop a searchbar - Click on the input - Type something => It will remove the searchbar and add text to the searchbar button. This happens because of the different behavior on Chrome and Firefox of `pointer-events`. When the input has `pointer-events` set to `none` Chrome blocks any activity on it, including `beforeinput` events, but Firefox doesn't. This commit fixes this problem making the input not `contenteditable`. task-5144517 [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
Single-day time off requests will now appear as a single-day event in the Calendar app. This fixes a display issue that could make leave requests look like they lasted two days in some time zones, 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#231662 Forward-Port-Of: odoo/odoo#224298
This update prevents Sign request emails from being resent when a contact’s email is changed only in letter case, such as uppercase to lowercase. It avoids confusing duplicate notifications for recipients and keeps email sending behavior more consistent.
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
The appointment booking page now uses a configurable maximum for resource capacity instead of being capped at 12. This ensures businesses can offer and book higher-capacity resources correctly 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 users from canceling a manufacturing order that has already been completed. Instead of silently canceling an associated stock transfer by mistake, the system now shows an error message to explain that the completed order cannot be canceled. This helps avoid confusion and protects the integrity of manufacturing and inventory 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/enterprise#98758This fix stops users from canceling a manufacturing order that has already been completed. Instead of canceling the wrong related transfer, the system now clearly warns that a done manufacturing order cannot be canceled, avoiding confusion and incorrect stock operations.
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#234126When a manufacturing order is split into a backorder, the shop floor screen now shows the correct quantity for the specific operation when the user opens the edit pop-up. This avoids confusion and helps operators record production accurately on each step.
Original PR description
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total…
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total quantity to produce, and not the quantity to produce in that specific operation. **STEP TO REPRODUCE** 1. create a BoM of product with 3 or more operations 2. Create a Manufacturing order for i.e. 10 unit 3. Open shop floor 4. Register the production in shopfloor: - Op1 – 10 units registered - Op2 – 7 units registered - Op3 – 5 units registered 5. At the end, a backorder is created for 5 units. 6. When we open the wizard to register the production on the Op2, the quantity to produce that is displayed is 5, which is wrong because we only need to produce 3 unit for that step. **CAUSE** When creating the confirmation dialog, we pass the wrong value `qty_remaining` which is the quantity of product we will end after finishing the Manufacturing Order. **FIX** We should pass `qty_production` instead which is the quantity to produce for the specific step. opw-5011739 Forward-Port-Of: odoo/enterprise#98036 Forward-Port-Of: odoo/enterprise#93599
Selecting an order line now works again when the certified scale module is installed. This restores the normal product screen behavior, so staff can tap a line to select it and use a long press for the configurator as expected.
Original PR description
Task: [5163235](https://www.odoo.com/odoo/project/1737/tasks/5163235) --- In the product screen, pressing an orderline was supposed to select this line and a long press was supposed to open the Configurator popup. However, since the feature of the long press, if we install the module `l10n_eu_iot_scale_cert`, pressing an orderline does not select it anymore. This was due to the fact that a `t-ref` was added in the orderline template and that in the `l10n_eu_iot_scale_cert` module, we were overriding this template completely. Forward-Port-Of: odoo/enterprise#97992 Forward-Port-Of: odoo/enterprise#96980
The fullscreen view for course slides now correctly restarts the text highlighting interaction when enabled. This resolves a display issue that could cause highlighting to stop working properly for learners in later versions.
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
Uninstalling certain modules could leave behind inconsistent technical records, which then caused errors or incorrect field settings after removal. This fix makes Odoo refresh the affected models properly during uninstall, so the database and metadata stay in sync and removals complete cleanly.
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-233770
Forward-Port-Of: odoo/odoo#234364This fix prevents a crash when a purchase warning is shown for a contact that has no name. It ensures purchase orders and vendor invoices can still be created normally, even if the related partner record is incomplete.
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 Forward-Port-Of: odoo/odoo#231603
Opening the avatar popover for an archived employee no longer triggers an error. This fixes a usability issue in Planning and ensures archived records are displayed properly when users view employee details.
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 when opening the avatar popover for an archived employee in Planning. It adds a safety check so missing data no longer causes a traceback, improving reliability for users who view archived staff records.
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
This change prevents the expense report title from appearing twice when printing PDFs with DIN5008-formatted localizations, such as German. It adds a small compatibility module so the report uses the correct document title and produces cleaner, more readable expense documents.
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#234686 Forward-Port-Of: odoo/odoo#212923