Daily updates from Odoo
Navigate
Branch
Wednesday, January 14, 2026
400 changes
11 changes
New functionality added to Odoo
This update reflects new regulations from the Mexican government (DOF) regarding Employment Subsidy calculations for 2026. The UMA subsidy percentage has been adjusted to 15.59% from January 1st, 2026, and 15.02% from February 1st, 2026, ensuring compliance with current tax laws.
Original PR description
As per the DOF publication on December 31, 2025, the UMA percentages used to calculate the Employment Subsidy have been updated for 2026. New values: - From Jan 1st, 2026: 15.59% - From Feb 1st, 2026: 15.02% This commit adds these new parameter values to "Mexico: UMA Percentage for Subsidy". Reference: https://www.dof.gob.mx/nota_detalle.php?codigo=5777649&fecha=31/12/2025 target: 19.0 task-5488347 Forward-Port-Of: odoo/enterprise#104053
Enhancements to existing features
This update adds three new fields to invoices generated with the l10n_fr_facturx_chorus_pro module: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields are required for Chorus Pro compliance, ensuring invoices meet the necessary documentation standards for accurate financial reporting.
Original PR description
This commit: - Add three reference fields to invoice PDF for Chorus Pro compliance: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header when set on the invoice. task-5410836 Forward-Port-Of: odoo/odoo#240494
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
5 changes
New functionality added to Odoo
This update adds support for payment channels in Thailand (TH), Malaysia (MY), and Vietnam (VN) through Xendit. This expansion allows Odoo to process payments from these key markets, broadening our customer base and improving payment flexibility.
Original PR description
Xendit has expanded to TH, MY and VN supporting the local payment channels. This commit is to add the supported pamyent channels according to what they have added. task-4334511 Forward-Port-Of: odoo/odoo#189527
Resolved issues and error corrections
This update resolves an issue preventing receipt printing when multiple payment methods were used in the Italian POS (l10n_it_pos) module. The fix backports a change from another Odoo project, ensuring accurate receipt generation for all payment types. This improves the user experience for Italian POS users.
Original PR description
Backports of https://github.com/odoo/enterprise/pull/96353. References: See page 36 in the [official docs](https://download4.epson.biz/sec_pubs/bs/pdf/ePOS%20Fiscal%20Print%20Solution%20Development%20Guide%20Rev%20T.pdf). Ticket [link](https://www.odoo.com/odoo/project.task/5376242) opw-5376242 Forward-Port-Of: odoo/enterprise#103710
This update resolves an issue where users without specific group permissions would encounter errors when pinning or unpinning embedded actions, particularly within superuser mode. By adding a check for superuser status, the system now correctly allows superusers to perform these actions, ensuring stability for automated processes and installation scripts.
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 Odoo incorrectly searched for proxy users when a branch company had the same VAT/Codice Fiscale as its parent. This prevented users from correctly configuring Electronic Invoicing (IT EDI) for branch offices. The fix ensures the correct company is identified during proxy user searches, improving EDI processing reliability.
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 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 applications.
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
18 changes
New functionality added to Odoo
This update expands Odoo's payment capabilities to include Xendit, a popular payment gateway, in Thailand, Malaysia, and Vietnam. The changes add necessary configurations to support local payment channels, enabling businesses to accept payments from customers in these regions.
Original PR description
Xendit has expanded to TH, MY and VN supporting the local payment channels. This commit is to add the supported pamyent channels according to what they have added. task-4334511 Forward-Port-Of: odoo/odoo#189527
Enhancements to existing features
This update allows branch companies within Odoo to participate in the Peppol network. Users can register their branch as a sender for the parent company or create a new registration, providing greater flexibility for international trade and compliance. This change simplifies the process for businesses operating across multiple locations.
Original PR description
This commit implements the functionality to allow all branch company to use Peppol. With this commit, the user can register a branch company in the peppol network in two ways: - By setting the same EAS/Endpoint than the one set on the parent company, the branch will be registered as a sender for the parent company. - By setting another EAS/Endpoint than the one set on the parent company, the branch will do a new registration. task-4852830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240081
This update adds three new fields to invoices generated for Chorus Pro compliance – Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header, allowing for accurate documentation required by Chorus Pro and improving data tracking for financial reporting.
Original PR description
This commit: - Add three reference fields to invoice PDF for Chorus Pro compliance: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header when set on the invoice. task-5410836 Forward-Port-Of: odoo/odoo#240494
Resolved issues and error corrections
This update fixes a minor issue in the VoIP contact search test. Previously, the test could produce incorrect results due to data used in the demo environment. The fix now ensures the test only uses data created specifically for the test, leading to more reliable and accurate search results.
Original PR description
In the test, we suppose to find no phone number matched result when search term length is shorter than `_phone_search_min_length`. However, it can still match `name` or `email` if possible. In this fix, we change the test to only consider the data created in the test, to avoid the wrong result from demo data. backport odoo/enterprise#101200
This update fixes an issue where a distracting helper message remained visible in the bank reconciliation journal when there were no entries. The change hides this message, creating a cleaner and more professional experience, particularly on mobile devices. This improves usability and reduces visual clutter.
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
This update resolves an issue where FrontDesk hosts with restricted user access couldn't complete the visitor checkout process via email. The fix allows the checkout action to run with elevated permissions, ensuring all hosts can now successfully check out visitors without errors. This improves the usability of the FrontDesk module for all staff.
Original PR description
Steps to reproduce: * Create a visitor record with a host who has only FrontDesk user access. * Ensure Notify with Email is enabled on the station. * Click Check Out Visitor from the received email → access error appears. Issue: * Hosts with only FrontDesk user access received an access error when clicking the “Check Out Visitor” button from the email notification. * They were unable to complete the visitor checkout process. Fix: * Run the checkout action with sudo() so the host can successfully check out the visitor from the email link. Impact: * Hosts can now check out visitors without encountering permission errors. task-5373026
This update fixes an issue where follower list avatars appeared distorted, particularly with non-square images. The change utilizes a standard Odoo class for avatars, ensuring consistent and correct image scaling and ratios. This improves the visual appearance of the follower list for all users.
Original PR description
Before this commit, follower list menu had avatar that do not preserve ratio of avatars. This is noticeable for avatars that have ratio quite different from 1:1, like 3:2 or 2:3 or even less squarish. This happens because of missing `.o_object_fit_cover`, that [1] erroneously removed from REF of follower template part into its own component. This commit uses an equivalent but more official solution: `.o_avatar`, which is a classname dedicated for avatars, which has `.o_object_fit_cover` property. Task-5412078 Before / After <img width="638" height="526" alt="Screenshot 2026-01-12 at 17 23 54" src="https://github.com/user-attachments/assets/b8d3a921-52a8-48b7-a0d0-5fbfdd33a92c" /> <img width="640" height="528" alt="Screenshot 2026-01-12 at 17 23 33" src="https://github.com/user-attachments/assets/8070420c-f341-4085-bcb2-2fba060765f0" /> [1]: https://github.com/odoo/odoo/pull/200382
This update resolves a bug in the General Ledger reporting where analytic group by functionality was producing incorrect results and leading to inaccurate journal entry views. The fix corrects a data ID mismatch, ensuring that the correct journal entries are displayed when grouping by analytic accounts. This improves the accuracy of financial reporting.
Original PR description
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report ->…
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report -> General Ledger -> Options - Activate "Analytic Group By" - Create an invoice - add a line with an analytic account - Confirm the Invoice - Duplicate the invoice - Confirm the second invoice - Go to the General Ledger - Group By the analytic account you used Current Behavior: General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger. Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry. Expected behavior: - "View Journal Entry" should send to the right entry Proposed Solution: To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id. However, lines are merged into only one single line. opw-5267981 Forward-Port-Of: odoo/enterprise#103169
This update fixes an issue where a specific error occurred when a leave request was linked to a refused allocation and the system's automated cleanup process ran. The fix addresses a problem with how data was being accessed, preventing a traceback and ensuring the system functions correctly under these circumstances. This improves the reliability of leave management.
Original PR description
When a leave is linked to a refused allocation and the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs. Steps to reproduce the error: - Install ``hr_holidays`` without demo data -…
When a leave is linked to a refused allocation and
the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs.
Steps to reproduce the error:
- Install ``hr_holidays`` without demo data
- Create a new Time Off Type > Time Off Requests, Approval: No Validation >
Allow Negative Cap: True > Maximum Excess Amount: 2
- Create an Accrual Plan using default values
- Create a New Allocation
- Allocation Type: Accrual Allocation
- Set the Time Off Type and Accrual Plan created above
- Allocation: 1 day > Approve
- Create a new Time Off in the near future (in the current month) and select the Time Off Type created above
- Go back to the Allocation > Refuse
- Run the cron ``Time Off: Cancel invalid leaves``
Traceback:
``IndexError: list index out of range``
https://github.com/odoo/odoo/blob/bc5f24195a486112574900015ecbcf0e3ba32145/addons/hr_holidays/models/hr_leave.py#L1535-L1536
Here, ``leave_type_data`` becomes ``defaultdict(<class 'list'>, {})``
because when the allocation is refused and the cron runs,
the ``get_allocation_data`` method returns an empty defaultdict.
As a result, accessing the index leads to the above traceback.
sentry-6874651972
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243315
Forward-Port-Of: odoo/odoo#227201This update resolves an issue where the height of image gallery snippets would unexpectedly reset after changing image order or manually adjusting the height. The fix removes outdated code and ensures the snippet's height remains consistent with the user's input, providing a more reliable and predictable gallery experience. Minor template issues were also addressed.
Original PR description
Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The…
Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The snippet height is automatically reset to `70%` of the screen height. Scenario B 1. Change the height value of the snippet from the `"Height"` option. 2. Select an image → change its order in the carousel → The snippet height is again reset (and the option value is overridden). Issue The original height behavior was introduced in [1] to make the slideshow mode auto-adapt to `70%` of the viewport height. This diff also removed height CSS for other modes where the height should depend on the content [2] Subsequent adaptations: [3] added a default height (`500px`) in XML, [4] removed it during a design refactoring, [5] restored the possibility to control the height of the image gallery snippet using the `"Height"` option. Keeping the same JS logic that forces the snippet height, led to the behavior explained above: even when the user manually sets a height, any action triggering `slideshow()` (e.g., image reorder) forces the height back to 70% of `window.innerHeight`. Fix 1. Remove the outdated JS code that automatically updates the height. 2. Keep the slideshow behavior consistent with [2] by excluding it from the height CSS removal logic. The snippet now starts with a default height and only changes when edited through the `"Height"` input. Additional fixes This commit also fixes a few minor issues in the new carousel items template introduced in [4]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/239b6bc0b5a2a644486737f2b0b71e7e6c0a2edf [3]: https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7 [4]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 [5]: https://github.com/odoo/odoo/commit/d5d138e833344e857a420d865d4b12f1acdb0e7c task-3414281 Forward-Port-Of: odoo/odoo#242385 Forward-Port-Of: odoo/odoo#126766
This update resolves an issue where automated time tracking activities were delayed in creating due to a problem with how the system recomputed dependent fields. Specifically, when a pre-filter condition in an automation rule cleared the compute flag for related fields, the system failed to update them correctly. This resulted in delays, particularly when exceeding allocated time.
Original PR description
This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323 When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled…
This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323
When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled afterwards For example, if a rule pre-filters on field B (which depends on A), computing A should not clear the compute flag of B
### Issue:
In some automation rules, computed fields must be processed in a specific order (e.g., `effective_hours` -> `remaining_hours`)
However, if `remaining_hours` is referenced in the automation `Before Update Domain`, its compute flag may be incorrectly cleared, preventing the proper recomputation chain
This results in inconsistent behavior, such as delays in activities being created when timesheets exceed allocated time
### Cause:
The automation engine flushes fields referenced in the `Before Update Domain`, but does not restore their compute flags afterward Thus dependent fields are not recomputed as expected
### Steps to reproduce:
1. Enable Debug Mode
2. Create an Automation Rule
-- Name: Time Exceeded
-- Model: Task
-- Trigger: On Save
-- Before Update Domain: [("remaining_hours", ">=", 0)]
-- Apply on: [("remaining_hours", "<", 0)]
4. Create a Project with Timesheets
5. Create a Task inside the Project
6. Set Allocated Time to 10h
7. Use the Start button to record 11h (No activity appears in chatter)
8. Do the same again (Activity appears only after the second exceed) Before the fix, there is always a delay because the recomputation chain is broken
### Tickets:
18.0: opw-4409744
17.0: opw-5237430
Forward-Port-Of: odoo/odoo#243059
Forward-Port-Of: odoo/odoo#239667This update resolves an issue preventing the printing of receipts when multiple payment methods (e.g., cash, credit card) were used in the l10n_it_pos module. The change backports a fix from another Odoo project, ensuring accurate receipt generation for Italian Point of Sale transactions. This improves the user experience and compliance with fiscal requirements.
Original PR description
Backports of https://github.com/odoo/enterprise/pull/96353. References: See page 36 in the [official docs](https://download4.epson.biz/sec_pubs/bs/pdf/ePOS%20Fiscal%20Print%20Solution%20Development%20Guide%20Rev%20T.pdf). Ticket [link](https://www.odoo.com/odoo/project.task/5376242) opw-5376242 Forward-Port-Of: odoo/enterprise#103710
This update resolves an issue where superuser mode prevented users from correctly pinning or unpinning embedded actions within the Documents module. The change adds a check for superuser status, allowing superusers to perform these actions without errors, which is crucial for automated processes and installation scripts.
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 corrects a critical issue with the Odoo Enterprise system's testing environment for Shopee integration. Shopee recently changed their API paths, rendering the existing testing configurations invalid. This fix ensures accurate testing and continued functionality with the Shopee platform.
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 resolves an issue where Odoo incorrectly searched for proxy users when a branch company had the same VAT number as its parent. This prevented proper Electronic Invoicing setup for branch companies. The fix ensures the correct company is used for proxy user searches, improving functionality for businesses with multiple entities.
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 fixes an issue where matching a partner by bank account could be overwritten by a subsequent match using the partner's name. This ensures that the correct partner is always associated with bank statements, improving data accuracy and reliability. The change prevents redundant matching and avoids incorrect partner assignments.
Original PR description
Ensure the retrive partner from partner name doesn't override the retrieve partner from bank account. When retrieving a partner on an st_line, we first check for a match based on the bank account, and then on the partner name. However, we fail to check if a match was already found before searching by name. This means that if a partner is matched via bank account, and subsequently another match is found via name, the first match gets overridden by the second one. This commit adds a check for st_line.partner_id before attempting further matching, preventing the previous result from being overridden. no-task
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 availability of translated code for our users.
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 fixes a limitation in the portal's canned response feature, allowing internal users to properly access and utilize available responses. The previous fix was reverted to ensure correct functionality and prepare for future support of the `::` delimiter in the portal. This enhancement improves the user experience for portal users.
Original PR description
*: im_livechat, portal, project, test_mail_full PR #192953 introduces a composer action for canned responses. The feature is available in portal for internal users but since `suggestion` is disabled in portal, this feature doesn't work properly. In preparation for supporting `::` delimiter in portal, the incorrect fix in PR #231360 has been reverted. `inFrontendPortalChatter` is specific to portal frontend and should not be set to `true` in the project sharing environment. Instead of the mentioned fix, a similar fix from PR #231441 has been backported. task-5262349 Forward-Port-Of: odoo/odoo#235551
7 changes
New functionality added to Odoo
This update expands Odoo's payment capabilities to include Xendit, a popular payment gateway, in Thailand, Malaysia, and Vietnam. The changes add the necessary configurations to support local payment channels through Xendit, enabling businesses to accept payments from customers in these regions.
Original PR description
Xendit has expanded to TH, MY and VN supporting the local payment channels. This commit is to add the supported pamyent channels according to what they have added. task-4334511 Forward-Port-Of: odoo/odoo#189527
Enhancements to existing features
This update adds three new fields to Odoo invoice PDFs – Buyer Reference, Contract Reference, and Purchase Order Reference – to ensure compliance with Chorus Pro requirements. These fields allow users to accurately document key purchase information directly on the invoice, simplifying the invoicing process for Chorus Pro clients.
Original PR description
This commit: - Add three reference fields to invoice PDF for Chorus Pro compliance: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header when set on the invoice. task-5410836 Forward-Port-Of: odoo/odoo#240494
Resolved issues and error corrections
This update resolves an issue preventing users in the l10n_it_pos module from printing receipts when multiple payment methods were used. The change backports a fix from another Odoo project, ensuring accurate receipt generation for Italian Point of Sale transactions. This improves the user experience and compliance with fiscal requirements.
Original PR description
Backports of https://github.com/odoo/enterprise/pull/96353. References: See page 36 in the [official docs](https://download4.epson.biz/sec_pubs/bs/pdf/ePOS%20Fiscal%20Print%20Solution%20Development%20Guide%20Rev%20T.pdf). Ticket [link](https://www.odoo.com/odoo/project.task/5376242) opw-5376242 Forward-Port-Of: odoo/enterprise#103710
This update corrects a critical issue with the Odoo Enterprise system's testing environment for Shopee integration. Shopee recently altered their API paths, rendering the previous testing configurations invalid. This fix ensures the testing environment accurately reflects the current Shopee API, maintaining reliable testing and development.
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 resolves an issue where the location of merged manufacturing orders wasn't correctly linked to subsequent transfer orders. The fix ensures that the final location of merged MOs is accurately propagated, preventing incorrect stock movements and improving the reliability of multi-location workflows. This primarily impacts complex manufacturing processes.
Original PR description
Situation ----- When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in…
Situation ----- When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1054 because of the `m.location_id == move.location_final_id` part being false in https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1090-L1097 This is because, during the merge, `location_final_id` is not propagated to the new MO https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L2416-L2424 so when the new MO's `move_finished_id` gets computed https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L822 it gets the MO's `location_final_id` https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L1202 which is false. This leads to to the move getting the warehouse's default stock location thanks to https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/mrp/models/stock_move.py#L456-L457 This is problematic for complex use cases with multi-locations and custom routes. It should be safe to propagate the `location_final_id` of the merged MOs if they all share the same one. Use case example ----- <details> <summary>Full use case</summary> - Enable multi-step routes - Create location "WH/Stock/L1" - Create location "WH/Stock/L2" - Create Operation Type "MO child" - Type of Operation: Manufacturing - Sequence Prefix: MOCHILD - Source Location: L1 - Destination Location: L2 - Create Operation Type "Push Transfer" - Type of Operation: Internal Transfer - Sequence Prefix: L2L1 - Source Location: L2 - Destination Location: L1 - Create Route "MO child" - Create Rule "Manufacture" - Action: Manufacture - Operation Type: MO child - Source Location: False - Destination Location: Stock - Create Route "2-step" - Warehouse: Main WH - Create Rule "L1 -> Virtual/Production" - Action: Pull from - Operation Type: MO child - Source Location: L1 - Destination Location: Virtual/Production - Create Rule "Push: L2 -> L1" - Action: Push To - Operation Type: Push Transfer - Source Location: L2 - Destination Location: L1 - Unarchive MTO - Edit MTO route - Create Rule "L1 -> Virtual/production (MTO)" - Action: Pull - Operation Type: "My Company: Manufacturing" - Source Location: L1 - Destination Location: Virtual/Production - Supply Method: Trigger another rule - Create product "Main product" - Create product "Child product" - Routes: "MO child" & MTO - Create product "Material" (consumable) - Create BOM - Product: "Main product" - Component: "Child product" - Create BOM - Product: "Child product" - Component: "Material" - Create MO for "Main product" - Misc/Component Location set to L1 - Duplicate the MO - Merge child MOs & produce - Validate merged MO transfer to L1 - Go back to one of the "Main product" MO > Component quantity is 0 </details> ----- Ticket: opw-5144196 Forward-Port-Of: odoo/odoo#240695
This update resolves an issue where printing reports using custom handlers (like IoT) didn't automatically close the associated wizard. Previously, the wizard remained open, leading to unexpected behavior. Now, the system correctly closes the wizard after a report download, regardless of the handler used.
Original PR description
Problem: When an alternate ir.action.report handler is used (such as for IoT), the logic to close the wizard after the report is downloaded (printed) is skipped, so the wizard stays open. Steps to Reproduce: - Go to "Acoustic Bloc Screens" product and click "Print Labels" - Select "ZPL labels" and confirm - The report downloads and the wizard closes as expected - Go to Settings > Technical > Reports and select "Product Label (ZPL)" - Set an IoT device on the report - "Print Labels" again, selecting a printer and the IoT toasts in the top right appear after the wizard closes - Refresh the page, and try printing again - The wizard stays open (wrong) and the IoT toasts appear Solution: When returning from the custom handler, check if close_on_report_download and close the wizard. opw-5153139 Forward-Port-Of: odoo/odoo#238247
This update ensures that rating cards are only shown in portal chatter when a module specifically requests them. Previously, rating cards were displayed even when a module didn't explicitly enable the feature, leading to a cluttered user experience. This change improves the portal's clarity and focus.
Original PR description
*: test_mail_full Modules using portal rating can set an `data-display_rating` attribute when calling the portal chatter template to indicate whether they want the rating feature displayed. Currently, only two modules have this attribute set to true: ecommerce and elearning. For other modules that don't set this attribute, even if there is a rating, such as when rating a ticket in the helpdesk module, we don't want the rating card feature to be shown in portal chatter. This change ensures that the feature is only available if the module requests it. task-5347848 Forward-Port-Of: odoo/odoo#243255
39 changes
New functionality added to Odoo
This update reflects new regulations from the Mexican government (DOF) regarding Employment Subsidy calculations for 2026. The UMA subsidy percentage has been adjusted to 15.59% starting January 1st, 2026, and 15.02% starting February 1st, 2026. This ensures compliance with current tax laws.
Original PR description
As per the DOF publication on December 31, 2025, the UMA percentages used to calculate the Employment Subsidy have been updated for 2026. New values: - From Jan 1st, 2026: 15.59% - From Feb 1st, 2026: 15.02% This commit adds these new parameter values to "Mexico: UMA Percentage for Subsidy". Reference: https://www.dof.gob.mx/nota_detalle.php?codigo=5777649&fecha=31/12/2025 target: 19.0 task-5488347 Forward-Port-Of: odoo/enterprise#104053
Enhancements to existing features
This update streamlines the process of canceling NFC-e receipts generated from Point of Sale orders. Previously, users had to manually handle cancellations through the SEFAZ portal, which was time-consuming. Now, a new button within the back-end allows for direct cancellation, improving efficiency and reducing manual effort.
Original PR description
With this **PR**, NFC-e generated from PoS orders can now be canceled directly from the back-end. Previously, users were required to manually perform the cancellation through the SEFAZ portal, which was cumbersome. A new button is added on the PoS order form to trigger the NFC-e cancellation. Upon successful cancellation, the related XML is saved and attached to the chatter. If an error occurs, a user-friendly message is displayed showing the relevant error code and description returned by SEFAZ/Avalara. **task**-5254905
This update ensures that withholding taxes are correctly reflected when uploading vendor bills from electronic invoices in Colombia. Previously, the system didn't recognize withholding taxes in XML files, leading to inaccurate bill uploads. Now, the XML parser accurately captures and includes these taxes, improving data accuracy for Colombian accounting.
Original PR description
Purpose: For Colombia, it is possible to upload vendor bills by drag and dropping the electronic invoice XML into the purchase journal. The XML file is parsed through for relevant information to create the vendor bill. Since vendor bills in Colombia will typically include withholding taxes, the parser should handle this case for a more accurate bill upload. Current Behavior: When uploading XML files that includes withholding taxes, the withholding taxes are not reflected on the uploaded vendor bill. Expected Behavior: When uploading XML files that includes withholding taxes, the withholding taxes are reflected on the uploaded vendor bill. task-5255094
This update enhances our document generation to meet the stricter PDF/A-3A standard, ensuring compatibility with a wider range of PDF viewers and archiving systems. The changes address previous validation failures and incorporate new requirements for PDF/A-3A compliance, improving document accessibility and long-term preservation.
Original PR description
This commit upgrades our PDF/A compliance from 3B to 3A, and fixes a few issues previously undetected due to the different PyPDF libraries we're currently supporting that made the previous PDF fails…
This commit upgrades our PDF/A compliance from 3B to 3A, and fixes a few issues previously undetected due to the different PyPDF libraries we're currently supporting that made the previous PDF fails even the 3B validation. Improvement 1: PDFA validators were previously detecting our file as 3B. Hence we update the metadata content `conformance` to `A`. Issue 2: When using `._pypdf` library, we failed the 6.1.2-2 and 6.8-1 rule even though we have implemented them on the previous version. It seems that this is caused by the `if SUBMOD...` check only ensuring it's not equal to `_pypdf2_2` (which makes it trigger for the new `_pypdf`). Hence, we reclarify the comments and fix the IF check. Issue 3: After implementing issue 2, it seems that a traceback occurs every time we're using `._pypdf` and calling the pdf write method. This is because the added characters on the header can't be decoded with `UTF-8`. Hence we change it to other greater-than-127-bytes characters that can still be decoded with `UTF-8`. (The actual character used here doesn't matter). Improvement 4: To be compliant with the new 3A rules (additional rules not there in 3B when we first implemented them), we add a minimal mark info dictionary and document structure on the PDF catalog object (`_root_object`). task-None Forward-Port-Of: odoo/odoo#243171 Forward-Port-Of: odoo/odoo#234960
This update makes the HR Applicant data available for use in other Odoo modules. Previously, this data was isolated. This change improves data flow and allows for more integrated HR processes within the system.
Original PR description
Export HrApplicant model so that it can be used in other modules Task-[5461729](https://www.odoo.com/odoo/5778/tasks/5461729) Enterprise PR odoo/enterprise#103402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243317
This update adds three new fields to Odoo invoice PDFs – Buyer Reference, Contract Reference, and Purchase Order Reference – to comply with Chorus Pro requirements. These fields allow users to accurately document key purchase information directly on the invoice, streamlining the accounting process for Chorus Pro transactions.
Original PR description
This commit: - Add three reference fields to invoice PDF for Chorus Pro compliance: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header when set on the invoice. task-5410836 Forward-Port-Of: odoo/odoo#240494
Resolved issues and error corrections
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to the 3000 deduction. The change ensures that the deduction amount is accurately reflected up to the year 2026, aligning with updated Belgian tax regulations. This ensures accurate payroll processing and compliance for businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#103891 Forward-Port-Of: odoo/enterprise#103824
This update resolves an issue where credit notes with discounts were being rejected by SUNAT. The fix prevents users from creating credit or debit notes with line discounts, aligning with SUNAT regulations that treat credit notes as pure amount adjustments. This ensures proper EDI validation and processing of credit notes in Peru.
Original PR description
Steps to reproduce: - With a PE Company setup - Create an Invoice with "Document Type" set to "(01) Factura" - Set a discount on the invoice line - Confirm and send for validation - Create the credit…
Steps to reproduce: - With a PE Company setup - Create an Invoice with "Document Type" set to "(01) Factura" - Set a discount on the invoice line - Confirm and send for validation - Create the credit note - Confirm the credit note and send for validation Issue: Credit note validation will fail with error `3271|El valor de venta por ítem difiere de los importes consignados. - Detalle: xxx.xxx.xxx value='ticket: 1767185167086 error: Error en la linea: 1: 3271 (nodo: "cac:CreditNoteLine/cbc:LineExtensionAmount" valor: "600.00")'` This occurs because while UBL standard allows AllowanceCharge in credit notes, SUNAT does not. Credit notes are treated as pure amount adjustments, not price recalculations. Discounts were already applied in the invoice, so SUNAT ignores AllowanceCharge in CN, causing error 3271. With this commit we introduce a check to ensure users won't post edi credit or debit notes containing line discounts opw-5414766 Forward-Port-Of: odoo/enterprise#103106
This update corrects small errors in the 2026 balance sheet and profit & loss reports for the Danish localization. These changes involve correcting formula signs and text labels, likely due to an oversight during development. This ensures accurate financial reporting for Danish businesses using Odoo Enterprise.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/0d431fe2cc6556a040888ecc5d6a71be4a435447 we introduce a new balance sheet report for 2026 but there was a mistake in the sign of a formula and in the text of a line. Same for the profit and loss, some errors in sign of accounts and naming. The errors don't come from a ticket but more of a logical fix, those errors were probably an oversight during development. no task id Forward-Port-Of: odoo/enterprise#103830
This update clarifies the call settings for users who have muted a participant. Previously, the menu and hints were confusing, showing the deafen icon with the unmute label. Now, only the 'undeafen' button is displayed when a participant is muted, streamlining the user experience and ensuring clarity.
Original PR description
Before this commit, the hint in the call settings was not taking into account if it was deafen or mute. On top of that the icon in the menu was showing the deafen icon but with the unmute label. When deafened, this was redundant with the undeafen button as well since unmute and undeafen are practically doing the same thing. Now, when deafen is activated, only the undeafen button is shown in the call menu and the hint in the call actions is undeafen not unmute. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242887 Forward-Port-Of: odoo/odoo#242519
This update corrects a recent change to the access rights for the account online synchronization feature, ensuring it's correctly linked to Invoicing & Banks. The previous update missed a crucial step, preventing proper access control, and this fix resolves that oversight.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/6edc057a9c0459af2b6d625415b700daf6280520 we changed the access rights of the account online sync to Invoicing & Banks but forgot to add the duplicate transactions no task id Forward-Port-Of: odoo/enterprise#104008
This update fixes an issue where the HTML editor would incorrectly display extra lines when multiple lines were selected. The change filters out empty text nodes to prevent unnecessary font wrappers, resulting in cleaner and more accurate rendering of selected text.
Original PR description
**Current behavior before PR:** - When multiple lines were selected within a block, any empty text nodes between them would also receive a font wrapper when applying a color. - As a result, it appeared as though an extra line was being inserted when the color was applied. **Desired behavior after PR is merged:** - Empty text nodes that are not visible and are not zero-width space or line-break nodes are now filtered out before the font tag is created. - This prevents font wrappers from being created around those nodes. task-5344051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236824
This update resolves a minor typo in the Odoo Enterprise system. Specifically, the name of an attachment file was corrected to align with its intended functionality and external ID. This ensures data consistency and proper operation within the accounting module.
Original PR description
Fix typo – Correct the ir_attachment file name to match the external ID and its functionality. OPW-5428700 Forward-Port-Of: odoo/enterprise#103809
This update resolves a security issue where users could access softphone features (creating or viewing tickets/applicants) without the necessary permissions. The fix adds crucial permission checks to the softphone interface, ensuring only authorized users can perform these actions. This improves security and prevents unauthorized access to sensitive functionality.
Original PR description
The ticket/applicant create/view buttons on softphone are missing permission check. Add them. Task-5461729 Forward-Port-Of: odoo/enterprise#103402
This update resolves an issue where payment processing could fail due to unexpected text responses from providers like Flutterwave and Worldline during outages. The system now gracefully handles these responses, preventing errors and ensuring smoother payment processing. This improves the reliability of our payment integrations.
Original PR description
Both Flutterwave and Worldline may respond with plain text rather than JSON-formatted responses when a Cloudflare outage occurs. This would lead to a traceback in Odoo when trying to extract the error message from the request response. This commit introduces a fallback to the text content of the response when any provider fails to parse the response as a JSON content. opw-5403982 Forward-Port-Of: odoo/odoo#242894
This update fixes a minor issue in the Sendcloud integration where the system was incorrectly retrieving product information. The change ensures that product IDs are accessed using the correct 'id' key, resolving a potential data retrieval problem. This improves the reliability of sending orders through Sendcloud.
Original PR description
Same fix as d4fae97, the id was retrieved by doing `[0]` but the proxy object has changed so we need to use the `id` key to get the value instead. ----- Ticket: opw-5433254 Forward-Port-Of: odoo/enterprise#103706
This update fixes an issue where users without write access couldn't star messages in threads, resulting in an error. The fix adds a necessary permission adjustment to allow users to star messages they can read, ensuring broader functionality for all users. This improves the user experience and prevents a frustrating access error.
Original PR description
Before this commit, starring a message in a thread without write access would result in an access error. This happens because since [1] a message is marked as starred by writing on the `starred_partner_ids` field of mail.message instead of the `starred_message_ids` field of res.partner. This results in an access error when the uses does not have write access. This commit fixes the issue by adding a sudo call to the write of `starred_partner_ids`, which is acceptable because a user should always be able to star a message they can read. [1] https://github.com/odoo/odoo/pull/219282 task-5481662 Forward-Port-Of: odoo/odoo#243130
The issue was caused by an inefficient domain optimization during a calculation involving deferred revenue. The optimized domain resulted in a large number of records being evaluated, leading to a memory exhaustion (MemoryError). This fix improves the domain optimization process to reduce the number of records processed, preventing the memory issue.
Original PR description
**Description:** - The [Invoices To Be Issued and Invoiced Not Delivered](https://github.com/odoo/enterprise/blob/19.0/sale_account_accountant/views/sale_order_line_views.xml#L73-L91)…
**Description:**
- The [Invoices To Be Issued and Invoiced Not Delivered](https://github.com/odoo/enterprise/blob/19.0/sale_account_accountant/views/sale_order_line_views.xml#L73-L91)
ir.actions.act_window menus from the sale_account_accountant module were triggering MemoryError on databases with millions of sale.order.line records. These actions call [_search_invoice_to_be_issued and _search_deferred_revenue](https://github.com/odoo/enterprise/blob/master/sale_account_accountant/models/sale_order_line.py#L17-L29)
which iterate over all lines and access the non-stored computed fields [qty_delivered_at_date](https://github.com/odoo/odoo/blob/master/addons/sale/models/sale_order_line.py#L905) and [qty_invoiced_at_date](https://github.com/odoo/odoo/blob/master/addons/sale/models/sale_order_line.py#L985).
- On similar lines, two additional menus—[Bill To Receive and Billed Not Received](https://github.com/odoo/enterprise/blob/19.0/purchase_accountant/views/purchase_order_line_views.xml#L61-L78)
were introduced from the purchase_accountant module. These menus were also triggering MemoryError on databases with a large number of purchase.order.line records. These actions call [_search_prepaid_expense and _search_bill_to_receive](https://github.com/odoo/enterprise/blob/19.0/purchase_accountant/models/purchase_order_line.py#L17-L29) which iterate over all lines and access the non-stored computed fields [qty_invoiced_at_date](https://github.com/odoo/odoo/blob/19.0/addons/purchase/models/purchase_order_line.py#L180) and [qty_received_at_date](https://github.com/odoo/odoo/blob/19.0/addons/purchase/models/purchase_order_line.py#L234).
- To resolve this, we refined _get_accrual_domain to include only lines within a one-year range, from the given accrual date (or today) back to one year earlier, and used split_every in the accrual searches to process the recordset in chunks.
```
matu_3625797_19.0=> select count(*) from sale_order_line;
count
---------
2228032
(1 row)
matu_3625797_19.0=> select count(*) from purchase_order_line;
count
--------
581637
(1 row)
```
**Traceback1:**
```
2025-12-03 07:02:25,973 9344 ␛[1;31m␛[1;49mERROR␛[0m matu_3306966_19.0 odoo.addons.base.maintenance.migrations.base.testsodoo.upgrade.base.tests.test_mock_crawl: Adding menu ('sale_account_accountant.menu_sale_order_line_accrual_to_bill_action', 1295, 'Accounting > Review > Sales > Invoices To Be Issued', 2690) to the failing menus
Traceback (most recent call last):
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 644, in mock_view_list
return self.mock_view_tree(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 655, in mock_view_tree
self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 713, in mock_web_read_group
data = model.web_read_group(domain, [groupby], aggregates, limit=limit)["groups"]
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 397, in web_read_group
groups, length = self._formatted_read_group_with_length(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 465, in _formatted_read_group_with_length
groups = self.formatted_read_group(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 830, in formatted_read_group
groups = self._read_group(
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 33, in _read_group
return self._read_group_for_accrual(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/enterprise/19.0/account_accountant/models/analytic_mixin.py", line 21, in _read_group_for_accrual
return super()._read_group(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1904, in _read_group
query = self._search(domain)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5361, in _search
domain = domain.optimize_full(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 445, in optimize_full
return self._optimize(model, OptimizationLevel.FULL)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in _optimize_step
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in <genexpr>
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 957, in _optimize_step
domain = self._optimize_field_search_method(model)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in _optimize_field_search_method
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in OR
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 595, in apply
children = cls._flatten(items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in <genexpr>
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in <genexpr>
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1921, in determine_domain
return determine(self.search, records, operator, value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 28, in _search_invoice_to_be_issued
ids = [line.id for line in so_lines if line.qty_invoiced_at_date < line.qty_delivered_at_date]
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 28, in <listcomp>
ids = [line.id for line in so_lines if line.qty_invoiced_at_date < line.qty_delivered_at_date]
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1737, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1908, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/19.0/addons/base_automation/models/base_automation.py", line 907, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4949, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/odoo/19.0/addons/sale/models/sale_order_line.py", line 989, in _compute_qty_invoiced_at_date
line.qty_invoiced_at_date = line.qty_invoiced
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1693, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
field._insert_cache(fetched, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1600, in _insert_cache
collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```
**Traceback2:**
```
2025-12-03 07:02:30,098 9344 ␛[1;31m␛[1;49mERROR␛[0m matu_3306966_19.0 odoo.addons.base.maintenance.migrations.base.testsodoo.upgrade.base.tests.test_mock_crawl: Adding menu ('sale_account_accountant.menu_sale_order_line_accrual_deferred_revenues_action', 1296, 'Accounting > Review > Sales > Invoiced Not Delivered', 2691) to the failing menus
Traceback (most recent call last):
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 644, in mock_view_list
return self.mock_view_tree(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 655, in mock_view_tree
self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 713, in mock_web_read_group
data = model.web_read_group(domain, [groupby], aggregates, limit=limit)["groups"]
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 397, in web_read_group
groups, length = self._formatted_read_group_with_length(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 465, in _formatted_read_group_with_length
groups = self.formatted_read_group(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 830, in formatted_read_group
groups = self._read_group(
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 33, in _read_group
return self._read_group_for_accrual(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/enterprise/19.0/account_accountant/models/analytic_mixin.py", line 21, in _read_group_for_accrual
return super()._read_group(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1904, in _read_group
query = self._search(domain)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5361, in _search
domain = domain.optimize_full(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 445, in optimize_full
return self._optimize(model, OptimizationLevel.FULL)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in _optimize_step
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in <genexpr>
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 957, in _optimize_step
domain = self._optimize_field_search_method(model)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in _optimize_field_search_method
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in OR
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 595, in apply
children = cls._flatten(items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in <genexpr>
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in <genexpr>
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1921, in determine_domain
return determine(self.search, records, operator, value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 21, in _search_deferred_revenue
ids = [line.id for line in so_lines if line.qty_invoiced_at_date > line.qty_delivered_at_date]
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 21, in <listcomp>
ids = [line.id for line in so_lines if line.qty_invoiced_at_date > line.qty_delivered_at_date]
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1737, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1908, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/19.0/addons/base_automation/models/base_automation.py", line 907, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4949, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/odoo/19.0/addons/sale/models/sale_order_line.py", line 989, in _compute_qty_invoiced_at_date
line.qty_invoiced_at_date = line.qty_invoiced
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1693, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
field._insert_cache(fetched, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields_textual.py", line 243, in _insert_cache
super()._insert_cache(records, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1600, in _insert_cache
collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```
- opw-5238152, opw-5269996
- upg-3306966, 3444833
Forward-Port-Of: odoo/enterprise#101677This update fixes a bug where purchase orders created from purchase agreements didn't correctly apply taxes set by the parent company. The change ensures that taxes associated with agreements are now accurately reflected on child company purchase orders, improving financial reporting and accuracy. This resolves an issue impacting how taxes are calculated across the Odoo system.
Original PR description
### Issue: In a child company, adding a product from a Purchase Agreement to a Purchase Order does not apply the associated parent company's purchase taxes ### Cause: In the onchange, taxes were filtered by company: ```python taxes_ids = fpos.map_tax(line.product_id.supplier_taxes_id.filtered(lambda tax: tax.company_id == requisition.company_id)).ids ``` This filter fails for taxes belonging to the parent company, so they were not applied on the child company purchase order ### Steps to reproduce: - Create a company branch and switch to it - Enable `Purchase Agreements` in Settings - Create a product with a Purchase Taxes (ex. 15%) - Create a Purchase Agreement for any vendor with this product - Create a RFQ for the vendor and add the agreement - Observe that the tax is not applied opw-5121243 Forward-Port-Of: odoo/odoo#243169 Forward-Port-Of: odoo/odoo#237114
This update streamlines the process of assigning barcodes to product packaging. Previously, users faced a confusing, multi-step process leading to duplicate UoM creation. Now, the barcode field is integrated directly into the packaging creation flow, offering a simpler and more efficient experience.
Original PR description
Before this commit: ------------------------- - In the product form view, when creating new packaging, a pop-up form opens to Create a new Unit of Measure (UoM), and if the user tries to assign a…
Before this commit: ------------------------- - In the product form view, when creating new packaging, a pop-up form opens to Create a new Unit of Measure (UoM), and if the user tries to assign a barcode Within that form, a second pop-up opens instead of assigning the barcode directly. - In the second pop-up, if the user creates the same UoM again, it causes data duplication; the same UoM gets created in 'Units and Packagings' with a default quantity of 1 without reference unit. This incorrect behavior leads to confusion when selecting the UoM later. Steps to reproduce: ------------------------- 1. Install the 'sale_stock' module. 2. Enable Units of Measure & Packagings in stock. 3. Create or open any product. 4. Go to the Sales tab. 5. Create new packaging (e.g., Pack of 5), set the quantity and reference unit, and try to create a barcode. 6. A second pop-up form opens to again create a new UoM and assign the barcode. 7. It causes data duplication; the same UoM gets created in 'Units and Packagings' with a default quantity of 1 without reference unit. Cause of the issue ------------------------- When assigning a new barcode to a UoM, the field could not fetch the corresponding UoM(In uom.uom) record because it did not yet exist in the database. As a result, the system opened another pop-up to create the same UoM(In product.uom) again and assign a barcode to it. After this commit: ----------------------- - The barcode field is hidden until the UoM is created. - Once the packaging is saved, users can edit it to assign a barcode to the specific UoM of the product. - This improves the flow by preventing duplicate UoM creation and ensuring a clear, single-step process for assigning barcodes to product packaging. Task ID:5023229 Forward-Port-Of: odoo/odoo#230474
This update prevents the full composer window from unexpectedly opening when users are editing messages within tasks. The original issue stemmed from a technical error related to how the composer was initialized during editing, causing a crash. This fix ensures a smoother editing experience for all users.
Original PR description
Steps to reproduce: =================== 1- Go to a project task & log any note. 2- Edit & Click the additional "+" and click "Open Full Composer" 3- Click on Save. -> traceback. Cause: ====== When entering edit mode, the composer was created without a thread reference, causing "Cannot read properties of undefined (`this.props.composer.thread is undefined`)" errors in `onClickFullComposer`. Solution: ========= We shouldn't have "open-full-composer" action in editing messages opw-5443985 Forward-Port-Of: odoo/odoo#242002
This update corrects a problem with Odoo invoices generated for Danish customers, specifically related to the ‘EndpointID’ scheme. The previous version used an outdated codelist, causing validation errors. This fix ensures invoices comply with the required OIOUBL standards, allowing for proper processing of invoices with the Nemhandel system.
Original PR description
**PROBLEM** Generated OIOUBL files don't pass schematrons validations. **STEP TO REPRODUCE** 1. Install the l10n_dk module. 2. Create a dk partner with an adress, and VAT number (DK12345674 for example, don't forget to add a street number for the DK Company address). 3. Create an invoice for the DK partner, and download the xml. 4. Use this validator https://oioubl.nemhandel.dk/validation (Odoo Peppol IAP validator tests oioubl version 3.0 which is not the version we want to test). **CAUSE** We used [wrong codelist](https://oioubl-demo.nemhandel.dk/oioubl/kodelister/ElectronicAddressSchemeCode-3.0.html) (oiubl3.0) for schemeID instead of the [one we should use](https://oioubl21.oioubl.dk/Codelists/en/urn_oioubl_scheme_endpointid-1.1.html) (oioubl2.1). opw-5379474 Forward-Port-Of: odoo/odoo#243342 Forward-Port-Of: odoo/odoo#240586
This update fixes an issue where the system incorrectly predicted downpayment accounts when a specific setting wasn't defined. The change reverted to using historical database data for predictions, ensuring accurate downpayment account assignments within the sales process. This improves the reliability of invoice generation.
Original PR description
In this pr (https://github.com/odoo/odoo/pull/206494), we changed the way downpayment accounts are set. Before, it was set on product categories, now, it's set on res.settings. But with this change, and unexpected behavior occurs. In case the downpayment account is not set in the setting, we try to predict the account to put, but the prediction is wrong, it's predicting based on the partner, but it should be based on the db history. This commit fix that, and brings back the old prediction. task-5473406 Forward-Port-Of: odoo/odoo#243357 Forward-Port-Of: odoo/odoo#242772
This update resolves an issue where the 'copy link' button in the salary calculator was generating a 404 error. The fix ensures the offer is saved before creating the link, preventing errors related to missing offer IDs. This improves the usability of the salary calculator for generating offer links.
Original PR description
Steps to reproduce: 1- Open salary calculator 2- Do not edit any fields 3- Click on copy link button 4- Open the link Issue: When you open the link you'll see a 404 page. Cause: The salary calculator essentially creates an offer. When no fields are modified in the form, the offer isn't created yet. When a link is created for that offer, the offer id part of the link is NewId_xxx. Fix: Modify the widget that copies the link to clipboard to first save the offer before generating the link. Task-5441297 Forward-Port-Of: odoo/enterprise#104021 Forward-Port-Of: odoo/enterprise#102900
This update fixes a problem where customers on one website could access payment providers enabled only for a different website. The fix ensures that payment providers are correctly filtered based on the customer's website, preventing incorrect payment options from appearing in the sales portal. This improves the customer experience and ensures accurate payment processing.
Original PR description
[FIX] website_sale, adding website_id in portal controller Version: 17.0+e Steps to reproduce ------------------ The database has two different websites. A payment provider is enabled for just one of…
[FIX] website_sale, adding website_id in portal controller Version: 17.0+e Steps to reproduce ------------------ The database has two different websites. A payment provider is enabled for just one of them (website1). When a sale order is created on the sales app and the customer accesses it in its portal on the website2, he is able to pay with the payment provider which is only enabled on website1. The problem also occurs when previewing the customer’s portal view. Why it's happening ------------------ When accessing an order via “/my/orders/<int:order\_id>”, the portal_order_page method calls _get_compatible_providers without passing the website_id. The overriding logic in website_payment then defaults to considering all activated payment methods as compatible, regardless of website restrictions. As no website_id is provided, the overriding method from the payment_provider extension in website_payment module considers every activated payment methods as compatible. The Fix ------- We now add the current website's id to the method if none has been added before. opw-5172444, “Payment provider visible on sales order portal" --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243341 Forward-Port-Of: odoo/odoo#235954
This update resolves an issue where applications weren't accurately counted and matched within a multi-company Odoo setup. The change removes a filtering constraint from the application matching process, ensuring a more precise count of applications per company. This improves the accuracy of reporting and data analysis across multiple businesses.
Original PR description
This commit fixes the issue where applications are not matched are not mathced with thier count among companies in a multi-company environment. The domain on company was removed from `_get_similar_applicants_domain` since there is no domain on company in `_compute_application_count`. task-5375876 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243154 Forward-Port-Of: odoo/odoo#238386
This update fixes an issue where public channels were incorrectly configured, defaulting to an internal user instead of being publicly accessible. Setting `group_public_id` to `None` ensures channels are properly designated as public, resolving a previous bug. This improves channel visibility and functionality.
Original PR description
Since #206619, the fixed test has used a wrong value for `group_public_id`, as if it's not set, the default is `Internal User`. This change sets it to `None` to make the channel public. Forward-Port-Of: odoo/odoo#243354 Forward-Port-Of: odoo/odoo#243237
This update resolves issues related to leave scheduling changes, specifically preventing leave refusals and handling multi-day leaves more effectively. Now, changes to working schedules before a leave's end split the leave into two records, ensuring accurate duration calculations and excluding cancelled leaves from the process.
Original PR description
Before this commit: - Changing the working schedule the day before a non-refused leave caused the leave to be refused. - For multi-day leaves, changing the working schedule before the end, split the…
Before this commit: - Changing the working schedule the day before a non-refused leave caused the leave to be refused. - For multi-day leaves, changing the working schedule before the end, split the leave into two records, both kept in the same state. - Changing the working schedule while a cancelled leave existed raised an error. After this commit: - Changing the working schedule the day before a leave now resets the leave to draft and recomputes its duration. - For multi-day leaves, changing the working schedule before the end splits the leave into two leaves: - the first keeps its original state, - the second is set to draft. - Cancelled leaves are excluded from the working schedule change flow. task-5420417 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#243451 Forward-Port-Of: odoo/odoo#240408
A recent update added call duration information to chatter messages, but this caused a tour to fail intermittently. This fix corrects the tour's targeting method to ensure consistent functionality, preventing future disruptions to the tour process.
Original PR description
After 5751f93c53d3cf37ae8cb627fb8d10a81b7b8833, call duration will be added to chatter message. This change is done by modifing the original message, which results in a non-deterministic failure when selector trying to match the original message. Change the selector to match a stable attribute. Forward-Port-Of: odoo/enterprise#104132
This update fixes a previous issue where the messaging menu incorrectly added needaction channel counts to the inbox count. Now, the inbox counter accurately reflects the number of unread messages across all channels, providing a more reliable view of communication activity. This ensures users have a precise understanding of their messaging workload.
Original PR description
This commit corrects a regression intoduced in [1]: the messaging menu now subtracts the channels needaction counter from the inbox counter, rather than adding it [1] https://github.com/odoo/odoo/pull/229751 Forward-Port-Of: odoo/odoo#243478 Forward-Port-Of: odoo/odoo#243318
This update fixes a bug where payslips were showing blank worked days for employees on fully flexible contracts. The change ensures accurate calculation of worked days, even when contracts don't have a standard calendar assigned, addressing a previous issue with attendance-based work entries. This improves payroll accuracy and reporting.
Original PR description
**Issue:** Payslips show blank worked days for employees with contracts without a `resource_calendar_id` (fully flexible, despite having valid work entries **Cause:** `_get_worked_day_lines()` skips…
**Issue:** Payslips show blank worked days for employees with contracts without a `resource_calendar_id` (fully flexible, despite having valid work entries **Cause:** `_get_worked_day_lines()` skips worked day computation if the contract has no calendar https://github.com/odoo/enterprise/blob/1a10e0444fdb71a072262a1f14f0bfc766d109c6/hr_payroll/models/hr_payslip.py#L665-L674 **Steps to Reproduce:** - Assign an employee a fully flexible contract with attendance as work entry source. - Create work entries based on the attendance records of the employee record - Go to employees > contracts > new Payslip Worked Days section is empty, even though attendance shifts are showing up on top. **Fix:** removing the calendar requirement in the main method and adding a fallback calendar in the called utility method **Note:** same issue happens if work entry source of the contract is Planning opw-4931972 Forward-Port-Of: odoo/enterprise#102668 Forward-Port-Of: odoo/enterprise#93935
This update corrects a discrepancy in how tax information is reported for Brazilian invoices impacted by a recent fiscal reform. Previously, tax details were optional, but now they are always required for XML reporting, ensuring compliance. This change impacts the accuracy of tax data for Brazilian businesses using Odoo Enterprise.
Original PR description
Before the fiscal reform, we deliberately avoid sending back informative taxes for service invoices because they may change depending on how and when the invoice is paid and they only need to appear on the XML optionally. New informative taxes specific to the fiscal reform are required to appear on the XML and therefore we must always send them. task-5450142 Forward-Port-Of: odoo/enterprise#103762 Forward-Port-Of: odoo/enterprise#103599
This update resolves an issue where non-admin users in multi-company environments couldn't update their profile picture or preferred language. The fix bypasses access rules that were incorrectly blocking company data access, allowing users to manage these settings without errors. This ensures a smoother experience for all users regardless of their company setup.
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. Now, when a new order is created, the system automatically uses the company setting from the POS session's configuration, 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 an issue where Manufacturing Orders weren't being created correctly when using the Barcode app. Specifically, disabling tracking caused a technical error that prevented components from being added to the order. The fix ensures the correct flow is followed, resolving this problem and improving the reliability of the manufacturing process.
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 resolves an issue where saving electronic invoicing settings on branch companies with identical VAT and Codice Fiscale to their parent company would fail. The fix ensures the correct company (parent) is used when searching for proxy users, preventing errors and improving the reliability of the IT EDI process. This ensures accurate electronic invoicing setup.
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 ensures that Odoo's code translations are correctly exported. A new package, odoo.orm, was recently added, and this change clarifies how the framework identifies and exports translations from this package. This improves the accuracy and completeness of our code translation resources.
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 encounter errors when pinning or unpinning embedded actions, particularly within superuser mode. By adding a check for superuser status, the system now correctly allows superusers to perform these actions, ensuring stability for automated processes and installation scripts.
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 fixes a bug where changes made within the website builder preview were not being saved correctly. The preview was automatically reverted upon user input, leading to lost edits. This ensures that edits made while previewing are preserved, improving the user experience when customizing website elements.
Original PR description
Forward-Port-Of: odoo/odoo#243039
8 changes
New functionality added to Odoo
This update adds support for payment channels in Thailand (TH), Malaysia (MY), and Vietnam (VN) through Xendit. This expansion allows Odoo users to accept payments from customers in these key Southeast Asian markets, improving our payment processing capabilities and customer reach.
Original PR description
Xendit has expanded to TH, MY and VN supporting the local payment channels. This commit is to add the supported pamyent channels according to what they have added. task-4334511 Forward-Port-Of: odoo/odoo#189527
Enhancements to existing features
This update adds key reference fields – Buyer Reference, Contract Reference, and Purchase Order Reference – to the invoice PDF generated by the l10n_fr_facturx_chorus_pro module. These fields are required for Chorus Pro compliance, ensuring invoices meet the necessary documentation standards.
Original PR description
This commit: - Add three reference fields to invoice PDF for Chorus Pro compliance: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header when set on the invoice. task-5410836 Forward-Port-Of: odoo/odoo#240494
Resolved issues and error corrections
This update resolves an issue where automated time tracking activities were delayed when exceeding allocated time limits. The fix ensures that dependent fields are correctly recomputed after pre-filter conditions are applied, preventing inconsistencies and delays in activity creation. This improves the reliability of time tracking workflows.
Original PR description
This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323 When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled…
This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323
When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled afterwards For example, if a rule pre-filters on field B (which depends on A), computing A should not clear the compute flag of B
### Issue:
In some automation rules, computed fields must be processed in a specific order (e.g., `effective_hours` -> `remaining_hours`)
However, if `remaining_hours` is referenced in the automation `Before Update Domain`, its compute flag may be incorrectly cleared, preventing the proper recomputation chain
This results in inconsistent behavior, such as delays in activities being created when timesheets exceed allocated time
### Cause:
The automation engine flushes fields referenced in the `Before Update Domain`, but does not restore their compute flags afterward Thus dependent fields are not recomputed as expected
### Steps to reproduce:
1. Enable Debug Mode
2. Create an Automation Rule
-- Name: Time Exceeded
-- Model: Task
-- Trigger: On Save
-- Before Update Domain: [("remaining_hours", ">=", 0)]
-- Apply on: [("remaining_hours", "<", 0)]
4. Create a Project with Timesheets
5. Create a Task inside the Project
6. Set Allocated Time to 10h
7. Use the Start button to record 11h (No activity appears in chatter)
8. Do the same again (Activity appears only after the second exceed) Before the fix, there is always a delay because the recomputation chain is broken
### Tickets:
18.0: opw-4409744
17.0: opw-5237430
Forward-Port-Of: odoo/odoo#243059
Forward-Port-Of: odoo/odoo#239667This update resolves an issue where saving company settings with duplicate VAT and Codice Fiscale (parent and branch) caused errors during proxy user setup. The fix ensures the correct company is identified during user searches, preventing conflicts and improving the stability of the Electronic Invoicing process. This ensures accurate EDI processing for multiple company setups.
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 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 software.
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 fixes an issue where a distracting helper element remained visible in the bank reconciliation journal when there were no entries. By hiding this element when there's no data, the view is now cleaner and more user-friendly, particularly on mobile devices. This improves the overall user experience.
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 addresses a bug where user edits within the website builder preview were lost. The system now immediately reverts the preview when text is entered or shortcuts are used, preventing conflicting state changes. This ensures a more reliable editing experience for users.
Original PR description
Forward-Port-Of: odoo/odoo#243039
This update fixes a critical issue where payroll sheets were incorrectly computed even when errors existed on payslips. Now, errors are properly flagged with a detailed message, ensuring payroll calculations are accurate and users are immediately alerted to resolve any problems. This prevents incorrect payments and improves payroll reliability.
Original PR description
Bug: When there is an issue on a payslip with an error level, and we try to compute the sheet, the sheet is computed. Instead of computing, it should raise and the message should specify what errors need to be resolved first. Cause: When computing the sheet, we were calling the self._get_error_message() without using the result, which is a string. Fix: Actually raise a ValidationError and use the result of self._get_error_message() for the error message. Introducing the raise brought other problems because some code supposed to fail was running seamlessly fine. But now, the raise is called and those needed to be solved as well. The issue raised multiple times is the "No contract in the payslip period". Task: 5153497
9 changes
Enhancements to existing features
This update adds three new fields to Odoo invoice PDFs – Buyer Reference, Contract Reference, and Purchase Order Reference – to ensure compliance with Chorus Pro requirements. These fields allow users to accurately document key purchase information directly on the invoice, streamlining the Chorus Pro process. This change improves data accuracy and reporting.
Original PR description
This commit: - Add three reference fields to invoice PDF for Chorus Pro compliance: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header when set on the invoice. task-5410836 Forward-Port-Of: odoo/odoo#240494
Resolved issues and error corrections
This update resolves a technical issue in the Odoo recruitment demo data. The system was incorrectly using user records instead of partner records, which caused errors. This fix ensures the demo data accurately reflects the expected data structure, improving the demo experience.
Original PR description
author_id expects a res.partner record. In this commit: Replace the user record with the corresponding partner record to avoid passing an incorrect recordset in demo data.
This update resolves an issue where users could incorrectly modify attendance records. The change now prevents unauthorized updates to attendance data, ensuring data integrity and accuracy. Test coverage has been added to guarantee this fix.
Original PR description
Closes [odoo/odoo#226007](https://github.com/odoo/odoo/issues/226007). Description of the issue/feature this PR addresses: Prevents a user from updating their attendance record by changing the employee to the one whose attendance is not managed by the current user. Current behavior before PR: - Assign the Officer Group of Attendance group to a user. - Assign the user as the attendance manager of itself. - Login with that user. - Create an attendance record for the employee and save it. - Try to change the employee and save; an error will be thrown as expected. - Go to the Attendance menu; the record will still be saved. Desired behavior after PR is merged: This commit ensures that un-allowed write does not take place + test coverage added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226335
This update resolves an issue where scheduled notifications and other mail-related processes would fail when records were deleted. The fix ensures that notifications are skipped when a record is deleted, preventing errors and improving the user experience by avoiding misleading notifications.
Original PR description
RATIONALE When a cascade delete occurs in DB, ORM methods are not called. More specifically loosely connected records using res_model / res_id pair are not removed when unlink override exists. SPECIFICATIONS Fix various use case in mail * notifications sent for scheduled messages; * failure notifications management; * activities mark as done; Task-5138556 Forward-Port-Of: odoo/odoo#238623 Forward-Port-Of: odoo/odoo#233071
This update addresses a potential issue where deleted records could still be accessed within Odoo, particularly after cascade deletions. The changes add checks to ensure related records don't exist before accessing data, preventing errors and improving system stability. This ensures notifications and activities are handled correctly even when records are removed.
Original PR description
In order to be defensive we have to check records linked to messages, notifications or activities exist before checking related information like display_name, or even to skip them in various flows. This happens notably due to DB-level cascade deletion that does not remove side records linked through (model, res_id) pairs. It implies some additional exist queries. Task-5138556 Forward-Port-Of: odoo/enterprise#101300 Forward-Port-Of: odoo/enterprise#101185
This update resolves an issue where URLs were appearing twice in WhatsApp messages due to a formatting error in how the Odoo UI's markup was converted. The fix prevents the duplication of URLs, ensuring messages are clear and consistent for users. This improves the user experience when sharing links via WhatsApp.
Original PR description
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises within the `_send_message` method, where we are taking the Markup body that we use within the Odoo UI to have a clickable URL, like `<a href="https://example.com">https://example.com</a>`. Then, the html2plaintext function duplicates by adding the footnote for the anchor tag, which "duplicates" the URL since the text within the anchor tag is the same as the URL itself. This results in a message body that contains the URL twice, leading to confusion for the user. Solution: This commit addresses the issue by backporting the solution to this problem introduced in odoo/odoo@a152910 and using the `include_references` parameter of the `html2plaintext` function to exclude footnotes from the conversion. opw-4936400
This update resolves an issue where incorrect credentials caused misleading error messages when sending invoices. The fix ensures a clearer and more accurate error display, preventing confusion and streamlining the invoice processing workflow. This improves the reliability of the HR EDI module.
Original PR description
Fixing incorrect error display that occurred while trying to send an invoice to MER with incorrect credentials set up. (no task/error ID) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug in our expense reporting feature that caused incorrect journal entries and access errors. The fix ensures the report correctly uses the relevant expense line information (AML ID and company) for accurate navigation and data display.
Original PR description
Steps to reproduce: 1. Edit the first account.move in expenses account by adding Analytic Distribution to first aml. 2. Open General Ledger & group by Analytic Plan. 3. Click "View journal Entry" for the Bill line. Before this commit: When grouping financial reports by Analytic Plans, the temporary table generation logic incorrectly prioritized `account_analytic_line` over `account_move_line` ids and companies. This caused the report to use Analytic IDs as row identifiers, leading to "Identity Theft" where clicking a row opened an unrelated Journal Item (sharing the same integer ID) or raised Access Errors due to company mismatches. After this commit: The report table now uses the aml id as intended and redirects to the expected journal entry. opw-5413138 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#103930
This update resolves an issue where Odoo encountered errors when processing emails with attachment content types incorrectly identified as '*/*'. To ensure emails are processed smoothly, the system now defaults to treating these attachments as 'application/octet-stream'. This prevents processing failures and maintains email functionality.
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
3 changes
Resolved issues and error corrections
This update addresses a rare technical issue where a variable within the Odoo mail system was sometimes undefined, leading to potential instability. This fix ensures the mail functionality operates reliably in all circumstances, improving overall system stability. The change is a minor correction to prevent unexpected errors.
Original PR description
In rare cases a variable is not defined.
This update resolves an issue where the save and cancel buttons in the report editor's WYSIWYG interface were difficult to see due to insufficient contrast. The change improves the visibility of these buttons, ensuring a better user experience for creating and editing reports. This addresses a minor usability concern.
Original PR description
Before this PR, the save and cancel button could not be seen properly, now the contrast has been improved. | Before | After | |--------|--------| | <img width="1056" height="97" alt="Screenshot 2026-01-08 at 11 00 30" src="https://github.com/user-attachments/assets/9b03a220-5537-4f6c-a7e2-a6fa3a4da75a" /> | <img width="1056" height="97" alt="Screenshot 2026-01-08 at 11 00 20" src="https://github.com/user-attachments/assets/cb4a868d-e2ab-429d-8588-a92c4e1e170e" /> | task-5401415
This update addresses a potential issue where long email display names could cause emails to be incorrectly formatted, leading to problems with email delivery and folding. The fix ensures that display names are properly quoted in email headers, maintaining RFC compliance and preventing misinterpretation of the email message. This ensures reliable email communication for our users.
Original PR description
In certain edge-case, when having long display names in an email address, the standard mail library in Python used to have a bug were it would remove the quotes in the display name of the email…
In certain edge-case, when having long display names in an email address, the standard mail library in Python used to have a bug were it would remove the quotes in the display name of the email address and lead to miss-folded header values in the final email after serialization of the message object for SMTP sending. See cpython#80222. While a fix was deployed in recent Python versions and backported, given it's non-critical nature, it is not backported my default in Debian/Ubuntu distribution for Python versions <3.13. This means that as long as the minimal supported version for Odoo is below 3.13, we will need to pre-emptively prevent this issues with an Odoo side fix. ## Bug description: 1) Create a contact with a very long display name: `A Name That Is Extremely Long And Will Force The Header Folding Mechanism To Break The Quotes, Which Is The Bug We Are Testing` 2) Send an email message to this contact (capture with a mailcatcher) 3) Analyse the "TO" header an notice that it's miss-folded and RFC non compliant ``` To: A Name That Is Extremely Long And Will Force The Header Folding Mechanism To Break The Quotes, Which Is The Bug We Are Testing <test@example.com> ``` Notice that the quotes were wrongly removed, now the single email is interpreted as multiple ones due to the non-quoted commas. ## After this fix: ``` To: "A Name That Is Extremely Long And Will Force The Header Folding Mec..." <test@example.com> ``` OPW-4988762 BPO-36041 BPO-44637