Wednesday, January 14, 2026
41 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue preventing non-admin users in multi-company environments from updating their profile picture or preferred language. Previously, a rule blocked access to company information, causing an error. This change bypasses the rule to ensure a smoother user experience across different company setups.
Original PR description
### Impacted versions: 19.0 and later ### Steps to reproduce: - Install at least 2 languages - Create multiple companies - Log in as marc demo and select only one company - Try to update profile picture or modify preferred lang ### Current behavior: When a non-admin user operates in a multi-company environment with only some companies active in their context, the `res_company_rule_employee` record rule blocks access to `company_ids` when trying to read all assigned companies. This causes an Access Error in the `res.users.new()` method when it attempts to count the user's companies to manage the `base.group_multi_company` group membership, preventing users from changing their profile picture and updating their preferred language Task: [5458607](https://www.odoo.com/odoo/project/49/tasks/5458607) Forward-Port-Of: odoo/odoo#243259
This update fixes an issue where Point of Sale orders weren't consistently linked to the correct company within the Odoo system. Now, when a new order is created, the system automatically sets the company ID to match the configuration of the current Point of Sale session, ensuring accurate reporting and accounting. This improves data integrity and simplifies business operations.
Original PR description
When creating an order, if due to some reason the company_id is not set on the order data, we set it to the company of the POS session's config. opw-5470175 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243249
This update fixes a problem where Odoo couldn't correctly identify proxy users when a branch company had the same VAT number as its parent. This prevented users from saving electronic invoicing settings. The change ensures the correct company is used for proxy user searches, improving stability and functionality.
Original PR description
Fix issue when saving a branch company sharing the same VAT and Codice Fiscale as its parent. The proxy user search fails because `account_edi_proxy_client.user` is looked up in the branch company instead of the parent one. The same applies when searching the demo user to remove. Steps to reproduce: - Install `account` and `l10n_it_edi` - Set up the company's VAT and Codice Fiscale - Create a branch company with the same VAT and Codice Fiscale - Enable the Electronic Invoicing processing through the SDI in the settings - Select only the branch company and try to save the settings - Observe error since we will try to create a proxy user on the IAP server for an already existing company (the parent one). Ticket [link](https://www.odoo.com/odoo/project.task/5391668) opw-5391668 Forward-Port-Of: odoo/odoo#241443
This update corrects a problem in the Barcode app for Manufacturing Orders. When tracking is disabled, a Manufacturing Order wasn't correctly created with components. The fix ensures the necessary data is set before comparisons are made, preventing errors and ensuring components are added to the order as expected.
Original PR description
Fix an incorrect flow when creating a Manufacturing Order through the Barcode app. Steps to reproduce: - Disable tracking in Settings - Create a BOM for product Table with components Wood and Screws…
Fix an incorrect flow when creating a Manufacturing Order through the Barcode app. Steps to reproduce: - Disable tracking in Settings - Create a BOM for product Table with components Wood and Screws - In the Barcode app, go to Manufacturing - Click New > Add product and select Table - Click Confirm -> Components are not added after the Table line The issue occurs because `set_qty_producing` is called even when `lot_producing_id` is undefined, leading to a call to `_set_quantity_done` who will delete Stock Move Line since quantity done is 0. So, since SML was deleted, the `move_raw_line_ids` will also be affected. This happens when tracking is disabled, causing the condition `lineRecord.data.lot_producing_id != this.env.model.record.lot_producing_id` to evaluate as true (undefined != false), which triggers `set_qty_producing`. This fix ensures that `lot_producing_id` is defined before performing the comparison. opw-5165163 Forward-Port-Of: odoo/enterprise#104023 Forward-Port-Of: odoo/enterprise#98440
This update fixes a technical issue that prevented Odoo from properly exporting code translations for the new odoo.orm package. By specifying the package name in the framework's export process, Odoo can now accurately capture and manage code translations, ensuring consistent localization across the platform. This improves the quality and accuracy of our translated code.
Original PR description
New package odoo.orm was added in PR https://github.com/odoo/odoo/pull/182727 The new package's name must be specified in ``TranslationModuleReader._export_translatable_resources`` to allow the framework to export its code translations. 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#243584
This update resolves an issue where users without specific group permissions would prevent superuser mode from correctly pinning or unpinning embedded actions within the Documents module. The change adds a check for superuser status, ensuring these actions function as expected during automated processes or when using sudo. This improves stability and reliability for all users.
Original PR description
Prior to this commit, an AccessError would be raised when pinning or unpinning embedded actions if the current user did not belong to the 'documents.group_documents_user' group. This could cause issues during operations running in superuser mode (e.g., automated actions, installation scripts, or sudo() calls) because the check strictly validated the user's groups without considering the environment's superuser flag. This commit adds a check for `self.env.su` to ensure the AccessError is not raised when the environment is in superuser mode. Task-5380727 Forward-Port-Of: odoo/enterprise#104043 Forward-Port-Of: odoo/enterprise#101106
This update resolves an issue where user edits within the website builder preview were lost. The system now reverts the preview immediately upon user input, ensuring edits are saved correctly. This improves the user experience and prevents data loss during preview interactions.
Original PR description
Forward-Port-Of: odoo/odoo#243039
This update resolves an issue where the HTML editor would automatically highlight links when a new Todo was created and the page was refreshed. The fix ensures the highlighting only occurs when a user actively selects a link within the editor. This improves the user experience and prevents unexpected visual distractions.
Original PR description
Problem: Add a link as the first line in a todo and refresh the page. The link is highlighted as soon as the page loads, even though no selection was made by the user. Cause: After 880734ee1f1f4d20d92c44e3cedcf2c61c0da908, when the editor is loaded without an active selection, the selection is set to the first element in the editable. If that element is a link, the class `o_link_in_selection` is added automatically. Solution: Only add `o_link_in_selection` when the selection is on a link and the editable is focused. Steps to reproduce: - Open a Todo. - Add a link as the first text. - Refresh the page. - Observe the link is highlighted. task-5436106 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241277
This update fixes a visual issue where links within editable fields were incorrectly highlighted when the field itself wasn't focused. This change aligns the testing process with the corrected behavior, ensuring consistent and accurate highlighting. The fix was originally identified and addressed in the community version of Odoo.
Original PR description
Links that are the first deep node in an editable are highlighted even when the editable is not focused which was fixed in the community PR. Adapt the test to reflect the correct behavior opw-5436106 Forward-Port-Of: odoo/enterprise#103676
This update resolves an issue where weighing information lingered on the customer display after a product was weighed. Now, the display automatically clears when the weighing dialog is closed, ensuring a cleaner and more accurate customer experience. This improves the usability of the point-of-sale system.
Original PR description
Before this commit, after weighing a product, the weighing details would remain on the customer display even after closing the weighing dialog. Only weighing another product could get it to change. After this commit, the weighing details on the customer display are always cleared once the weighing dialog is closed.
This update optimizes how the Point of Sale system searches for related product information, like pricelists. Previously, searching was slow, especially with a large number of products. Now, the system uses a faster indexing method, resulting in quicker searches and a smoother user experience.
Original PR description
Before this commit, computing a back link (e.g., finding all pricelist items for a specific product template) required iterating over the entire collection of related records for every single record that accessed the property. In a POS with 1,000 products and 10,000 pricelist items, this resulted in $O(N \times M)$ complexity, causing noticeable UI lag during initialization or search. This commit introduces an indexed approach using a reactive effect. The first time a back link is accessed, an inverted index (Map) is built for the entire relation. Subsequent accesses by any record instance become a simple $O(1)$ Map lookup. opw-5448113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241783
This update fixes an issue where employee expense payments were incorrectly linked to the company bank account instead of the employee's. Now, when an employee submits an expense, the payment automatically uses their linked bank account, ensuring accurate and timely reimbursements. This improves the financial reporting and streamlines the expense process.
Original PR description
The aim of this commit is to fix the commercial partner id of the move lines to default to the move's partner commercial partner Steps to reproduce: - Have a bank account setup for the current company - Create an employee for a user, sets its `parent_id` to be the current company and set a bank account on the employee - Create an expense for said employee in `own_account` - Submit -> Pay flow - Bank account on the wizard is the company one, not the employee one After this commit: - Bank account on the wizard is the employee one, we stop pretending to reimburse them and actually give them money task-id: 5420587 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#240963
This update resolves an issue where Odoo encountered errors when processing emails with attachment content types incorrectly identified as '*/*'. To ensure emails are processed reliably, the system now defaults to 'application/octet-stream' for these cases, minimizing disruption while acknowledging the sender's responsibility for correct email formatting.
Original PR description
In some rare cases it would seem that some systems construct emails with attachments reporting `*/*` as the Content-Type. While trying to parse such content in Odoo, it causes issues with the…
In some rare cases it would seem that some systems construct emails with attachments reporting `*/*` as the Content-Type. While trying to parse such content in Odoo, it causes issues with the standard CPython email library, as no standard handler exists for '*/*' content-types: Example error: ``` File "/usr/lib/python3.13/email/contentmanager.py", line 25, in get_content raise KeyError(content_type) KeyError: '*/*' ``` This is not compliant with valid MIME types defined in RFC2046/section-3, but in real life scenarios, blocking the processing of an incoming email in Odoo because of this might be excessive. While not a perfect solution, we will assume that attachments falsly reported as `*/*` are to be processed as 'application/octet-stream' content types. This should cover most use-cases, and if it still fails, we will consider that it's up to the original email sender to be RFC compliant. OPW-5425093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242193
This update resolves an issue where clicking a link in the portal triggered a false 'page view' event for customers. A simple fix was implemented by adding a variable to the request headers from the link preview, ensuring accurate tracking of customer portal activity. This improves the reliability of our portal analytics.
Original PR description
When a link to the portal is sent from the chatter via message or log note, the preview of the link triggers that the page was viewed by customer. As a solution a variable was added to the request headers coming from the previewer. opw-5237785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243061
This update resolves an issue where user images within the referral module were not aligned correctly. The fix ensures a consistent and professional appearance for user profiles, enhancing the overall user experience. This improves the visual quality of the referral process.
Original PR description
This fix ensures that the user's image is correctly aligned task-5264613 Forward-Port-Of: odoo/enterprise#99488
This update resolves a problem that occurred when switching between accounting configurations (COAs) within the Hair Salon Point of Sale (POS) industry. The fix ensures that payment methods are correctly deleted during the CoA switch, preventing database errors and ensuring smooth operation.
Original PR description
Steps to reproduce: - Install industry Hair Salon - Settings > Invoicing > Fiscal Localization - Switch to Jordan fiscal localization Issue: Action will fail with error ``` ERROR: update or delete on table "account_journal" violates foreign key constraint "pos_payment_method_journal_id_fkey" on table "pos_payment_method" DETAIL: Key (id)=(6) is still referenced from table "pos_payment_method". ``` Analysis: It occurs because, when switching CoA, the system attempt to delete and re-create journals. However, the hair salon industry initialize a PoS configuration that will create a default payment method based on one of those journal, thus the system will raise a constraint error on delete. A solution is to manually enforce cascade delete when we are switching CoA. opw-5145235 Forward-Port-Of: odoo/odoo#243381 Forward-Port-Of: odoo/odoo#239433
This update fixes an issue where a distracting element appeared in the bank reconciliation journal when there were no transactions. The change hides this element when the quick-create view is open and empty, resulting in a cleaner and more professional user experience, particularly on mobile devices.
Original PR description
Before this PR, in the bank reconciliation journal, the no-content helper remained visible when the quick-create view was opened and there were 0 entries. This was unexpected behavior and caused overlapping issues, especially on mobile views. With this PR, the no-content helper is hidden whenever the quick-create view is open and there are 0 entries either isGrouped or not. task-5470591 Forward-Port-Of: odoo/enterprise#103776
This update resolves a bug where the default purchase tax wasn't correctly associated with the appropriate company in a multi-company Odoo setup. The fix ensures that the correct tax is selected when invoices are imported, preventing potential accounting errors. This improves data accuracy and reliability.
Original PR description
In v18.4, the invoice import has been refactored with these 2 PRs: - [189979](https://github.com/odoo/odoo/pull/189979) - [75327](https://github.com/odoo/enterprise/pull/75327) This introduced a small bug where, in a multi-company setup, an `account.tax` could be selected from the wrong company when `_fetch_mail()` was called from the cron `Mail: Fetchmail Service` or if the method was called manually from the wrong company. Ticket: opw-5375785 Forward-Port-Of: odoo/enterprise#103190
This update fixes an issue where the payment register incorrectly defaulted to the company bank account instead of the employee's bank account when processing reimbursements. The change re-enabled prioritization of employee bank accounts, ensuring accurate payment registration for employee expenses. This improves the accuracy of financial reporting.
Original PR description
**Steps to reproduce:** * Create an **employee** with a bank account. * Link the employee’s contact to the current company as a **child partner**. * Create an expense for that employee with payment mode **Paid by Employee**. * Submit, approve, and post the expense. * Open the **payment register** to reimburse the employee. **Observed behavior:** * The payment register defaults to the **company bank account** instead of the employee’s bank account. **Cause:** * The `account_payment_registered` file was removed in this commit: https://github.com/odoo/odoo/commit/704a5a19499469e5a14461bb81d33c832ce00d70#diff-f8829ed273c0ec8838636b1709ac4f895857992dddada6dbcbca3c62a2cbce81 * As a result, the payment register no longer prioritizes the employee’s bank account when the employee contact is linked to the company. **Fix:** * Added `account_register_payment` back to the `__init__` file. opw-5414133 Forward-Port-Of: odoo/odoo#242817
This update resolves a crash that occurred when using the 'Integer Rounding' option in accounting reports (like Aged Receivable). The issue stemmed from a calculation error when a report column returned a 'None' value. The fix ensures that rounding is skipped when a 'None' value is encountered, preventing the crash and improving report stability.
Original PR description
Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None. Steps to…
Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None. Steps to reproduce: 1) Install 'account_reports' module with demo data and enable developer mode. 2) Navigate to Accounting > Reporting> Partner Reports > Aged Receivable. 3) Click on 'gear icon' to navigate advance options. 4) Click on the Options tab and set Integer Rounding to 'Nearest', click save and close adv options. 5) Expand a partner line. Error: `TypeError: unsupported operand type(s) for /: 'NoneType' and 'int'` Root Cause: When integer rounding is enabled, the system iterates over formula results to round them using `float_round`(see[1]). However, specific report columns (such as totals for empty periods) may return None. The `float_round` function attempts to perform arithmetic on this value, failing because it cannot divide NoneType. FIX: Skip the rounding if the value received at [1] is None. [1]- https://github.com/odoo/enterprise/blob/9b517564d95424836da1e8368f6b5dc52ae45d1a/account_reports/models/account_report.py#L3329 opw-5392883 Forward-Port-Of: odoo/enterprise#102417
This update resolves an issue where the Shopee API testing environment no longer works due to a recent change by Shopee. The update corrects the API path used in our testing, ensuring continued functionality for our Shopee integration. This ensures our testing remains aligned with Shopee's current system.
Original PR description
Shopee has changed the API path and the original testing API paths are no longer valid. Forward-Port-Of: odoo/enterprise#103939
This update corrects a bug where delivery fees weren't accurately calculated when sales orders and company currencies differed. The fix ensures that delivery fees are now correctly priced based on the sales order's currency, preventing discrepancies in pricing. This improves the reliability of delivery cost calculations.
Original PR description
Issue ----- When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency. Example: Sale in…
Issue ----- When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency. Example: Sale in EUR, Company in USD and 1.5 EUR = 1 USD rate. Sell for 15 EUR of products => the delivery picking shows 10 EUR Steps to reproduce ----- - Activate EUR currency at 1.5 EUR = 1 USD rate - Setup company in USD - Setup INTL FEDEX delivery method - Create a dummy product with a 10 USD sale price - Create a pricelist using the EUR currency - Create a sale for some INTL client - set pricelist to EUR - add dummy product - add INTL FEDEX shipping - confirm the sale - Confirm the linked delivery > Message in chatter shows a price of 10 EUR instead of 15 EUR Cause ----- The problem is with the `carrier_price` field of `stock.picking`. https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L21 The value is set by https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L155 which gets its' value from the response of https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/delivery_fedex.py#L157 We then go through https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L382 where we call https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L484 The problem is that in `_decode_pricing` we take the first line matching the `rateType` with no regard to the currency of the rate https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L594-L598 we should also filter to ensure the rate matches the order's specified currency. ----- Ticket: opw-5419724 Forward-Port-Of: odoo/enterprise#103737 Forward-Port-Of: odoo/enterprise#103232
This update ensures that loyalty programs with pricelist restrictions are properly considered when a customer makes a purchase in the POS. Previously, the system would incorrectly apply loyalty programs even if the customer's purchase didn't match the program's pricing rules. This fix corrects a bug related to pricelist availability and ensures accurate loyalty program application.
Original PR description
Before this commit, if a loyalty program had pricelist restrictions, the POS would not consider them when loading the applicable loyalty programs. This could lead to scenarios where a loyalty program was applied in a POS session even if the session's pricelist was not allowed by the program. This happened when the pricelist was also not available in the POS configuration and program.pricelist_ids was empty. opw-5467990 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242279
This update resolves a problem where clients were incorrectly using outdated number ranges when syncing data with DIAN. The fix ensures that the latest available number range is always used, preventing invoice errors and improving data accuracy. This impacts invoice processing with Colombian DIAN regulations.
Original PR description
**PROBLEM** When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one. **STEP TO REPRODUCE**…
**PROBLEM** When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one. **STEP TO REPRODUCE** According to the DIAN documentation, the GetNumberRange service is only available in the production environment. So i'm not sure if we can safely test this. The repro steps would be something like: 1. Request a range. 2. Exhaust all number from this range by sending invoices to DIAN. 3. Request a new range. 4. sync with DIAN. (notice the range selected is still the old one). 5. Try sending a new invoice to DIAN and notice there is an error. **CAUSE** In `l10n_co_dian/models/account_journal.py` the function `_l10n_co_dian_get_journal_values()` loops on all the xml `NumberRangeResponse` node and store the last range values encountered for each prefix. We don't check if the this last range is still valid, if it's the newest created (could be checked with the xml field `ResolutionDate`, but the date could be the same if the range were created the same day), if it's the latest in term of number range (DIAN start with range 1-100, then 101-something etc.). Forward-Port-Of: odoo/enterprise#103943
This update corrects a previous navigation enhancement for the forum on mobile devices. The prior change caused an unnecessary breadcrumb display when the forum was part of a course. This fix ensures the correct breadcrumb is shown, improving the user experience and preventing duplicate navigation elements.
Original PR description
This PR fixes an oversight introduces in Commit[^1]. With Commit 1, we improved the navigation by showing the back button everywhere on the forum but this created an issue due to a rule in `website_slides_forum` rendering the whole breadcrumb if the forum is a course one. | saas-19.1 and above | This PR | |--------|--------| | <img width="391" height="205" alt="image" src="https://github.com/user-attachments/assets/385a6d95-d8b4-4693-8c13-457e2b06f2fe" /> | <img width="390" height="145" alt="image" src="https://github.com/user-attachments/assets/429979a9-ed09-4fe7-8ded-e95909a9c97b" /> | [^1]: https://github.com/odoo/odoo/commit/bb5b7cfa284a55e6dd3a5deb4870bcfae28033af task-5490243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr