Daily updates from Odoo
Monday, March 9, 2026
66 changes
19 changes
Resolved issues and error corrections
This update resolves an issue where demo livechat sessions incorrectly displayed as active in the info panel, even after receiving feedback. By adding a marker for the end of the conversation, the panel now accurately reflects the session's outcome, ensuring consistent and reliable demo data. This improves the clarity and accuracy of demo information.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Some livechat demo sessions included feedback/ratings but were still displayed as active conversations…
**Description of the issue this PR addresses:** ---------------------------------------------- Some livechat demo sessions included feedback/ratings but were still displayed as active conversations in the info side panel. This created inconsistent demo data where closed conversations appeared with options meant for ongoing chats (e.g., status shown instead of outcome). **Current behavior before PR:** ---------------------------------------------- - Certain demo livechat sessions had ratings applied but no explicit livechat_end_dt set. - As a result, the info side panel treated them as ongoing conversations. - This caused mismatched UI information for demo data. **Desired behavior after PR is merged:** ---------------------------------------------- - Demo livechat sessions that received feedback are explicitly marked as ended using livechat_end_dt. - The info side panel correctly reflects closed conversations with coherent outcome information. Task-5412081 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250001
This update resolves a JavaScript error that occurred when reloading the shopfloor app, specifically during MO process runs. The fix disables the automatic focus of the search bar, preventing a 'null' element error and ensuring consistent functionality. This improves the user experience and stability of the shopfloor application.
Original PR description
Steps to reproduce:
- Open the shopfloor app
- Reload or duplicate the page where the MO process is running
Issue:
A JavaScript error occur during reload:
UncaughtClientError > TypeError
Uncaught Javascript Error > Cannot read properties of null (reading 'blur')
Occured on 101125414-19-0-all.runbot180.odoo.com on 2026-02-16 04:59:28 GMT
TypeError: Cannot read properties of null (reading 'blur')
at https://101125414-19-0-all.runbot180.odoo.com/web/assets
/9d8abcf/web.assets_web.min.js:36280:459
Cause:
This happens when the search bar component attempts to call `blur()` on `inputRef.el` while the element is not yet available or has already been destroyed during the component lifecycle.
Fix:
Disable the search bar autofocus in the shopfloor
`env.config.disableSearchBarAutofocus = true`.
opw-5902675
upg-3894728
Forward-Port-Of: odoo/enterprise#109803
Forward-Port-Of: odoo/enterprise#107491This update removes a temporary workaround in the API documentation that was created when some fields in Odoo were renamed. This change ensures the API documentation accurately reflects the current field names, providing developers with the correct information. It's a minor fix to maintain the consistency and reliability of our API.
Original PR description
Reference-to: ec2b2edda9d4a2e4fb45d0 ([FIX] base: rename inherited custom field) 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#249161 Forward-Port-Of: odoo/odoo#249072
This update resolves a bug that caused the Odoo Enterprise application to crash when users switched between the text and HTML composer in AI chat. The fix ensures focus handling correctly works for both composer types, preventing errors and improving stability.
Original PR description
*=ai_app In AI chat, focusing the composer used to call ev.target.select(). That works for the text composer (textarea), but not for the HTML composer (contenteditable), where select() doesn’t exist and causes a TypeError. This update makes focus handling respect the active composer mode: - text mode keeps the existing select behavior - html mode uses the editor focus path instead task-5981018 Forward-Port-Of: odoo/enterprise#109634 Forward-Port-Of: odoo/enterprise#109163
This update resolves an unexpected behavior in the HTML editor within Safari, where pressing the spacebar would incorrectly move the text selection. The fix addresses a discrepancy in how Safari handles text node normalization, ensuring consistent and accurate selection behavior across browsers.
Original PR description
Problem: In Safari, pressing space sometimes can move the selection unexpectedly. Cause: `node.normalize()` in Safari doesn't work in the same way as in Chrome or Firefox. When the selection is on a…
Problem: In Safari, pressing space sometimes can move the selection unexpectedly. Cause: `node.normalize()` in Safari doesn't work in the same way as in Chrome or Firefox. When the selection is on a text node adjacent to another and we normalize, the two text nodes will be merged but the selection will move to the parent element instead of the correct position inside the new merged text node. Example: before normalize: `<span>"ab""c[]d"</span>` after normalize: `<span>"ab[]cd"</span>` (expected) vs `<span[]>"abcd"</span>` (Safari) Solution: Instead of using `normalize`, we manually merge adjacent text nodes and properly restore the selection by computing the absolute offset before the merge and restoring it to the correct position in the merged text node. Steps to reproduce: - Have two adjacent text nodes inside a `span`. - Put the selection on the second text node in the middle. - Press space. - The selection will move to the end of the text. opw-5956709 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252485 Forward-Port-Of: odoo/odoo#251918
This update fixes an issue where employee status information wasn't being retrieved correctly, leading to potential maintenance challenges. By reading `im_status` directly, the system now accurately captures necessary data for out-of-office calculations and internal user access, ensuring consistent employee status representation.
Original PR description
Just reading `im_status` instead of the dedicated method makes the maintenance harder and it is potentially problematic as it doesn't return the `im_status_access_token` nor the necessary extra information from employee records to compute out of office. In the 2 flows that are fixed here, the token is not mandatory as employee data is typically returned to internal users which have the right to read partners regardless. Leave status is also sent as part of `_store_avatar_card_fields` so that is also fine, but homeworking status appears to not be sent. `_store_avatar_card_fields` does return `work_location_id` and its type but `_store_im_status_fields` returns `work_location_type` and that is what is used in `hr-homeworking-office` of `imStatusDataRegistry`.
This update adjusts the spacing in the live chat sidebar to create a cleaner and more visually appealing design. Specifically, the spacing between the language code and the conversation badge counter has been reduced, and the language code is now displayed with a muted style for better readability. This improves the overall user experience.
Original PR description
Before this commit, discuss app sidebar items that had both the language and the important badge counter had too much spacing. This commit adapts spacing to preserve visually the same except reducing the language and counter spacing. The language code was also too visible compared to conversation name, so this PR improves by putting a `.text-muted` on it. Before / After <img width="297" height="945" alt="Screenshot 2026-03-06 at 14 44 59" src="https://github.com/user-attachments/assets/b75fc8ae-7c56-4918-8adb-5a347b740d7e" /> <img width="298" height="949" alt="Screenshot 2026-03-06 at 14 44 45" src="https://github.com/user-attachments/assets/6f3b98ec-4f54-438c-8e8b-bdac9a842a5d" />
This update improves the Knowledge app by automatically moving related articles to the trash when an audit report is deleted. Previously, linked articles remained visible, leading to cluttered workspaces and confusion. This change ensures a cleaner and more organized Knowledge experience for users.
Original PR description
When a user deletes an audit report, the articles linked to that report currently remain visible in the Knowledge app. This can lead to cluttered workspaces and confusion about which articles are still relevant. To keep workspaces clean, these linked articles will now be automatically moved to the trash when the audit report is deleted. Task-5902448 Forward-Port-Of: odoo/enterprise#101234
This update resolves an issue where multi-page invoices generated as PDFs would display an empty first page. The fix adjusts how the PDF rendering engine handles table formatting, ensuring all invoice lines are correctly placed across multiple pages. This improves the user experience when printing invoices.
Original PR description
Steps to reproduce: 1. Create an invoice with enough lines to span at least two pages. 2. Print the Invoice PDF. Observation: The first page appears empty (except for the header), and the entire invoice lines table is pushed to the second page. Cause: The introduction of the 'table-responsive-sm' wrapper in saas-19.1 includes 'overflow-x: auto'. The wkhtmltopdf rendering engine treats elements with overflow properties as unbreakable atomic blocks. If the block's height exceeds the remaining space on the current page, the engine moves the entire container to the next page rather than splitting it. Solution: Apply 'overflow: visible !important' to the 'table-responsive-sm' div. This overrides the Bootstrap default for the reporting engine, allowing the internal table rows to break naturally across pages while retaining the responsive wrapper for web/portal views." opw-5937043 Forward-Port-Of: odoo/odoo#251221
This update ensures that the 'Outstanding Account' field is automatically populated when a new 'Card' payment method is created in Point of Sale. Previously, the system lacked this configuration, causing inconsistencies between automated setup and manual setup, which has now been resolved to improve data accuracy and streamline the POS configuration process.
Original PR description
Steps to reproduce: 1. Initialize a new database with 'point_of_sale' and 'accountant' modules. 2. Go to Configuration > Payment Methods and open the 'Card' payment method. 3. Observe that the 'Outstanding Account' field is empty, despite being required in the view for bank journals. The issue occurred because the '_create_journal_and_payment_methods' method created the default 'Card' payment method without specifying an 'outstanding_account_id'. While the ORM allows this (as the field is only required in the view), it creates an inconsistency between automated setup and manual configuration. Solution: Modify '_create_journal_and_payment_methods' to automatically assign the 'outstanding_account_id' during creation. It follows the pattern used in the payment method's onchange logic by fetching the default debit account from the chart template or falling back to the company's transfer account. opw-5914536 Forward-Port-Of: odoo/odoo#249439
This update resolves a warning message users encountered when adding Google Shared Drive links to course content. The fix allows the system to properly access files within Shared Drives by explicitly requesting broader access through the Google Drive API. This ensures a smoother experience for users adding content from Shared Drives.
Original PR description
Step to reproduce: 1. Install `website_slides` 2. Go to eLearning > Courses > select a course > Add Content 3. Paste a public link that belongs to a file located in a Google `Shared Drive` Issue: - The system shows a warning `Your file could not be found on Google Drive, please check the link and/or privacy settings` even if the link is accessible via a browser in incognito mode. Cause: - The Google Drive API restricts the search scope to the user's personal `My Drive` by default It filters out items located in Shared Drives unless the client explicitly signals Solution: - Add `params['supportsAllDrives'] = 'true'` to the API request opw-5424413 Forward-Port-Of: odoo/odoo#241037
This update resolves an issue where the Timesheet Assistant form wasn't clearing after deselecting multiple suggestions. Now, when you remove all suggestions, the form automatically resets and disappears, preventing confusion and ensuring accurate timesheet data. This improves the user experience and data integrity.
Original PR description
# Steps to reproduce - Open Timesheet Assistant - Select multiple suggestions - Click on the cross to deselect all suggestions # Current behaviour The created timesheet from is not cleared and remains opened. # Expected behaviour Instead, the form should be cleared and disappear. task-6003551 Forward-Port-Of: odoo/enterprise#109819
This update ensures that all float time fields, including those in list views, are formatted consistently using the same options. Previously, the list view footer wasn't correctly applying the formatting rules, leading to discrepancies. This change guarantees a uniform and accurate display of float time values across all views.
Original PR description
Before this commit, the float_time formatter didn't extract the options "unit" and the field widget was. So, the list view footer, that was using the formatter and not the field widget, wasn't formatted in the same way that the column. Now, the formatter and the field widget float_time time behaviour with the options are the same. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where setting the inventory quantity to zero on a product without a defined location would cause an error. The fix ensures that the system handles this scenario gracefully, preventing disruptions to inventory management. This improves data accuracy and reliability.
Original PR description
When a user sets the inventory quantity to 0 on a quant while the product’s Inventory Location is unset, a traceback is raised. Steps to reproduce the error: - Install ``stock`` module with demo data…
When a user sets the inventory quantity to 0 on a quant while
the product’s Inventory Location is unset, a traceback is raised.
Steps to reproduce the error:
- Install ``stock`` module with demo data
- Open ``Cabinet with Doors`` product
- In Inventory tab, unset Inventory Location > Open forecast report > click the On Hand quantity
- Select the quant > Actions > Set to 0
Traceback:
```py
ValueError: NotNullViolation('null value in column "location_dest_id"
of relation "stock_move" violates not-null constraint
```
https://github.com/odoo/odoo/blob/bc790e13ddf3ceacead40cc6ff8d27f1a5f5364d/addons/stock/models/stock_quant.py#L1005-L1016
When property_stock_inventory is unset,
the ``_get_inventory_move_values`` method assigns a NULL value to ``location_dest_id`` in ``move_vals``.
As a result, creating the stock move with a NULL ``location_dest_id`` leads to the above traceback.
sentry-7117991902
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245245This update resolves an issue where the 'stats' button on a Purchase Order (PO) would disappear after the PO was canceled when it was originally created from a Stock Movement (MO). The fix ensures the PO remains linked to the MO, maintaining accurate tracking and reporting. This prevents confusion and ensures data integrity.
Original PR description
* Currently when a PO generated from MO, after that we cancel that PO, the MO statsbutton disappear, * Reason: because we remove move_dest_ids out of po line so the link is missing 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#250042
This update fixes a display issue in the payroll module where 'Confirm' buttons were incorrectly visible when payslips existed. The system now correctly hides these buttons when payslips are present, streamlining the user experience. This ensures users only see confirmation options when appropriate.
Original PR description
The 'empty_payslips' field is an Integer, but the view was treating it as a pure Boolean. This commit: - Updates 'Confirm' buttons to be invisible when payslips exist (> 0). Task: 5916154 Forward-Port-Of: odoo/enterprise#106957
This update removes unnecessary overrides related to Swiss payroll calculations within the payrun process. The core logic has been corrected, making these overrides no longer required. This streamlines the payroll process and ensures accurate calculations.
Original PR description
Not necessary anymore, standard logic has been fixed Forward-Port-Of: odoo/enterprise#108121
This update fixes an issue where long preset names in Point of Sale (PoS) were causing the preset button to take up too much space and obscure other buttons on the screen. The change ensures the PoS interface remains usable, even with lengthy preset names, improving the overall user experience. This was a minor visual adjustment.
Original PR description
# How to reproduce - Enable Take out / Delivery / Members in PoS Configuration - Create a preset with a very long name and set it as default - Open the register # The problem The preset button takes too much space and hide the other buttons opw-5938578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250671
This update ensures that employees only receive timesheets for public holidays that are relevant to their company. Previously, timesheets were incorrectly generated for employees in companies without the holiday, leading to inaccurate time tracking. This change improves data accuracy and reporting.
Original PR description
**Steps to reproduce** - Have 2 companies A and B - Use a single working schedule (needs to have no company on it) for both companies and their employees - Create a public holiday with company A, while having company B in the selected companies - There's a timesheet for the public holiday created for employees of company B, even though the public holiday will not apply for them. **Change** Only generate the timesheets for employees belonging to the companies of the public holidays. opw-5498462 Forward-Port-Of: odoo/odoo#245743
7 changes
Resolved issues and error corrections
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees linked to non-Indian companies, ensuring data accuracy and a consistent user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888
This update resolves an issue where the Timesheet Assistant form wouldn't clear after deselecting suggestions, leaving a partially filled timesheet open. The fix ensures that the form is completely cleared and disappears, providing a cleaner user experience and preventing confusion. This improves data accuracy and usability.
Original PR description
# Steps to reproduce - Open Timesheet Assistant - Select multiple suggestions - Click on the cross to deselect all suggestions # Current behaviour The created timesheet from is not cleared and remains opened. # Expected behaviour Instead, the form should be cleared and disappear. task-6003551
This update resolves an issue where sending digest emails failed when a company didn't have a website configured. The fix prevents a technical error (KeyError) by ensuring the system handles cases where website information is missing. This ensures all users can receive their email digests, regardless of whether a website is set up.
Original PR description
When a company has no website configured, sending a digest email raises a traceback. Steps to reproduce the error: - Install ``website`` module - Create a new company and switch to it - Create a new digest email > In KPIs, Enable Visitors > Add recipient > Save - Click on Send Now button Traceback: ```py KeyError: res.company(1,) ``` https://github.com/odoo/odoo/blob/dee3fdee0326db032d95639eb8ee9386bb1762d4/addons/website/models/digest.py#L49-L59 If no website exists for the company, ``websites_per_company`` becomes an empty dictionary. Therefore, accessing ``websites_per_company[company]`` raises the above traceback. sentry-7239108433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the Spreadsheet app would crash when using the 'Date' global filter. The fix ensures the system correctly handles scenarios where the 'spreadsheet_account' module isn't installed, preventing the error and improving filter stability.
Original PR description
Steps to reproduce: - Install Spreadsheet and Accounting - If `spreadsheet_edition_account` is installed, uninstall it - Go to Spreadsheets, create a new one and add a "Date" global filter => Traceback This commit fixes the issue by handling the case where no fiscal year is not installed. Task: 6002612
This update resolves an unexpected behavior in the HTML editor within Safari, where pressing the spacebar would shift the selection incorrectly. The fix involves a manual merging of adjacent text nodes to ensure accurate selection handling, improving the editor's usability across different browsers.
Original PR description
Problem: In Safari, pressing space sometimes can move the selection unexpectedly. Cause: `node.normalize()` in Safari doesn't work in the same way as in Chrome or Firefox. When the selection is on a…
Problem: In Safari, pressing space sometimes can move the selection unexpectedly. Cause: `node.normalize()` in Safari doesn't work in the same way as in Chrome or Firefox. When the selection is on a text node adjacent to another and we normalize, the two text nodes will be merged but the selection will move to the parent element instead of the correct position inside the new merged text node. Example: before normalize: `<span>"ab""c[]d"</span>` after normalize: `<span>"ab[]cd"</span>` (expected) vs `<span[]>"abcd"</span>` (Safari) Solution: Instead of using `normalize`, we manually merge adjacent text nodes and properly restore the selection by computing the absolute offset before the merge and restoring it to the correct position in the merged text node. Steps to reproduce: - Have two adjacent text nodes inside a `span`. - Put the selection on the second text node in the middle. - Press space. - The selection will move to the end of the text. opw-5956709 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252485 Forward-Port-Of: odoo/odoo#251918
This update fixes an issue where 'Confirm' buttons were incorrectly displayed when payslips existed. The system now correctly hides these buttons when there are outstanding payslips, providing a cleaner user experience. This ensures users only see the 'Confirm' button when it's appropriate.
Original PR description
The 'empty_payslips' field is an Integer, but the view was treating it as a pure Boolean. This commit: - Updates 'Confirm' buttons to be invisible when payslips exist (> 0). Task: 5916154 Forward-Port-Of: odoo/enterprise#106957
This update fixes an issue where miscellaneous journal entries weren't appearing in printed follow-up reports, even when marked for inclusion. Now, all overdue journal entries, including those categorized as 'miscellaneous,' are accurately reflected in the reports sent to partners. This ensures partners receive a complete overview of outstanding debts.
Original PR description
…port Currently, even if users mark a miscellaneous entry to be included in the follow-up report, only its amount is counted in the total overdue; the entry itself is excluded from the printed report sent to the partner. Steps to reproduce: - Have a journal item with partner, receivable account and due date in the past - Open followup report for the partner, uncheck 'No followup' for the aml - Go back to the partner, in the followup section, hit 'Send' and send the manual followup (or wait/trigger the scheduled action) Issue: Printed followup report is missing any info on the misc entry opw-5405657 Forward-Port-Of: odoo/enterprise#109581 Forward-Port-Of: odoo/enterprise#106725
2 changes
Resolved issues and error corrections
This update fixes an issue where miscellaneous journal entries weren't appearing in printed follow-up reports, even when marked for inclusion. Now, all relevant information from these entries, including the entry itself, is included in the report sent to partners, ensuring accurate overdue tracking. This improves the visibility of outstanding debts.
Original PR description
…port Currently, even if users mark a miscellaneous entry to be included in the follow-up report, only its amount is counted in the total overdue; the entry itself is excluded from the printed report sent to the partner. Steps to reproduce: - Have a journal item with partner, receivable account and due date in the past - Open followup report for the partner, uncheck 'No followup' for the aml - Go back to the partner, in the followup section, hit 'Send' and send the manual followup (or wait/trigger the scheduled action) Issue: Printed followup report is missing any info on the misc entry opw-5405657 Forward-Port-Of: odoo/enterprise#109581 Forward-Port-Of: odoo/enterprise#106725
This update removes unnecessary customizations related to Swiss payroll calculations within the payrun process. The standard Odoo logic has been corrected, eliminating redundant and potentially conflicting rules. This ensures accurate and compliant payroll processing for Swiss clients.
Original PR description
Not necessary anymore, standard logic has been fixed
12 changes
Resolved issues and error corrections
This update corrects a display issue in the website editor where the 'Custom URL' field incorrectly appeared on certain pages. Previously, this field was misleadingly presented even when the URL didn't support customization. Now, the field only appears when a page's URL is editable, ensuring a cleaner and more accurate SEO experience.
Original PR description
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not…
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not contain any modifiable slug. However, the value was not take into account since the route of the page did not expect slug. Reproduce: With an admin user, activate the website editor on an appointment page. Clicking on "Optimize SEO" in the "Site" dropdown menu, a form containing the "Cutsom Url" field is displayed. This field should represent the current page's URL but with fillable field instead of the editable URL part. In this case, this is not correct as the URL is repeated before and after the fillable field, which does not represent the current URL. Also, the URL is not modified with the value entered in the fillable field. After the fix: The "Custom Url" field must not be displayed when URL does not contain a customisable slug. Task-5114394 Forward-Port-Of: odoo/odoo#231609
This update resolves an issue where the system couldn't access files shared within Google Shared Drives. The fix adds a setting to the API request, allowing the system to properly search across all Google Drive locations. This ensures users can seamlessly embed content from Shared Drives into courses.
Original PR description
Step to reproduce: 1. Install `website_slides` 2. Go to eLearning > Courses > select a course > Add Content 3. Paste a public link that belongs to a file located in a Google `Shared Drive` Issue: - The system shows a warning `Your file could not be found on Google Drive, please check the link and/or privacy settings` even if the link is accessible via a browser in incognito mode. Cause: - The Google Drive API restricts the search scope to the user's personal `My Drive` by default It filters out items located in Shared Drives unless the client explicitly signals Solution: - Add `params['supportsAllDrives'] = 'true'` to the API request opw-5424413 Forward-Port-Of: odoo/odoo#241037
This update fixes a server error that occurred when merging tables in the restaurant POS system. Specifically, the system now waits for order synchronization before merging tables, preventing errors when a table has an empty order. This ensures a smoother and more reliable table management experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs during table merge Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related: https://github.com/odoo/enterprise/pull/104577
This update resolves an issue that prevented users from properly closing the mail composer when sending emails to a large number of leads (over 500). The fix avoids a technical error related to data payload sizes, ensuring the composer functions correctly regardless of the number of records selected.
Original PR description
Steps to reproduce: 1. Install `crm` 2. Create leads more than 500. 3. Select all and try to send email 4. Not close the wizard by "X" Issue: - Traceback occurs: `Uncaught Promise > Unexpected end of JSON input` Cause: - res_ids is not set on the composer when more than 500 records are selected. This is expected, as the compute method `_compute_res_ids()` does not write `res_ids` when the number of `active_ids` exceeds 500 (to avoid storing large payloads on the field). Because of this, the code trying to JSON.parse(res_ids) fails while dismissing the wizard at `onCloseWizardModal` Solution: - Fallback to context.active_ids when res_ids is not available opw-5891862 Forward-Port-Of: odoo/odoo#248406
This update resolves an issue that prevented basic receipts from printing correctly when the point-of-sale (POS) name exceeded a certain length. The fix limits the maximum POS name length to prevent a technical error that caused the printing process to fail. This ensures all receipts, regardless of POS name length, can be printed successfully.
Original PR description
When printing a basic receipt, if the pos name is too long a traceback will occurs when printing the basic receipt. Steps to reproduce: * Create a pos with a name of 46 character or more * Setup the italian fiscal printer * Enable Basic Receipt printing * Open point of sale * Create an order and validate it * Try "Print Basic receipt" Traceback: RangeError: Invalid count value: -15 at String.repeat () If the data being printed is longer than the maximum number of character in a line (MAX_CHARS = 46), paddingLeft becomes negative which cause an error in repeat(). [Similar solution](https://github.com/odoo/enterprise/blob/18.0/l10n_it_pos/static/src/app/fiscal_printer/commands/print_rec_message/print_rec_message.js#L35) [opw-5270697](https://www.odoo.com/odoo/project/49/tasks/5270697) Forward-Port-Of: odoo/enterprise#109527
This update ensures that timesheets are only generated for employees associated with the companies that have public holidays defined. Previously, timesheets were incorrectly created for employees in companies without a relevant holiday, leading to inaccurate time tracking. This change improves data accuracy and reporting.
Original PR description
**Steps to reproduce** - Have 2 companies A and B - Use a single working schedule (needs to have no company on it) for both companies and their employees - Create a public holiday with company A, while having company B in the selected companies - There's a timesheet for the public holiday created for employees of company B, even though the public holiday will not apply for them. **Change** Only generate the timesheets for employees belonging to the companies of the public holidays. opw-5498462 Forward-Port-Of: odoo/odoo#245743
This update fixes a minor issue in the Gantt chart where date selections in the scale selector didn't immediately update. The change ensures that date selections in the dropdown update instantly, providing a smoother and more responsive user experience when setting the chart's timeframe.
Original PR description
Steps to reproduce: - Open any Gantt view (e.g., Planning). - Open the scale selector dropdown and select a custom start or end date. Observation: The dates displayed in the dropdown do not update until the 'Apply' button is clicked. Cause: The XML template was referencing dates from the 'scales' prop, which is managed by the parent Gantt controller. This prop only updates after 'selectCustomRange' is called and the entire view reloads. Consequently, local changes in the date picker were not reflected in the UI during the selection phase. Solution: Modify 'web_gantt.GanttScaleSelector' to display dates directly from the local 'pickerValues' state. Since 'pickerValues' is a reactive 'useState' object, the UI now re-renders immediately when a date is picked, providing instant visual feedback before the user commits the change via the 'Apply' button. opw-5911253
This update fixes a minor issue where the HTML Editor module was incorrectly displaying 'odoo' (lowercase) as the author. The change ensures the correct Odoo S.A. author is listed, maintaining accurate attribution within the Odoo system. This aligns with previous author settings and ensures consistency.
Original PR description
Author was set as "odoo" (lowercase). This commit removes the author key so it fallbacks to the default one, i.e. Odoo S.A. This also aligns keys with previous commits like 42bad1a6 and ef7005f5. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190655
This update ensures that stock availability emails sent during testing correctly use the website's partner information. Previously, runbots would encounter errors because the website partner lacked an email address. The fix now provides a default email for the website partner in tests and prevents errors by explicitly failing if no email is available, ensuring reliable email delivery.
Original PR description
This commit (https://github.com/odoo/odoo/pull/249299/changes) backported some changes concerning stock availability mails. The mail is now sent from the partner associated to the website. However, in nightly runbots, the partner associated to the website does not have any email, so an error is thrown This fix does two things : - Make sure the website's partner has an email when running the tests - Prevent the mails being sent with the current user's email as a last ressort, and let an error be thrown instead runbot-102934954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251951
This update resolves an issue where German addresses submitted to Amazon were being incorrectly formatted, causing delivery validation failures. The fix swaps the order of address fields to match Amazon's requirements, ensuring accurate address data and successful deliveries for German customers. This improves the overall customer experience and prevents shipping delays.
Original PR description
When filling in a German address on Amazon, customers are presented with two fields: - Street, and - Building or company name. The street is sent as AddressLine2, while the building/company name is sent as AddressLine1. However, delivery providers validate address existence, which fails when address line 1 is not a street name. To resolve this, we swap these two fields for German addresses. opw-4668178 Forward-Port-Of: odoo/enterprise#109215
This update resolves an issue preventing users with multiple companies from successfully setting up their Amazon accounts. The fix allows access to all company data during the onboarding process, eliminating a mismatch error. This ensures a smoother and more reliable experience for all users.
Original PR description
The onboarding return route is a website route with access restricted to the website company only. This causes an error when the company doesn't match the Amazon account being connected. This commit allows users to access all their companies during Amazon account setup to avoid this mismatch error. opw-5944078 Forward-Port-Of: odoo/enterprise#109740 Forward-Port-Of: odoo/enterprise#109590
This update resolves an issue where documents couldn't be opened after their names were changed. The problem stemmed from an outdated reference within the documents module, which has now been corrected. This ensures documents can be reliably opened and accessed after being renamed, improving user workflow.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625 Forward-Port-Of: odoo/enterprise#105602
1 change
Resolved issues and error corrections
This update resolves issues with the product barcode lookup tooling, specifically preventing errors caused by mixing API requests and image requests. The code has been refactored to ensure consistent return values, enhancing the reliability of this critical feature.
Original PR description
The tooling had several issues like mixing a request to the API server and requesting an image to another server. Also the parameter of barcode_lookup_request was mutable since 444df3e48cb We separate in two method to ensure we never return the request object but only the parts that we expect (a json or the content)
9 changes
Resolved issues and error corrections
This update fixes a potential data error that could occur when moving folders linked to accounting settings to the trash. The automated system cleaning process was incorrectly attempting to delete these folders, leading to database inconsistencies. This change ensures these folders are excluded from the cleanup process, maintaining data integrity.
Original PR description
When a workspace(folder) linked to a folder setting is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install…
When a workspace(folder) linked to a folder setting is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``documents_account`` module - Go to Documents > Configuration > Files Centralization > Enable Accounting > Select any workspace > Save > - Click on Journals > Create a new > Select any Journal > Create a Workspace A > Save - Go to Documents > Click on Workspace A > Actions > Move to trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "documents_document" violates foreign key constraint "documents_account_folder_setting_folder_id_fkey" on table "documents_account_folder_setting" ``` solution: override the ``_get_gc_clear_bin_domain`` method to exclude folders linked to folder settings, preventing their deletion during the garbage collection. sentry-7193540869 Forward-Port-Of: odoo/enterprise#109776 Forward-Port-Of: odoo/enterprise#104875
This update ensures that the 'Insert in spreadsheet' action is only visible in list view menus for users with the necessary permissions for Documents and Dashboards. Previously, users without these permissions could still see the action, which has now been corrected for improved security and user experience.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards. Desired behavior after PR is merged: - The action is shown in the list view action menu only if the user has the required permissions. Task: 5930184 Forward-Port-Of: odoo/enterprise#109900 Forward-Port-Of: odoo/enterprise#108099
This update addresses a failing test within the Odoo Enterprise module, ensuring stability. The change refines the logic for determining product pushes based on move lines, resolving a technical issue. This improves the reliability of stock management processes.
Original PR description
This commit is part of the fw port community PR https://github.com/odoo/odoo/pull/252123. This commit fixes afailing test in enterprise. Task-5212472
This update resolves an issue where the internal note from a subscription wasn't correctly displayed in the list view of upsell orders. The fix ensures that notes are accurately reflected in both form and list views, improving data visibility and order management. This was caused by a technical detail related to how Odoo's ORM handles dependencies.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install Subscription and Studio modules 2. Using Studio, add `internal_note_display` field in the Quotation list view 3. Create a…
Steps to reproduce: ---------------------------------------- 1. Install Subscription and Studio modules 2. Using Studio, add `internal_note_display` field in the Quotation list view 3. Create a Subscription with some text in the Notes tab 4. Confirm it and create/confirm an invoice 5. Create an Upsell from this Subscription → Confirm 6. Open the Quotation list view Observation: ---------------------------------------- The internal note is correctly populated in the form view of the upsell order, but remains empty in the list view. Issue: ---------------------------------------- https://github.com/odoo/enterprise/blob/ba950af4ea21624419cf0cb7bbbe92c678ff7325/sale_subscription/models/sale_order.py#L531-L537 `_compute_note_order`accessed `subscription_id.note_order` recursively, Without the recursive dependency in the decorator, the ORM does not properly resolve the `note_order` chain during batch computation (list view), resulting in an empty `internal_note_display` on upsell orders. Form view worked because fields are fetched lazily, ORM tracks full dependency chain. Solution: ---------------------------------------- Add `recursive=True` on the `note_order` field so the ORM correctly tracks the full dependency chain and to allow the ORM to handle the self-referencing compute without warnings. This ensures correct recomputation in batch contexts such as list views. opw-5346451
This update resolves an issue where incorrect logic was used to handle boolean options in date and time fields. The change ensures accurate representation of these options, preventing potential errors in reporting and scheduling. This aligns with best practices for data integrity within Odoo.
Original PR description
*:appointment,esg_hr_fleet This commit is the counterpart of a community commit which removes wrong usages of `exprToBoolean` to evaluate boolean options in date(time) field widgets and formatters. This commit adapts the impacted archs accordingly. Part of task~6012182
This update improves the Knowledge app by automatically moving linked articles to the trash when an audit report is deleted. This prevents workspaces from becoming cluttered and reduces confusion about article relevance. It's a simple change to maintain a cleaner and more organized user experience.
Original PR description
When a user deletes an audit report, the articles linked to that report currently remain visible in the Knowledge app. This can lead to cluttered workspaces and confusion about which articles are still relevant. To keep workspaces clean, these linked articles will now be automatically moved to the trash when the audit report is deleted. Task-5902448 Forward-Port-Of: odoo/enterprise#101234
This update resolves an issue where the Timesheet Assistant form wasn't properly clearing after deselecting multiple suggestions. Previously, the form remained open. Now, the form will automatically clear and disappear when all suggestions are deselected, ensuring a cleaner user experience.
Original PR description
# Steps to reproduce - Open Timesheet Assistant - Select multiple suggestions - Click on the cross to deselect all suggestions # Current behaviour The created timesheet from is not cleared and remains opened. # Expected behaviour Instead, the form should be cleared and disappear. task-6003551 Forward-Port-Of: odoo/enterprise#109819
This update allows users to sign multiple documents directly within the Documents App. Previously, this functionality was limited. The change was implemented to address a reporting issue related to code counting within Odoo, ensuring accurate tracking of customizations.
Original PR description
This commit allows to sign multiple documents directly from the Documents App. This was removed by this commit (df271283cb277b69ea16c3adbfe90cc3a6e3d585) by wrapping the "code" server action into a "multi" one. It was done to avoid the cloc tool from counting the line as a customization, but since the server action is included in odoo path it's excluded from the count. Task-5416998
This update fixes an issue where employees could potentially select holidays from different companies within the Odoo Enterprise system. Now, the Gantt chart for holiday scheduling restricts employee selection to only their current company, ensuring accurate and consistent leave management. This improves data integrity and simplifies the scheduling process.
Original PR description
Task: 6012646
8 changes
Resolved issues and error corrections
This update ensures that users only see the option to 'Insert in spreadsheet' within list view menus if they have the necessary permissions for Documents and Dashboards. Previously, users without these permissions could still access the action, which has now been corrected for improved security and user experience.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards. Desired behavior after PR is merged: - The action is shown in the list view action menu only if the user has the required permissions. Task: 5930184 Forward-Port-Of: odoo/enterprise#109739 Forward-Port-Of: odoo/enterprise#108099
This update fixes an issue where users without proper permissions could access the 'Insert in spreadsheet' action in the Kanban view. Now, the action is only visible to users with the necessary permissions, and the restriction on inserting records based on grouped m2m fields has been removed, streamlining the process.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the kanban view action menu, even when the user lacked access rights for Documents or Dashboards. - Inserting records from a kanban view into a spreadsheet was blocked when the view was grouped by an m2m field. Desired behavior after PR is merged: - The action is shown in the kanban view action menu only if the user has the required permissions. - The m2m field check is removed when inserting from kanban views. Task: 5930184 Forward-Port-Of: odoo/enterprise#108098
This fix prevents a data error that occurred when generating work entries after overtime lines were created. The issue stemmed from an incorrect domain used to unlink overtime lines, leading to a 'ValueError'. This ensures work entries are consistently accessible after overtime generation.
Original PR description
__ ## Short functional explanation of the error When trying to access work entries after having generated similar overtime lines, an error occurs. This commit prevents the error to occur on databases…
__ ## Short functional explanation of the error When trying to access work entries after having generated similar overtime lines, an error occurs. This commit prevents the error to occur on databases where similar overtime lines have already been generated, but the prevention of duplicating overtime lines is implemented in commit 7bc84a920ba39457cb89cf2b93b2e769060c2854 on community. ## Reproduction Steps 1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of the work schedule to Pacific/Fiji (GMT +12). Set his Work Entry Source to Attendances, and in settings, set an overtime ruleset. 2. On this ruleset, select a rule and select 'From a specific duration', and in the field Duration to Exceed, write 8 hours. 3. Go to Attendances. Create an attendance from 3 am to 3 pm, save and close. 4. Click on the Configuration tab > Rulesets, click on the ruleset and click on Regenerate overtimes. 5. Try to open Work Entries. ### Expected behavior The Work Entries show. ### Unexpected behavior An error occurs: `ValueError: Expected singleton: hr.attendance.overtime.line` ## Origin of the issue When regenerating overtimes, we unlink the previously created overtime lines. However, as the domain to retrieve such lines wasn't set correctly, the overtime line of day 2 wasn't included in the lines to unlink. __ opw-5908447
This update removes unnecessary customizations related to Swiss payroll calculations within the payrun process. The core logic has been corrected, eliminating redundant and potentially conflicting rules. This ensures accurate and compliant payroll processing for Swiss users.
Original PR description
Not necessary anymore, standard logic has been fixed Forward-Port-Of: odoo/enterprise#108121
This update resolves a technical issue that prevented basic receipts with long POS names from printing correctly. The problem stemmed from a calculation error when padding text, causing a runtime error. This fix ensures all POS names, regardless of length, can be accurately printed on basic receipts.
Original PR description
When printing a basic receipt, if the pos name is too long a traceback will occurs when printing the basic receipt. Steps to reproduce: * Create a pos with a name of 46 character or more * Setup the italian fiscal printer * Enable Basic Receipt printing * Open point of sale * Create an order and validate it * Try "Print Basic receipt" Traceback: RangeError: Invalid count value: -15 at String.repeat () If the data being printed is longer than the maximum number of character in a line (MAX_CHARS = 46), paddingLeft becomes negative which cause an error in repeat(). [Similar solution](https://github.com/odoo/enterprise/blob/18.0/l10n_it_pos/static/src/app/fiscal_printer/commands/print_rec_message/print_rec_message.js#L35) [opw-5270697](https://www.odoo.com/odoo/project/49/tasks/5270697) Forward-Port-Of: odoo/enterprise#109527
This update resolves an issue where the AI module installation would fail due to insufficient PostgreSQL user permissions. By checking if the `pg_vector` extension is already installed before attempting to create it, we avoid errors and streamline the installation process without granting excessive database privileges.
Original PR description
[FIX] ai: test if pg_vector is installed before launching the create extension command
The command `CREATE EXTENSION IF EXISTS ...` require the postgresql user to have rights to use the command `CREATE EXTENSION`.
If the extension is already installed it will fail with a stacktrace because of inssuficient rights. `psycopg2.errors.InsufficientPrivilege`
With this PR we want to be able to install the module without giving too many rights to the postgresql user.This update ensures that German customer addresses are correctly formatted when used with Amazon. Previously, the system incorrectly sent company names as the primary address line, causing delivery validation errors. This change swaps the fields to ensure accurate address formatting and successful delivery.
Original PR description
When filling in a German address on Amazon, customers are presented with two fields: - Street, and - Building or company name. The street is sent as AddressLine2, while the building/company name is sent as AddressLine1. However, delivery providers validate address existence, which fails when address line 1 is not a street name. To resolve this, we swap these two fields for German addresses. opw-4668178 Forward-Port-Of: odoo/enterprise#109215
This update fixes an issue where users weren't seeing ratings for helpdesk tickets when they weren't part of the team assigned to those tickets. The change ensures all ratings for assigned tickets are displayed in the average rating views, regardless of team membership. This improves the accuracy of customer feedback reporting.
Original PR description
Steps to reproduce: - Configure a helpdesk team to be viewable by the test user - Remove test user from member_ids of helpdesk team - With that team selected, create a helpdesk ticket assigned to test user - Submit a rating for the ticket as the customer - As the test user in the helpdesk app overview, click on today average rating or last 7 days average rating Current behavior: - In both views, the test user won't see ratings for tickets attached to helpdesk teams where they are not listed in member_ids Expected behavior: - In both views, the test user should see all ratings of assigned tickets regardless if they are included in a helpdesk team's member_ids Note: member_ids in helpdesk.team appear to be only used for auto assigning new helpdesk tickets, so checking member_ids doesn't account for all potential users working in a team opw-5949917 Forward-Port-Of: odoo/enterprise#109136
4 changes
Resolved issues and error corrections
This update fixes a technical issue where excessive warnings were being generated due to how Odoo handles URLs. The fix ensures warnings are properly deduplicated, preventing unwanted and duplicated notifications. This improvement addresses a potential performance concern and avoids unnecessary alerts.
Original PR description
Every manipulation of the warnings list flushes the warnings registry, which prevents `warnings.warn` from deduplicating `default`, `module`, and `once` actions, instead they all behave as if `always`. Because werkzeug.urls is used *a lot* in odoo, this causes warnings to be emitted continuously even if that's not intentional, something which is already an issue due to workers (every new worker has an empty warnings registry triggering duplicate warnings). Upstream fixed this issue in pallets/werkzeug#2692 which was merged in 2.3.4, but apparently we vendored 2.3.0 which didn't have these fixes. Forward-Port-Of: odoo/odoo#252193
This update resolves an issue where the website slides feature wouldn't display content from Google Shared Drives. The fix allows the system to correctly access files in Shared Drives by adjusting the Google Drive API request. This ensures users can seamlessly integrate content from Shared Drives into their courses.
Original PR description
Step to reproduce: 1. Install `website_slides` 2. Go to eLearning > Courses > select a course > Add Content 3. Paste a public link that belongs to a file located in a Google `Shared Drive` Issue: - The system shows a warning `Your file could not be found on Google Drive, please check the link and/or privacy settings` even if the link is accessible via a browser in incognito mode. Cause: - The Google Drive API restricts the search scope to the user's personal `My Drive` by default It filters out items located in Shared Drives unless the client explicitly signals Solution: - Add `params['supportsAllDrives'] = 'true'` to the API request opw-5424413 Forward-Port-Of: odoo/odoo#241037
This update resolves an issue where a small floating-point number was incorrectly displayed in sale order down payment percentages. The fix ensures that percentages are rounded correctly, providing accurate financial data for sales calculations. This improves the reliability of the sales order process.
Original PR description
Issue: --- Due to this issue, a small floating point is shown in down payment percentage of a sale order. Steps to reproduce: --- 1- Create a sale order with lines. 2- From `other info` tab, uncheck `online signature` and check `online payment`, and set it to 14 percent. 3- Click on preview. 4- Click on `Accept & Pay`. The percentage shown is `14.000000000000002`, which is unexpected. Fix: --- By setting the percentage as `float` widget it will be rounded properly: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/odoo/addons/base/models/ir_qweb_fields.py#L185-L208 opw-5975047
This update corrects a technical issue that prevented German customers from correctly completing their addresses on Amazon. The system was sending building names as the primary address line, which caused delivery validation errors. By swapping the fields, we ensure accurate address formatting and successful delivery.
Original PR description
When filling in a German address on Amazon, customers are presented with two fields: - Street, and - Building or company name. The street is sent as AddressLine2, while the building/company name is sent as AddressLine1. However, delivery providers validate address existence, which fails when address line 1 is not a street name. To resolve this, we swap these two fields for German addresses. opw-4668178 Forward-Port-Of: odoo/enterprise#109215
4 changes
Resolved issues and error corrections
This update resolves a problem where Razorpay payments failed due to customer names containing commas or exceeding 50 characters. The fix ensures Razorpay receives only clean names (without commas) and limits them to 50 characters, preventing payment errors and improving compatibility with Razorpay.
Original PR description
Steps: - Install and set up Razropay. - Create order and set customer with long name or name with comma. - Try to pay with Razorpay. Issue: - Error name is invalid. Cause: - Razorpay only take name without comma and upto 50 character, so having longer name or name with comma would cause an issue. Fix: - Replace comma with empty space and only take first 50 character of name while creating customer in Razorpay.
This update resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixed a bug where date formats like '2500/1222' were wrongly identified as '%Y.%m.%d'. The change ensures that import files are processed with the correct date formats, preventing import errors and improving data accuracy.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196477
This update resolves an issue where emails with attachments using the 'bin/plain' MIME type would cause the system to crash. The fix now handles this attachment type by falling back to a standard format, ensuring all incoming emails are processed correctly and preventing disruptions to vendor bill creation.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a technical problem where screenshots of spreadsheets couldn't be saved correctly, leading to errors. The fix ensures that thumbnails are reliably created even when the spreadsheet is temporarily closed, improving spreadsheet functionality and preventing data loss.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)