Daily updates from Odoo
Navigate
Branch
Tuesday, June 9, 2026
236 changes
9 changes
Resolved issues and error corrections
This update fixes a reporting issue by now logging a specific message when a new partner is created through Google or Microsoft Calendar synchronization. Previously, all new partners received a generic message. This change provides clearer tracking of partners originating from calendar integrations, aiding in troubleshooting and reporting.
Original PR description
Before we were logging the new created partners default message. Now we log custom message indicating that this partner was created from Calendar sync. task-6177363 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#264392
This update resolves an issue where partner names with '&' characters were being incorrectly formatted for SEPA bank exports, leading to rejection by banks. The fix ensures '&' is preserved in name and address fields, aligning with industry standards and preventing export failures.
Original PR description
Problem: The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name)…
Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.
As a result, a partner named "test & test GMBH" was exported as:
<Nm>test + test GMBH</Nm>
instead of the expected:
<Nm>test & test GMBH</Nm>
This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.
Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:
- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.
- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.
Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.
ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:
Forward-Port-Of: odoo/enterprise#118897
Forward-Port-Of: odoo/enterprise#115409This update fixes a technical glitch that caused unexpected pop-ups and errors when using preset orders with time management in the restaurant POS. The issue stemmed from how the system handled merging orders, leading to outdated processes. This change ensures a smoother and more reliable experience when selecting and using preset orders.
Original PR description
pos*: point_of_sale, pos_restaurant Steps to reproduce: - Configure a preset identified by name and managed by time. - Open the restaurant POS. - Create a direct order and set a tab for it. - Return to the floor screen and create another direct order. - Select the configured preset and choose the previously created order from the order name popup. Issue: - The time slot selection popup appears unexpectedly. - Selecting a time slot triggers a traceback. Cause: - When selecting an existing order, the current order is merged into the selected order. - However, the time slot selection flow remains active for the merged order, which has already been deleted. Fix: - Exit the preset selection flow when the order is merged and deleted. Task-6032880 Forward-Port-Of: odoo/odoo#268709 Forward-Port-Of: odoo/odoo#253586
This update fixes an issue where sale order prices weren't accurately displayed in invoicing. The system was previously using product prices instead of the specific price set on the sale order line. This change ensures that users always see the correct price from the sale order, improving invoicing accuracy and reporting.
Original PR description
Steps to reproduce: - - Create a Sale Order with two sale order lines for the same product. - Set different prices on each SOL (e.g. 20 and 40). - Open the related project and go to the Invoicing tab. - Search for the Sale Order Lines. Issue: - Displayed price uses the product price instead of the SOL price. Cause: - The display name formatting used `product_id.lst_price`. Solution: - Use `price_unit` from the sale order line to show the correct price. task-5966799 Forward-Port-Of: odoo/odoo#250554
This update ensures that Cashdro payments are correctly cancelled when a payment is manually forced in the POS system. Previously, forced payments would remain in a waiting state, preventing proper cancellation. This change improves payment accuracy and prevents potential issues with Cashdro machines.
Original PR description
Since the Cashdro machine has no way for the user to cancel the payment through its interface, if a payment was forced the machine would remain waiting for a payment that could no longer be cancelled from the POS. To fix this, we now send a cancel request whenever a payment is forced. task-6276665 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268496
This update resolves an issue where invoices from certain Peppol suppliers (using a specific XML format) weren't being correctly imported. The fix automatically identifies the supplier's VAT information, creating the necessary partner records and linking bank accounts, ensuring invoices are processed accurately. This prevents import failures and data inconsistencies.
Original PR description
Some Peppol emitters carry the supplier VAT in cac:PartyIdentification/cbc:ID instead of the BIS3-standard cac:PartyTaxScheme/cbc:CompanyID. The import then extracted no VAT, the partner auto-creation not available (needs name+vat) and invoice.partner_id stayed empty. As a side effect, when the XML also carried a PayeeFinancialAccount, the bank account creation crashed with a NOT NULL violation on partner_id. Fall back on cac:PartyIdentification/cbc:ID when cbc:CompanyID is empty, so the partner is found (or auto-created) and the bank account is properly linked. Steps to reproduce: - Create a XML with the supplier VAT only in cac:PartyIdentification/cbc:ID and a cac:PayeeFinancialAccount/cbc:ID. - Upload on a purchase journal: import fails, the bill stays empty with an error in chatter. - With the fix: partner auto-created, bill filled, bank linked. opw-6148974 Forward-Port-Of: odoo/odoo#268316 Forward-Port-Of: odoo/odoo#261933
This update corrects a bug in the HR module's version calculation logic. Specifically, it fixed an error that could incorrectly identify overlapping contract periods, leading to inaccurate reporting. This ensures more reliable tracking of employee contracts and related data.
Original PR description
Forward-Port-Of: odoo/odoo#268807
This update prevents managers from overriding the assigned card for expense approvals. Previously, setting a manager on a card expense would be cleared upon approval, causing confusion and potential errors. Now, card expenses are read-only for managers, streamlining the expense approval process.
Original PR description
**Issue** If a manager was manually set on a card expense after it was created, it would be cleared when the expense was approved. **Change** Make the field readonly for card expenses, the idea is that the manager shouldn't need to approve card expenses since they are able to control them via the card itself. opw-6045587 Forward-Port-Of: odoo/enterprise#112593
This update fixes a persistent memory leak within the Odoo test suite. The issue stemmed from an unintended reference to internal Odoo environment variables, causing tests to consume excessive memory. The solution ensures proper cleanup of these references after each test run, improving test stability and performance.
Original PR description
Since [1], there was a memory leak in the test suite due to the path of `rpc._rpc`. This override was leaking the env and all services in every module sets created by hoot. In stable, we simply hook on the `after` callback to cleanup the patch, thus removing the reference to the env and services. In master, with owl3, the strategy will be to put the patch in a Plugin, which has a cleanup function that is executed automatically when the App is destroyed, i.e. after each test. [1] odoo/odoo#248852 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#268883
22 changes
Enhancements to existing features
This update clarifies the handling of Forward VAT (FWVAT) reverse charges in the Philippines for DS and EM transactions. Previously, these groups used a single reverse-charge tax without Automatic Tax Collection (ATC). Now, separate taxes with ATC are implemented for DS and EM, ensuring accurate VAT reporting and compliance.
Original PR description
The 12% FWVAT DS and EM groups shared a single reverse-charge tax with no ATC. Split it into two dedicated taxes so each carries its own ATC: 12% FWVAT RC DS (WV080) and 12% FWVAT RC EM (WV100). task-6278099 Forward-Port-Of: odoo/odoo#268502
Resolved issues and error corrections
This update resolves an issue where the Profitability report's Cost of Goods Sold dashboard didn't display data when multiple invoices were associated with a project. The fix ensures the report accurately reflects all related journal entries, regardless of the number of invoices generated.
Original PR description
Steps to reproduce: ------------------- 1. Install `sale_project_stock` and Accounting. 2. Create a storable product with **Real-time valuation** and configure the COGS account in the product…
Steps to reproduce: ------------------- 1. Install `sale_project_stock` and Accounting. 2. Create a storable product with **Real-time valuation** and configure the COGS account in the product category expense account. (Ensure you have enabled automatic & analytic accounting from accounting>config.) 3. Create a project with a specific analytic account and ensure the project is billable. 4. Create a sale order with the created product and set the same analytic account in the analytic distribution. 5. Confirm the order, deliver the product, generate the invoice, and post it. 6. Open the project and go to the *Profitability* report. 7. Click on the **Cost of Goods Sold** dashboard item. 8. Repeat steps 4–7 with multiple invoices. Issue: ------ When there is only one invoice, clicking the COGS dashboard item correctly displays the related move lines. However, when there are multiple invoices, the action opens with empty results. Cause: ------ `_get_action_for_profitability_section` sets `res_id` only when a single record exists. When multiple records are present, `res_id` becomes `False`, which causes the action to open without results. https://github.com/odoo/odoo/blob/8f79d407724f40ba8e48f1747b2e87311b7fb49e/addons/project_account/models/project_project.py#L78-L83 Solution: --------- When `res_id` is not set, search `account.move` records using the domain to retrieve the relevant move IDs, then apply a proper domain to display all related COGS journal items. opw-5949261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267097 Forward-Port-Of: odoo/odoo#253639
This update fixes an issue where sale order prices weren't accurately displayed in invoicing. The system was previously using product prices instead of the specific price set for each sale order line. This change ensures that users always see the correct price when viewing sale order details, improving invoicing accuracy and reporting.
Original PR description
Steps to reproduce: - - Create a Sale Order with two sale order lines for the same product. - Set different prices on each SOL (e.g. 20 and 40). - Open the related project and go to the Invoicing tab. - Search for the Sale Order Lines. Issue: - Displayed price uses the product price instead of the SOL price. Cause: - The display name formatting used `product_id.lst_price`. Solution: - Use `price_unit` from the sale order line to show the correct price. task-5966799 Forward-Port-Of: odoo/odoo#250554
This update resolves a bug that prevented users from generating planning reports when grouping by departments instead of resources. The fix ensures that the system correctly identifies a resource when grouping by other methods, preventing an error and allowing reports to be printed successfully.
Original PR description
## Steps to Reproduce: 1. Install the Planning module. 2. Planning > Group by "Department". 4. Click Actions > Print. ## Error: `AttributeError - 'bool' object has no attribute 'id'` ## Cause: When the planning is grouped by other than `resource_ids`, `resource` is set to False. Later, then accessing the ID leads to an error. ## Fix: When the planning is not grouped by resource, use the first resource assigned to the slot instead of False. sentry-7536432202
This update optimizes Odoo's styling process, specifically reducing the time it takes to recalculate styles in large tables like the Accounting Balances Sheets. By removing unnecessary selectors, the system now responds faster to window resizing, scrolling, and sorting, leading to a smoother user experience.
Original PR description
Adapt selector to remove the :has value since it not needed to have the effect applied. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. This commit is a follow up of https://github.com/odoo-dev/enterprise/commit/8aa63b3c726d825e68430bb0a64a54c1b58d6af7 Note: We also fixes the scss button variable not correctly overided Forward-Port-Of: odoo/enterprise#119521
This update fixes an issue where invoices from certain Peppol suppliers (using a specific XML format) weren't being correctly imported. The fix automatically identifies the supplier's VAT information, creating the necessary partner records and linking bank accounts, ensuring invoices are processed accurately. This prevents import failures and data inconsistencies.
Original PR description
Some Peppol emitters carry the supplier VAT in cac:PartyIdentification/cbc:ID instead of the BIS3-standard cac:PartyTaxScheme/cbc:CompanyID. The import then extracted no VAT, the partner auto-creation not available (needs name+vat) and invoice.partner_id stayed empty. As a side effect, when the XML also carried a PayeeFinancialAccount, the bank account creation crashed with a NOT NULL violation on partner_id. Fall back on cac:PartyIdentification/cbc:ID when cbc:CompanyID is empty, so the partner is found (or auto-created) and the bank account is properly linked. Steps to reproduce: - Create a XML with the supplier VAT only in cac:PartyIdentification/cbc:ID and a cac:PayeeFinancialAccount/cbc:ID. - Upload on a purchase journal: import fails, the bill stays empty with an error in chatter. - With the fix: partner auto-created, bill filled, bank linked. opw-6148974 Forward-Port-Of: odoo/odoo#268316 Forward-Port-Of: odoo/odoo#261933
This update addresses a slow file preview issue when handling large files. Previously, users experienced a blank screen while a large file downloaded and rendered, leading to a frustrating experience. Now, a loading indicator provides feedback while the preview is being prepared, significantly improving user satisfaction.
Original PR description
When previewing a big file, the download might take long and the rendering might take even more time. The UI is blocked until the iframe is ready, but there is no feedback for the user. This commit adds some loading feedback until the iframe is rendered. Steps to reproduce: - Go to a Knowledge article - Upload a file with `/file` - Add a huge JSON file (~30MB) - Save - Click on the file icon => The preview opened but took ages to be displayed without giving any feedback to the user task-6014223 Forward-Port-Of: odoo/odoo#264136
This update prevents managers from overriding the card details when approving card expenses. Previously, setting a manager on a card expense would be cleared upon approval, causing confusion. Now, card expenses are read-only for managers, streamlining the expense approval process and ensuring accurate control via the card itself.
Original PR description
**Issue** If a manager was manually set on a card expense after it was created, it would be cleared when the expense was approved. **Change** Make the field readonly for card expenses, the idea is that the manager shouldn't need to approve card expenses since they are able to control them via the card itself. opw-6045587 Forward-Port-Of: odoo/enterprise#112593
This update ensures that work orders can only be assigned to employees specifically authorized for the relevant workcenter. Previously, all employees were selectable, regardless of workcenter permissions. This change improves efficiency and accuracy by limiting assignments to qualified personnel.
Original PR description
Add domain on `employee_assigned_ids` to restrict selectable employees based on the workcenter configuration. If `all_employees_allowed` is True, no filter is applied. Otherwise, only employees listed in `allowed_employees` are selectable. opw-6208602 Forward-Port-Of: odoo/enterprise#117876
This update corrects a bug that prevented signature requirement features from working correctly for shipments between US locations. The fix adjusts the API request to accurately reflect whether a delivery is at the shipment or package level, aligning with UPS API specifications. This ensures signature requirements are properly applied for US deliveries.
Original PR description
Issue ----- Enabling signature requirement blocks US -> US deliveries. Steps to reproduce ----- - Setup UPS - enable signature requirement - Set current company to US - Create a US Customer - Create…
Issue ----- Enabling signature requirement blocks US -> US deliveries. Steps to reproduce ----- - Setup UPS - enable signature requirement - Set current company to US - Create a US Customer - Create a product with some weight - Create a SO for the product - Add UPS delivery and try to get a rate > Error: "The requested accessory option is unavailable between the selected locations." Cause ----- Depending on the type of transfer, signature is requested at shipment or package level (see the "Delivery Confirmation Origin-Destination Pairs" category of the following link) https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US US50 -> US50 & Canada -> Canada is package level Everything else is shipment level By default we use 'ShipmentServiceOptions_DeliveryConfirmation' for which 'DCISType' = 1 is the correct value. https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L8902-L8911 For package level, we should use 'PackageServiceOptions_DeliveryConfirmation' for which 'DCISType' = 2 would be the expected value https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L10410-L10421 ----- Ticket: opw-6173624 Forward-Port-Of: odoo/enterprise#117564
This update resolves a minor issue where the displayed name for the Sendcloud website delivery module had a typo ("Sendcould"). The underlying functionality remains unchanged as all other references use the correct spelling. This ensures accurate module identification and a consistent user experience.
Original PR description
The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary.
opw-6239003
Forward-Port-Of: odoo/enterprise#118416
Forward-Port-Of: odoo/enterprise#118223This update fixes an issue where the field service report was displaying incorrect information. The report now accurately shows the Planning Shift name and start date, which were automatically populated when a shift is created. This change ensures the report provides the correct details for service interventions.
Original PR description
…port title - Removed the 't-if' condition containing 'doc.name', as 'doc.name' now refers to the Planning Shift name following the changes introduced in v19.2. - The report now displays 'start_datetime', which is automatically populated when a Planning Shift is created. - As a result, the 't-if' condition is no longer necessary. - This change aligns with the new behavior introduced in v19.2 and effectively replaces the Task name that was previously displayed before the report was migrated from 'project.task' to 'planning.slot'. Task-ID: 6284967
This update fixes a persistent memory leak within the Odoo test suite. The issue stemmed from an unintended override of the test environment, leading to unnecessary resource consumption. The solution ensures proper cleanup after tests, preventing future memory problems.
Original PR description
Since [1], there was a memory leak in the test suite due to the path of `rpc._rpc`. This override was leaking the env and all services in every module sets created by hoot. In stable, we simply hook on the `after` callback to cleanup the patch, thus removing the reference to the env and services. In master, with owl3, the strategy will be to put the patch in a Plugin, which has a cleanup function that is executed automatically when the App is destroyed, i.e. after each test. [1] odoo/odoo#248852 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
This update introduces support for Belgian voluntary overtime within Odoo's payroll system, DMFA reporting, and 281.10 tax reporting. It includes new work entry types and thresholds to accurately track and report overtime hours, ensuring compliance with Belgian regulations.
Original PR description
Add support for Belgian voluntary overtime in payroll, DMFA, and 281.10 reporting. * Introduce dedicated work entry types for: * Voluntary overtime exempt from ONSS/precompte (DMFA service code 81) * Voluntary overtime subject to ONSS/precompte at 150% and 200% rates (DMFA service code 1, remuneration code 1) * Add salary rules and categories for voluntary overtime remuneration. * Enforce yearly thresholds through payroll parameters: * 240h for voluntary overtime exempt from ONSS * 120h for voluntary overtime subject to ONSS * Exclude voluntary overtime from employment bonus calculations and paid amount computation where required. * Include voluntary overtime remuneration in payroll calculations and DMFA declarations. * Add dedicated 281.10 reporting support for voluntary overtime exempt from ONSS using the reserved tax form fields. * Fix DMFA service hour computation and add payroll/DMFA test coverage. TaskID: 6275791
This update introduces support for Belgian voluntary overtime within Odoo's payroll system. It allows businesses to accurately track and report overtime hours, including those exempt from social security contributions and those subject to standard rates. This ensures compliance with Belgian regulations and provides better management of employee compensation.
Original PR description
Add support for Belgian voluntary overtime in payroll, DMFA, and 281.10 reporting. * Introduce dedicated work entry types for: * Voluntary overtime exempt from ONSS/precompte (DMFA service code 81) * Voluntary overtime subject to ONSS/precompte at 150% and 200% rates (DMFA service code 1, remuneration code 1) * Add salary rules and categories for voluntary overtime remuneration. * Enforce yearly thresholds through payroll parameters: * 240h for voluntary overtime exempt from ONSS * 120h for voluntary overtime subject to ONSS * Exclude voluntary overtime from employment bonus calculations and paid amount computation where required. * Include voluntary overtime remuneration in payroll calculations and DMFA declarations. * Add dedicated 281.10 reporting support for voluntary overtime exempt from ONSS using the reserved tax form fields. * Fix DMFA service hour computation and add payroll/DMFA test coverage. TaskID: 6275791
This update fixes a reporting issue by now logging a specific message when new business partners are created through the Google or Microsoft Calendar sync. Previously, all new partners received a generic message. This change provides clearer tracking of partners originating from calendar integrations, aiding in data analysis and troubleshooting.
Original PR description
Before we were logging the new created partners default message. Now we log custom message indicating that this partner was created from Calendar sync. task-6177363 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#264392
The Odoo Builder was experiencing performance issues due to excessive resource requests when the shape selector panel loaded. This fix delays the panel's content rendering until it's needed, preventing the UI from freezing and improving responsiveness. This change ensures a smoother user experience for builders.
Original PR description
The shape selector panel was eagerly compiling and rendering its slot content on builder startup, triggering 200+ concurrent SVG thumbnail requests before the user had opened the panel or selected an image. With browsers limiting parallel connections per domain, this flooded the request queue and caused the main UI to freeze for several seconds. Slot content is now deferred behind a `contentRendered` flag that is set the first time the panel is opened, so no compilation or network activity happens until the user actually needs it. task-5973702 Forward-Port-Of: odoo/odoo#253041
This update fixes an issue where vendor bills imported from Poland's KSeF system were not correctly accounting for discounts applied to individual items. The update now properly parses the 'P_10' XML node, ensuring accurate bill data is imported and processed. This improves the reliability of financial reporting for businesses using the l10n_pl_edi module.
Original PR description
When fetching vendor bills from KSeF, the XML node "P_10" is used to indicate a discount per unit on a line. This node is currently being ignored when parsing the file. Official documentation: https://ksef.podatki.gov.pl/media/gn2kt4gl/broszura-informacyjna-struktury-logicznej-e-faktury-fa-1-wersja-anglojezyczna.pdf opw-6235460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268551 Forward-Port-Of: odoo/odoo#267235
This update resolves a problem in the account module's testing process. The tests were failing due to leftover account transactions that weren't being properly cleaned up. By canceling payments before removing these transactions, the tests now run correctly and provide accurate results.
Original PR description
The KPI provider test setup could leave some account moves behind when running with all modules and demo data installed. These leftover moves were then detected by subsequent test steps, causing incorrect numbers and test failures. This commit ensures the targeted moves are removed to provide an empty test environment. Payments need to be canceled first; otherwise unlinking the moves raises a ValidationError. [runbot-939456](https://runbot.odoo.com/odoo/error/939456) Forward-Port-Of: odoo/odoo#268151
This update allows Odoo to correctly validate Turkish VAT invoices issued to non-taxpayers or overseas customers, following Turkish regulations. Previously, invoices using standard placeholder VAT numbers were incorrectly rejected. This change ensures accurate VAT processing for Turkish businesses while maintaining existing validation rules.
Original PR description
- Turkish regulations allow the usage of special placeholder identifiers for invoices issued to non-taxpayer end consumers and overseas customers, where providing a real TCKN/VKN is not mandatory. - Although Odoo already referenced these identifiers in the VAT format help message (`11111111111` for TCKN and `2222222222` for VKN), they were still rejected by the Turkish VAT validation logic because they do not pass the standard `stdnum` checks. - This commit extends the Turkish VAT validation to explicitly allow these GİB-approved placeholder identifiers while preserving the existing standard VAT validation behavior and Nilvera test environment exceptions. taskID-6237629 Forward-Port-Of: odoo/odoo#268225
This update fixes a technical issue where the ‘Configuration’ menu item within the Contracts module was being incorrectly positioned due to a low sequence value. This caused conflicts with other modules and disrupted the standard Odoo menu hierarchy. Adjusting the sequence ensures the Contracts menu remains in its intended last position, maintaining a consistent and predictable user experience.
Original PR description
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other…
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other modules (e.g. [OCA](https://github.com/OCA/partner-contact/pull/2202/files)) add menu items in the same section. This affects not only external modules but also internal ones that add menu items under *Contacts*. ## Current behavior before PR When other modules add new menu items to *Contacts*, the *Configuration* menu moves out of its intended last position, breaking Odoo’s default menu hierarchy. <img width="467" height="148" alt="Behavior before PR:" src="https://github.com/user-attachments/assets/4cb6e3bb-00c0-4636-87de-c51b572dc42c" /> ## Desired behavior after PR is merged The sequence of the *Configuration* menu item is adjusted so that it always remains last, aligning with Odoo’s default menu hierarchy and avoiding friction between modules. <img width="467" height="148" alt="Behavior after PR is merged" src="https://github.com/user-attachments/assets/314c2556-5f2b-403d-af8d-ab550bff41a9" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234909
This update fixes a calculation error related to year and week numbers, particularly at the end of a year when weeks span across two years. Previously, the system incorrectly reset the year, leading to inaccurate reporting. This change ensures year and week numbers align correctly, improving data consistency and reporting accuracy.
Original PR description
### Description of the issue/feature this PR addresses: getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on…
### Description of the issue/feature this PR addresses: getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on the year where the week has most days. So if a week has 5 days in year Y and 2 in Y+1. The week is taken counting from Y (probably week 53). If a week has 3 days in Y and 4 in Y+1, then the week number is reset to 1. The year, however did not follow the same logic, and was taken as the year of the last day of the ISO week. ### Current behavior before PR: At the end of 2026, this will cause problems because the week number will run as: * 2026, week 52 (all days in 2026, OK) * 2027, week 53 (most days in 2026, last day in 2027, Not OK) * 2027, week 1 (all days in 2027, OK) ### Desired behavior after PR is merged: This commit aims to solve this issue by following the same logic for week number and year, so that the end of 2026 will go as: * 2026, week 52 (no changes) * 2026, week 53 (year is not incremented if week number is not reset) * 2027, week 1 (no changes, but year is incremented when week number is reset) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267871 Forward-Port-Of: odoo/odoo#267656
21 changes
Enhancements to existing features
This update clarifies the handling of Forward VAT (FWVAT) reverse charges in the Philippines. Previously, all DS and EM transactions used a single reverse-charge tax without Automatic Tax Collection (ATC). Now, separate taxes are created for DS and EM reverse charges, ensuring correct ATC application and compliance with local regulations.
Original PR description
The 12% FWVAT DS and EM groups shared a single reverse-charge tax with no ATC. Split it into two dedicated taxes so each carries its own ATC: 12% FWVAT RC DS (WV080) and 12% FWVAT RC EM (WV100). task-6278099 Forward-Port-Of: odoo/odoo#268502
Resolved issues and error corrections
This update optimizes Odoo's styling process, specifically reducing the time it takes to recalculate styles in large tables like the Accounting Balances Sheets. By removing unnecessary selectors, the system now responds faster to window resizing, scrolling, and sorting, leading to a smoother user experience.
Original PR description
Adapt selector to remove the :has value since it not needed to have the effect applied. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. This commit is a follow up of https://github.com/odoo-dev/enterprise/commit/8aa63b3c726d825e68430bb0a64a54c1b58d6af7 Note: We also fixes the scss button variable not correctly overided Forward-Port-Of: odoo/enterprise#119521
This update fixes an issue where invoices from certain Peppol suppliers (using a specific XML format) weren't being correctly imported. The fix ensures the system correctly identifies the supplier's VAT information, automatically creating the invoice and linking the associated bank account. This prevents import failures and ensures accurate financial data.
Original PR description
Some Peppol emitters carry the supplier VAT in cac:PartyIdentification/cbc:ID instead of the BIS3-standard cac:PartyTaxScheme/cbc:CompanyID. The import then extracted no VAT, the partner auto-creation not available (needs name+vat) and invoice.partner_id stayed empty. As a side effect, when the XML also carried a PayeeFinancialAccount, the bank account creation crashed with a NOT NULL violation on partner_id. Fall back on cac:PartyIdentification/cbc:ID when cbc:CompanyID is empty, so the partner is found (or auto-created) and the bank account is properly linked. Steps to reproduce: - Create a XML with the supplier VAT only in cac:PartyIdentification/cbc:ID and a cac:PayeeFinancialAccount/cbc:ID. - Upload on a purchase journal: import fails, the bill stays empty with an error in chatter. - With the fix: partner auto-created, bill filled, bank linked. opw-6148974 Forward-Port-Of: odoo/odoo#268316 Forward-Port-Of: odoo/odoo#261933
A previous issue caused errors when uploading fillable PDFs with no data entered. This update fixes a bug where an empty PDF generated a zero-page error. The fix skips the page merge process when no content is present, preventing the error and ensuring PDFs are generated correctly.
Original PR description
Version: 19.0 Issue: - Uploading a fillable PDF with no filled-in values caused an error. Cause: - When all form fields are empty, nothing is drawn on the ReportLab overlay canvas, producing a 0-page PDF. - Calling getPage(0) on an empty page list raised an IndexError. Fix: - Skip the page merge when the overlay has no pages to avoid the IndexError on empty fillable forms. Forward-Port-Of: odoo/enterprise#119677
This update prevents managers from overriding the card details when approving card expenses. Previously, setting a manager on a card expense would be cleared upon approval. This change ensures card expenses are controlled directly by the card itself, streamlining the expense approval process.
Original PR description
**Issue** If a manager was manually set on a card expense after it was created, it would be cleared when the expense was approved. **Change** Make the field readonly for card expenses, the idea is that the manager shouldn't need to approve card expenses since they are able to control them via the card itself. opw-6045587 Forward-Port-Of: odoo/enterprise#112593
This update ensures that work order employees are restricted to those specifically authorized for each workcenter. Previously, all employees could be assigned, but now the system checks a configuration setting to limit assignments to only those employees approved for that particular workcenter. This improves accuracy and control over work order assignments.
Original PR description
Add domain on `employee_assigned_ids` to restrict selectable employees based on the workcenter configuration. If `all_employees_allowed` is True, no filter is applied. Otherwise, only employees listed in `allowed_employees` are selectable. opw-6208602 Forward-Port-Of: odoo/enterprise#117876
This update corrects a bug that prevented signature requirement features from working correctly for US deliveries when using UPS. The change ensures that the system correctly requests signature confirmation based on delivery type (shipment vs. package level) as defined by the UPS API. This resolves an error message preventing rate calculations for shipments with signature requirements within the US.
Original PR description
Issue ----- Enabling signature requirement blocks US -> US deliveries. Steps to reproduce ----- - Setup UPS - enable signature requirement - Set current company to US - Create a US Customer - Create…
Issue ----- Enabling signature requirement blocks US -> US deliveries. Steps to reproduce ----- - Setup UPS - enable signature requirement - Set current company to US - Create a US Customer - Create a product with some weight - Create a SO for the product - Add UPS delivery and try to get a rate > Error: "The requested accessory option is unavailable between the selected locations." Cause ----- Depending on the type of transfer, signature is requested at shipment or package level (see the "Delivery Confirmation Origin-Destination Pairs" category of the following link) https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US US50 -> US50 & Canada -> Canada is package level Everything else is shipment level By default we use 'ShipmentServiceOptions_DeliveryConfirmation' for which 'DCISType' = 1 is the correct value. https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L8902-L8911 For package level, we should use 'PackageServiceOptions_DeliveryConfirmation' for which 'DCISType' = 2 would be the expected value https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L10410-L10421 ----- Ticket: opw-6173624 Forward-Port-Of: odoo/enterprise#117564
This update resolves a minor issue where the displayed name for the Sendcloud website delivery module had a typo ("Sendcould"). The fix ensures accurate module identification and avoids potential confusion. This change improves the clarity and consistency of our Odoo Enterprise software.
Original PR description
The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary.
opw-6239003
Forward-Port-Of: odoo/enterprise#118416
Forward-Port-Of: odoo/enterprise#118223This update fixes a bug that allowed users to validate internal transfer barcodes without scanning the destination location. Previously, deleting a line would cause validation to succeed incorrectly. The fix ensures that validation is blocked until the destination location has been scanned, improving data accuracy and preventing errors.
Original PR description
Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required.…
Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required. ## Steps to produce: - Install the Inventory module - Go to Settings and enable Storage Locations. - Inventory > Configuration > Operation Types > Internal Transfers > Barcode App - Configure the Destination Location to require scanning after each product. - Create an Internal Transfer for Pedal Bin, demand 1. - Mark the transfer as To Do and open it in the Barcode app. - Add quantity using +1, then scan the barcode for the Pedal Bin(Barcode: 6016478556493). - Delete the newly added line and attempt to Validate. ## Observed Behavior: The system should prevent transfer validation when the destination location has not been scanned and display a notification to the user, similar to the behavior before user deleted the newly added line. ## Root cause: This issue occurs because when the delete button is pressed, the deleteLine function [1] removes the line, but the deleted line becomes the selected line due to [2] being triggered before the UI updates. As a result, the selected line is now undefined. Since the selected line is undefined, it fails to meet the condition at [3] during validation. This prevents notifications from being triggered and allows the transfer to be validated before the destination location has been scanned. [1]: https://github.com/odoo/enterprise/blob/3476d15bf8e75eb6530658dd623861b60963ab40/stock_barcode/static/src/models/barcode_model.js#L826-L836 [2] : https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/stock_barcode/static/src/components/line.js#L129-L133 [3]: https://github.com/odoo/enterprise/blob/6ff158ca3a6d2d2b3d285a7f8317622844811688/stock_barcode/static/src/models/barcode_picking_model.js#L945-L948 ## Solution: We can prevent users from validating if any line has an unscanned destination location when destination-location scanning is mandatory after scanning each product. To enforce this behavior, we can track whether a line has been modified and whether a destination location has been scanned and applied to that line. This allows us to identify which lines still require destination location scanning before validation can proceed. However, line state information is currently discarded and recreated on every save. As a result, information about lines that were updated and already had their destination location scanned is lost. This may incorrectly require users to rescan the destination location, even though it was previously scanned. To address this, we preserve the destination-scanned and modified state by carrying it forward from existing lines to their corresponding newly created versions using a loop. This ensures that destination location scan status is retained and users are not asked to rescan unnecessarily. opw-6069614 Forward-Port-Of: odoo/enterprise#119499 Forward-Port-Of: odoo/enterprise#113618
This update corrects a bug where changes to the provider state on the Ticket Screen weren't reflected in the displayed orders. The fix ensures that the Ticket Screen reloads with the correct filters when the provider state is updated, guaranteeing accurate order information for UrbanPiper users. This improves the reliability of order review within the POS system.
Original PR description
Steps to Reproduce ------------------------- - Install Point of Sale and configure UrbanPiper. - Open a POS session and select a provider state from the notification popup to review orders. - While on the Ticket Screen, select a different provider state to review other orders. Issue ------- - Orders are not updated according to the newly selected state. - Previously applied filters remain unchanged. Cause -------- - Since the user is already on the Ticket Screen, changing only the provider state does not trigger a re-render. - The page was already rendered with the old filters. Fix ---- - The Ticket Screen is first switched away and then re-rendered. - This forces the screen to reload with the updated state and filters. Task: 6079663 Forward-Port-Of: odoo/enterprise#119309 Forward-Port-Of: odoo/enterprise#104546
This update fixes a bug where credit limit warnings incorrectly flagged customers as over budget, even after receiving bank payments. The system now accurately considers outstanding bank payments in its calculations, ensuring warnings only appear when the actual outstanding balance exceeds the credit limit. This improves financial reporting accuracy and prevents unnecessary alerts.
Original PR description
Before this fix: The credit limit warning calculation only considered credit notes but ignored outstanding bank payments when computing the partner's effective outstanding balance. For example, if a…
Before this fix: The credit limit warning calculation only considered credit notes but ignored outstanding bank payments when computing the partner's effective outstanding balance. For example, if a customer had a credit limit of 1,000 and an invoice of 2,000 was created, then a bank payment of 1,500 was received, the warning would still incorrectly appear showing the customer exceeded their limit (2,000 > 1,000), even though the actual outstanding amount was only 500. After this fix: The credit limit warning now properly includes outstanding bank payments in the calculation. Two cases are handled: - Bank payments received but not yet matched to any invoice, these are identified by their open suspense account entry and deducted from the partner's outstanding exposure. - Bank payments already matched to the invoice, the reconciled amount is read from the invoice's receivable line and deducted accordingly. So with this fix, after a 1,500 bank payment, the system correctly recognises the outstanding amount as 500 and does not show a warning since it is within the 1,000 credit limit. task-5427613 Forward-Port-Of: odoo/enterprise#119691 Forward-Port-Of: odoo/enterprise#118957
This update fixes an issue where DATEV export files incorrectly included EU-specific fields for customers outside the European Union. The change ensures that the correct country field (`Land`) is populated for non-EU customers, aligning with DATEV's data format requirements and improving data accuracy for reporting.
Original PR description
### Issue: In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled However, these fields must only be used for EU countries…
### Issue: In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled However, these fields must only be used for EU countries For non-EU countries, the `Land` field should be filled instead, and is required whenever the country is not Germany https://developer.datev.de/en/file-format/details/datev-format/format-description/debitorskreditors ### Cause: `_l10n_de_datev_get_partner_list` did not distinguish between EU and non-EU countries As a result, any partner with a VAT number could populate `EU-Land` and `EU-UStID`, even if the country was outside the EU Greece also requires a special case: its VAT prefix is `EL` so the `EU-Land` too, while the country code used in `Land` must remain `GR` ### Steps to reproduce: - Install `l10n_de_reports` and switch to the DE company - Create a customer in Switzerland with a valid VAT number - Create and confirm an invoice for that customer - Go to Accounting → Audit Reports → General Ledger - Select the full year - From the gear menu, export DATEV DATA (zip) - Open the `EXTF_customer_accounts` file ### Before the fix: `EU-Land` and `EU-UStID` are filled for the Swiss customer, while `Land` is empty ### After the fix: `EU-Land` and `EU-UStID` are empty for non-EU countries such as Switzerland, while `Land` is correctly filled `Land` is filled using the following priority: 1. Partner country_code 2. Country extracted from the VAT number 3. Empty opw-5902565 Forward-Port-Of: odoo/enterprise#119593 Forward-Port-Of: odoo/enterprise#113835
This update significantly speeds up the Inventory Valuation report by reducing the number of products processed. Previously, the report strained system resources, but now it focuses only on products with stock, dramatically improving performance – especially for large catalogs. This results in faster report generation and reduced system load.
Original PR description
Opening the Inventory Valuation report iterated every storable product to compute total_value, which on large catalogs used several GB of RAM and timed out workers. The report now searches only…
Opening the Inventory Valuation report iterated every storable product to compute total_value, which on large catalogs used several GB of RAM and timed out workers. The report now searches only products that have stock (under the same valuation context that total_value uses) or that are lot-valuated, and feeds that smaller set into stock_value and stock_accounting_value. For historical (at_date) reports the search runs with to_date in context so qty_available is scoped to that date. _get_accounts_by_product() also switches to search_fetch so only categ_id is loaded upfront. Benchmarks were measured on a customer database restore with ~360k storable products. After filtering, ~2.5k products feed into the valuation today and ~2.2k for a historical date. Benchmark opening Inventory Valuation report (Accounting) | Date | Before | After | Speed up | |------------|--------|--------|----------| | Today | ~88s | ~2s | 41x | | Historical | ~245s | ~173s | 1.4x | The historical improvement is more modest because stock_value still has to compute total_value at the historical date for the remaining products, which traces SVL/stock.move history; the filter eliminates the dominant per-product overhead today but only the tail in the historical case. 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#254010
This update fixes an issue where vendor bills imported from Poland's KSeF system were not correctly accounting for discounts applied to individual items. The update now properly parses the 'P_10' XML node, ensuring accurate bill data is imported and processed. This improves the reliability of financial reporting for businesses using the KSeF system.
Original PR description
When fetching vendor bills from KSeF, the XML node "P_10" is used to indicate a discount per unit on a line. This node is currently being ignored when parsing the file. Official documentation: https://ksef.podatki.gov.pl/media/gn2kt4gl/broszura-informacyjna-struktury-logicznej-e-faktury-fa-1-wersja-anglojezyczna.pdf opw-6235460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268551 Forward-Port-Of: odoo/odoo#267235
This update resolves an issue where test runs for the KPI provider were failing due to leftover account moves in the test environment. The fix ensures these moves are cleaned up before tests run, preventing inaccurate results and test failures. This improves the reliability of the KPI provider test suite.
Original PR description
The KPI provider test setup could leave some account moves behind when running with all modules and demo data installed. These leftover moves were then detected by subsequent test steps, causing incorrect numbers and test failures. This commit ensures the targeted moves are removed to provide an empty test environment. Payments need to be canceled first; otherwise unlinking the moves raises a ValidationError. [runbot-939456](https://runbot.odoo.com/odoo/error/939456) Forward-Port-Of: odoo/odoo#268151
This update adjusts Odoo's Turkish VAT validation to now accept special placeholder VAT numbers (GİB) used for invoices to non-taxpayers and overseas customers, as permitted by Turkish regulations. This simplifies invoice creation for businesses operating in Turkey without requiring mandatory TCKN/VKN information. The change maintains existing VAT validation rules and exceptions.
Original PR description
- Turkish regulations allow the usage of special placeholder identifiers for invoices issued to non-taxpayer end consumers and overseas customers, where providing a real TCKN/VKN is not mandatory. - Although Odoo already referenced these identifiers in the VAT format help message (`11111111111` for TCKN and `2222222222` for VKN), they were still rejected by the Turkish VAT validation logic because they do not pass the standard `stdnum` checks. - This commit extends the Turkish VAT validation to explicitly allow these GİB-approved placeholder identifiers while preserving the existing standard VAT validation behavior and Nilvera test environment exceptions. taskID-6237629 Forward-Port-Of: odoo/odoo#268225
This update corrects a display issue where the 'Show Sub-Tasks' option was incorrectly visible in the mobile My Tasks menu for both the standard project and the project_todo modules. The fix ensures that this button is hidden where it doesn't apply, improving the user experience and preventing confusion.
Original PR description
Steps to reproduce: - Install project - Open the My Tasks menu on mobile view Issue: The "Show Sub-Tasks" option was visible in the My Tasks menu on mobile view. Cause: The condition only applied `showTaskOptions` to the desktop part of the expression, so the dropdown was still rendered on mobile when there were no embedded actions. Apply `showTaskOptions` to the whole condition to properly hide the dropdown in the My Tasks mobile view. Fix-2: Steps to reproduce: - Install project_todo Issue: The Show Sub-Tasks button was visible in project_todo views even though To-do items do not support subtasks. Fix: Ensure that the Show Sub-Tasks button is hidden in project_todo views. task-6026239 Forward-Port-Of: odoo/odoo#255283
This update corrects a bug in how leads are assigned to sales teams, ensuring a more equitable distribution of leads. Previously, older team members received a disproportionate number of leads, especially when team quotas were equal. The fix introduces random tie-breaking to ensure fair lead assignment across the team.
Original PR description
_assign_and_convert_leads() is biased towards team members created earlier because they're ordered by create_date, id. When members have equal quota, the round-robin order falls back to the order of the team members. If the amount of leads distributed across the team is not a multiple of the team size, then the oldest members will get more leads assigned. This advantage repeats each time the cron runs and can add up to a big difference, the provided test case ends up assigning all 30 leads to the more senior member without the fix. Note that the lead_day_count field used in _get_assignment_quota() doesn't solve the problem. It helps to balance leads assigned in the same 24 hour window, but because the same senior person always goes first inside one of those windows, they will always get more leads assigned to them. To fix it we break ties in the quota randomly. task-6119168 Forward-Port-Of: odoo/odoo#268716 Forward-Port-Of: odoo/odoo#259775
This update resolves an issue where scanning a package type alongside a regular package didn't correctly link the new package to the product. The fix ensures that when scanning a package type, the system creates a new package and associates it with the correct product, resolving a gap in the barcode scanning workflow. This improves the accuracy and usability of the barcode inventory system.
Original PR description
When scanning a package then a package type, from the point of view of the user nothing happend, and in the backend it will created a new package but it will not link it to the products nor will it…
When scanning a package then a package type, from the point of view of the user nothing happend, and in the backend it will created a new package but it will not link it to the products nor will it show any warning. Steps to reproduce: ------------------- * Install barcode and stock * Enable packages in settings * Open Inventory * Create a product, * Create a Package Type -> barcode PACKTYPE, * Create a Package linked to this package type -> PACK, * Add at least 2 unit of product to this package, * Create a delivery for 2 unit of the product, Open Barcode * Operation > Delivery orders > your delivery * Erase the destination package from the first line * Scan PACK ( don't click on the green line) * Scan PACKTYPE **Actual behavior** create a new package but does not link it to the new products **Expected behavior** create a new package and set it as destination package. Observation: ------------- When scanning the package (PACK), we will go through ```_processPackage``` -> ```async _processPackage``` where in the end the line is unselected: https://github.com/odoo/enterprise/blob/39d8a473fe03038ca0494a6a8165e3eb75bd8492/stock_barcode/static/src/models/barcode_picking_model.js#L2090 When we scan our package type (PACKTYPE), we will go to ``` _processPackage``` -> ```_processPackage```->```_processPackageType``` where we will obtains packagesIds checking that we have a source package: https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2123-L2132 and will send us to ```_putPackInPack```: https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2133-L2136 Where we will avoid the empty packageIds since we checked on the source package and not the destination package: https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2296-L2299 and will call ```action_put_in_pack``` from the packaging model: https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2301-L2306 In ```action_put_in_pack``` will create a new packaging and put it as a the new destination package, but since the ```previous_dest_package``` (saved in db) was itself, he will [erase the link](https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_package.py#L354-L363) he just made. Which means that in our case, we created a package without linking it to anything. Even if we avoid the function to erase the destination package, since the destination package shown in barcode is the one from move line : https://github.com/odoo/enterprise/blob/d0d0a3cf4a02bf24cf502b533e494fe7ca155eb3/stock_barcode/static/src/components/line.js#L115-L117 It will not show the new package in barcode opw-5449729 Forward-Port-Of: odoo/enterprise#104876
This update fixes an issue where the year calculation was incorrect when weeks spanned across years, particularly at the end of 2026. The change ensures consistent year and week number tracking, preventing unexpected jumps and maintaining accurate date representations. This improves the reliability of reporting and scheduling.
Original PR description
### Description of the issue/feature this PR addresses: getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on…
### Description of the issue/feature this PR addresses: getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on the year where the week has most days. So if a week has 5 days in year Y and 2 in Y+1. The week is taken counting from Y (probably week 53). If a week has 3 days in Y and 4 in Y+1, then the week number is reset to 1. The year, however did not follow the same logic, and was taken as the year of the last day of the ISO week. ### Current behavior before PR: At the end of 2026, this will cause problems because the week number will run as: * 2026, week 52 (all days in 2026, OK) * 2027, week 53 (most days in 2026, last day in 2027, Not OK) * 2027, week 1 (all days in 2027, OK) ### Desired behavior after PR is merged: This commit aims to solve this issue by following the same logic for week number and year, so that the end of 2026 will go as: * 2026, week 52 (no changes) * 2026, week 53 (year is not incremented if week number is not reset) * 2027, week 1 (no changes, but year is incremented when week number is reset) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267871 Forward-Port-Of: odoo/odoo#267656
This update ensures that Quality Checks and Mass Produce options remain accessible on the Shop Floor, regardless of whether production is automatically closed. Previously, disabling auto-close would hide these critical features, preventing users from completing quality checks and generating serial numbers. Now, these options are consistently available to facilitate efficient production workflows.
Original PR description
### *Why this commit*: --- Ensures Quality Checks and Mass Produce options remain available on the Shop Floor regardless of the "Auto-close Production" setting. ### *Steps to Reproduce* --- 1. Define…
### *Why this commit*: --- Ensures Quality Checks and Mass Produce options remain available on the Shop Floor regardless of the "Auto-close Production" setting. ### *Steps to Reproduce* --- 1. Define a product tracked by Serial Numbers with a Manufacturing BoM. 2. Create a Quality Control Point for the product on the Manufacturing operation. 3. In Inventory Configuration, disable "Auto-close Production" on the Manufacturing operation type. 4. Create a Manufacturing Order (MO) and open it in the Shop Floor view. 5. If the MO has no operations, try to use Mass Produce. ### *Before this PR* --- When auto_close_production was set to False, the Shop Floor card footer incorrectly hid both the Quality Checks and Mass Produce buttons. This blocked users from registering Serial Numbers and completing mandatory quality check steps. Additionally, for products without BoM operations, clicking Mass Produce triggered quality check validation instead leading to errors, preventing the generation of serial numbers. ### *After this PR* --- The visibility logic for Shop Floor actions is now decoupled from the closing permission. The workflow follows this corrected sequence: Mass Produce: Stays visible to allow serial registration and backorder creation even if the MO cannot be closed from the Shop Floor. Quality Checks: Remain accessible to ensure all mandatory tests are passed before production progresses. Close Production: Only appears if "Auto-close Production" is enabled on the operation type. OPW: 5473839 Forward-Port-Of: odoo/enterprise#115529 Forward-Port-Of: odoo/enterprise#103926
4 changes
Resolved issues and error corrections
This update resolves a critical issue preventing correct receipt printing in Austria, ensuring accurate financial records. It also addresses a deadlock during authentication with Fiskaly and FON, improving system stability and reliability. The original error message was discarded to maintain focus on core functionality.
Original PR description
In this task: -------------- - Fixed Austria closing receipt printing by calculating the offset from the last closed month instead of the current month. Closing records are returned in ascending order and exist only for completed months, so the latest month must use offset 0. - Prevent a deadlock during Fiskaly and FON authentication by checking for open sessions before starting any authentication flow, instead of after the first step of authentication. - The resp was used to show error which was not in the scope. task: 5420256 Forward-Port-Of: odoo/enterprise#102313
This update fixes an issue where DATEV customer exports incorrectly included EU-specific fields for customers outside the European Union. The change ensures that non-EU customers, like those in Switzerland, use the correct country code (`Land`) field, aligning with DATEV's data format requirements. This improves data accuracy and compliance for international reporting.
Original PR description
### Issue: In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled However, these fields must only be used for EU countries…
### Issue: In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled However, these fields must only be used for EU countries For non-EU countries, the `Land` field should be filled instead, and is required whenever the country is not Germany https://developer.datev.de/en/file-format/details/datev-format/format-description/debitorskreditors ### Cause: `_l10n_de_datev_get_partner_list` did not distinguish between EU and non-EU countries As a result, any partner with a VAT number could populate `EU-Land` and `EU-UStID`, even if the country was outside the EU Greece also requires a special case: its VAT prefix is `EL` so the `EU-Land` too, while the country code used in `Land` must remain `GR` ### Steps to reproduce: - Install `l10n_de_reports` and switch to the DE company - Create a customer in Switzerland with a valid VAT number - Create and confirm an invoice for that customer - Go to Accounting → Audit Reports → General Ledger - Select the full year - From the gear menu, export DATEV DATA (zip) - Open the `EXTF_customer_accounts` file ### Before the fix: `EU-Land` and `EU-UStID` are filled for the Swiss customer, while `Land` is empty ### After the fix: `EU-Land` and `EU-UStID` are empty for non-EU countries such as Switzerland, while `Land` is correctly filled `Land` is filled using the following priority: 1. Partner country_code 2. Country extracted from the VAT number 3. Empty opw-5902565 Forward-Port-Of: odoo/enterprise#119593 Forward-Port-Of: odoo/enterprise#113835
This update resolves a minor visual issue where the name of the Sendcloud website delivery module was incorrectly displayed as 'Sendcould'. The fix ensures consistent and accurate module naming within the Odoo Enterprise platform. This change improves the user experience and avoids potential confusion.
Original PR description
The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary.
opw-6239003
Forward-Port-Of: odoo/enterprise#118416
Forward-Port-Of: odoo/enterprise#118223This update resolves an issue where the commission report displayed empty groups when linked to inactive commission plans. By excluding these plans from the report's initial data processing, the report now accurately shows populated groups, providing a cleaner and more reliable view of commission achievements. This ensures sales teams have accurate data for their performance analysis.
Original PR description
Steps to reproduce: 1. create a commission plan 2. invoice an SO with the linked salesperson to the plan to progress towards the target 3. Archive the commission plan 4. Go to Sales > Commissions > Commissions 5. Remove all filters The `sale.commission.report` includes empty groups for `sale.commission.achievement.report` that are linked to inactive commission plans By excluding said plans from the initial join, the report would display populated groups only without the clutter. opw-6177132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#119695 Forward-Port-Of: odoo/enterprise#117615
4 changes
Resolved issues and error corrections
This update corrects a bug in how leads are assigned to sales teams, ensuring a more equitable distribution of leads. Previously, team members created earlier received a disproportionate number of leads, particularly when quotas were equal. The fix introduces random tie-breaking to ensure fair lead assignment across the team.
Original PR description
_assign_and_convert_leads() is biased towards team members created earlier because they're ordered by create_date, id. When members have equal quota, the round-robin order falls back to the order of the team members. If the amount of leads distributed across the team is not a multiple of the team size, then the oldest members will get more leads assigned. This advantage repeats each time the cron runs and can add up to a big difference, the provided test case ends up assigning all 30 leads to the more senior member without the fix. Note that the lead_day_count field used in _get_assignment_quota() doesn't solve the problem. It helps to balance leads assigned in the same 24 hour window, but because the same senior person always goes first inside one of those windows, they will always get more leads assigned to them. To fix it we break ties in the quota randomly. task-6119168 Forward-Port-Of: odoo/odoo#268350 Forward-Port-Of: odoo/odoo#259775
This update fixes a visual issue in the portal chatter interface where elements like the Follow/Unfollow button appeared misaligned due to excessive padding. The problem was caused by a duplicated padding setting that has now been removed from the core code. This ensures a cleaner and more professional appearance for portal users.
Original PR description
**Steps to reproduce:** 1. Log in as a portal user. 2. Open a shared project and then open any task within it. 3. Observe the vertical spacing above the Follow/Unfollow button and the chatter component. **Issue:** The chatter UI has incorrect vertical spacing, causing elements like the Follow/Unfollow button to sit too far down and appear misaligned. **Cause:** The pt-2 padding class was hardcoded in two separate locations: 1. The compileChatter wrapper in project_sharing_form_compiler.js. 2. The portal.Chatter XML template. When combined this caused a double-padding effect forcing excessive space. **Fix:** Removed the hardcoded pt-2 class from both the JavaScript compiler wrapper and the core XML template. This eliminates the double-padding conflict. This resolves the alignment issue in Project Sharing and does not affect the layout or functionality of other portal components. task-4203362 Forward-Port-Of: odoo/odoo#257490
This update ensures the KSeF vendor bill download cron job continues to run even if some XML files are corrupted. Previously, a single error would halt the entire process. Now, errors are logged, and the cron job successfully processes the remaining valid invoices, preventing data loss.
Original PR description
Description of the issue/feature this PR addresses: Issue: When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file is…
Description of the issue/feature this PR addresses: Issue: When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file is missing something that is expected, the parser raises a UserError. This unhandled exception halts the entire cron job and rolls back the database transaction, clogging up the rest of the queue. Solution: This PR wraps the l10n_pl_edi_get_ksef_bill_vals_from_xml parsing step inside a try/except block within the batch download loop. If a UserError is encountered for a specific invoice, the error is logged as a warning, and the cron proceeds. Current behavior before PR: A single malformed XML file causes the cron to fail completely. Valid invoices in the same batch are not created due to the halted queue. Desired behavior after PR is merged: The cron successfully processes the batch of downloaded XMLs even if one or more files are invalid. Errors on specific invoices are logged for the user to investigate, while the rest of the valid vendor bills in the batch are succesfully created. opw-6218288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268681 Forward-Port-Of: odoo/odoo#267816
This update corrects a bug where new lines added to sales orders from deliveries were missing descriptions. Now, when a delivery line is created, the corresponding sale order line automatically uses the product's existing description, ensuring accurate record-keeping and improved reporting. This prevents inconsistencies in sales order details.
Original PR description
When a line is added to a delivery related to a sale order, the corresponding line created in the sale order uses only the display_name as a description. This commit makes sure that if a previous SO line exists for the product, the new line uses the same description. Otherwise we call `get_product_multiline_description_sale()` Steps to reproduce: - Create a product with a description in the Sales tab - Create a quotation with any product (can be said product) and confirm it - Go to the delivery action, and add a new line with the product in the view, set delivered quantity to 1 - After Validating, you'll notice that the new line in the Quotation doesn't have a description opw-6175891 Forward-Port-Of: odoo/odoo#262276
1 change
Resolved issues and error corrections
This update prevents empty ICS calendar files from being generated when publishing shifts. Previously, a technical issue caused an empty ICS file to be created when a matching slot wasn't found. The fix ensures the ICS file is only generated when a valid employee is assigned to the shift, improving calendar integration.
Original PR description
**Step:** - install planning - create a resource - create an open shift for a future date - in Gantt view: - publish shift and select the created resource - click “Publish & Send” - check the email and click “Add to Calendar” **Issue:** Currently, clicking “Add to Calendar” generates an empty ics file. **Reason:** During ics file generation, the planning token to find a slot using the planning date and employee. but, no matching slot is found, so the process returns an empty slot, resulting in an empty ics file. **Fix:** Generate the `planning_url_ics` only when a slot is linked with an employee. Otherwise, hide the “Add to Calendar” button and do not generate the ics file. Forward-Port-Of: odoo/enterprise#118978
25 changes
New functionality added to Odoo
This update improves the Timesheets Assistant by adding a new rule that suggests entries like "Working on <drawing>" based on Excalidraw drawings. This allows users to more easily and quickly record their time spent on projects using this popular drawing tool, streamlining timesheet creation.
Original PR description
This commit adds an `aw.rule` covering Excalidraw. Timesheets Assistant can suggest "Working on <drawing>" entries. task-6267748
Enhancements to existing features
This update simplifies the softphone's contact search by prioritizing recent contacts and providing a dedicated history view for each contact. The previous 'contacts' tab has been removed, streamlining the process to focus on searching and reviewing recent interactions, making it easier to find relevant contact information.
Original PR description
Before: - Search in "recent" tab searches recent calls. - A "contacts" tab allows to browse contacts (and search them). Now: - Search in "recent" tab searches *contacts*. This looks better as if you…
Before: - Search in "recent" tab searches recent calls. - A "contacts" tab allows to browse contacts (and search them). Now: - Search in "recent" tab searches *contacts*. This looks better as if you search "john", it is often more useful to find your multiple "john" contacts rather that a chaos list of all the calls you had with all the "john"s. - The "contacts" tab is gone (search them via keypad or recent tabs): indeed, browsing contacts is rarely useful, you'd rather search for them, which you can now do both in keypad and recent tabs. - From a "contact" entry (found with a search), a new "history" button allows to list recent calls records linked to that contact. This is mostly what you wanted while searching in the "recent" tab before: if you searched "john", you found all your "john" calls... but maybe of multiple "john"s. Now you find your multiple "john" contacts, click on the correct one, click the "history" button and find the calls you wanted to find. And more, see commits for details. task-5475573
This update improves the DEP7 export process by switching from PDF to JSON files, aligning with regulatory requirements for German tax reporting (BMF/RKSV). The new JSON format is machine-readable and uses a standardized filename structure, ensuring compatibility with official tax tools and simplifying data processing.
Original PR description
In this commit: ------------------- - Updated the DEP7 export to generate a zip with JSON files instead of PDF, in compliance with BMF (RKSV) requirements. - The export now produces a valid JSON document containing the machine-readable data expected by the official BMF tools. - The filename format has also been adjusted to follow common conventions (e.g. `Name_Duration_DEP_KassenID.json`). Task: 6071034 Forward-Port-Of: odoo/enterprise#112276
Resolved issues and error corrections
This update removes unnecessary code from the timesheet grid component. Previously, unused data passed to the grid rows has been removed, streamlining the component and improving performance. This change ensures the timesheet grid is more efficient and maintainable.
Original PR description
Currently, we are not passing the relation props to the Many2OneGridRow component. Therefore, it is unused and has been removed. task: 4461272
This update fixes an issue preventing users from accessing the payroll tab when creating a new employee in the Belgium localization. The fix involved adjusting how a related field is calculated, ensuring the payroll tab opens correctly without errors. This improves the employee onboarding process for Belgian companies.
Original PR description
[FIX] l10n_be: payroll tab opening
Bug reproduction:
1 - Master -> Belgium company -> Employee app.
2 - Create new employee, before saving it press to payroll tab, traceback is there.
Bug cause:
1 - available_l10n_be_worker_status has a compute
2 - l10n_be_worker_status uses filterable_selection widget that uses available_l10n_be_worker_status as whitelist_fname.
3 - Before available_l10n_be_worker_status compute works, the JS of widget executes and this.props.record.data[this.props.whitelist_fname].includes raises the error, since False has not includes
Bug solution:
1 - I have used the filterable_selection in the Belgium Localization before and it was not causing this issue.
2 - I noticed that inherited=True is used in field available_l10n_be_worker_status for the employee, but there is no upper model that uses this field so inherited=True is meaningless.
3 - When we deleted it, it works.
task - 6275543This update simplifies the process of creating invoices for subscriptions by removing redundant logic previously handled by the Sales module. The change ensures Sales remains responsible for its button conditions, making the system more stable and easier to maintain. This improves the overall reliability of subscription billing.
Original PR description
Subscription used to override the Sales "Create Invoice" button to inject its own rules. That forced us to re-implement Sales visibility logic and keep it in sync, which is fragile and easy to miss when Sales evolves. Keep Sales in charge of its own button conditions and add a dedicated Subscription button only when needed. This preserves upstream behavior while still enabling subscription-specific flows. task-6208702 See also: - https://github.com/odoo/odoo/pull/263868
This update corrects a previous issue where the 'Add reaction' button was incorrectly displayed on all messages in the Odoo Chatter interface. The fix ensures the button's visibility is properly controlled, preventing a confusing user experience. This was a regression caused by a previous code change.
Original PR description
Before this commit, message action "Add a reaction" was always visible on all messages in chatter. This is a regression made by [1], in which the `Message.isActive` getter was overridden and mistakenly passed `undefined` as props to the `QuickReactionMenu`, which made it display the button. This commit fixes the issue by enforcing `Boolean()` on `Message.isActive`, so that this is properly provided to `QuickReactionMenu` to enforce its visibility state. https://github.com/odoo/odoo/pull/268832 [1]: https://github.com/odoo/enterprise/pull/110501 Before / After <img width="543" height="332" alt="Screenshot 2026-06-08 at 12 20 40" src="https://github.com/user-attachments/assets/92db46fd-f3d8-4d26-847e-c972e8103c83" /> <img width="527" height="313" alt="Screenshot 2026-06-08 at 12 20 53" src="https://github.com/user-attachments/assets/b49d18c2-b601-4567-872b-ceeb02ca1996" />
This update resolves an issue where PDF documents received via email were incorrectly displayed with a duplicate iframe preview. The fix ensures that the document preview accurately shows the PDF content, addressing a visual inconsistency. This improvement enhances the user experience when viewing documents attached to emails.
Original PR description
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the…
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the document preview - Preview is split in two iframes, both with the same content (pdf) **Issue:** Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`. ``` <iframe t-if="state.file.isPdf" ... <iframe t-if="state.file.isText" ... ``` It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file. **Fix:** Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`. Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: `<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">` which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450 opw-6018536 Forward-Port-Of: odoo/enterprise#118863 Forward-Port-Of: odoo/enterprise#112041
This update fixes a bug that prevented recent ratings from appearing in the Helpdesk rating dashboard. The change now uses the current date and time for searches, ensuring that ratings created within the last seven days are accurately reflected. This improves the accuracy of reporting and provides a more complete view of customer feedback.
Original PR description
Before this commit, the ratings created the current date at 23h will not been taken into account in helpdesk rating dashboard. This commit uses datetime.now() instead of date.today() to search the ratings in the last 7 seven days. runbot-error-230905 Forward-Port-Of: odoo/enterprise#119035
This update corrects an issue in the l10n_lu_reports module that caused incorrect balance sheet reports. Specifically, fields 2955 and 2956 must always be set to zero, as required by Luxembourg's eCDF reporting standards. Fixing this ensures reports are accepted by the eCDF, preventing data rejection and maintaining accurate financial reporting.
Original PR description
Before this commit, fields 2955 and 2956 in the balance sheet could be incorrect. 2955 must always be blank (not exist) and 2956 must always be 0 per: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/CA_PLANCOMPTA/2020/en/2/rules page 116 + 117 If they are not these values specifically, submitting the XML to eCDF results in the report being rejected. Steps to reproduce: - Install l10n_lu_reports - Create a journal entry for a closed year (2025) that debits account 142000 and credits another account that starts with a 1 - Go to the balance sheet for 2025 - Download the XML for the report - 2955 is present and 2956 is either not present or is not 0 (behavior varies between versions) Ticket [link](https://www.odoo.com/odoo/project.task/6246564) opw-6246564 Forward-Port-Of: odoo/enterprise#119193
This update fixes a technical error that was preventing warning messages from being logged correctly within the IoT module. The issue stemmed from how data was being passed to the logging function, and this change ensures all warning messages are now properly recorded.
Original PR description
Error: ``` TypeError: Logger._log() got an unexpected keyword argument 'ip' ``` Cause: - The `**new_iot_record` unpacks the dictionary into keyword arguments for `Logger._log()` instead of supplying it as the value for the third `%s` placeholder in the warning message, causing the error because `_log()` doesn't accept keywords such as `version` or `ip`. sentry-7522168864 Forward-Port-Of: odoo/enterprise#119494
This update resolves a bug where the 'Reset Selected Work Entries' function in payroll was unexpectedly deleting work entries. The issue stemmed from incorrect time zone handling, which caused the system to incorrectly identify and remove entries. The fix ensures accurate work entry management regardless of employee time zones.
Original PR description
Setup: Set the work entry source to attendance for an employee with active contract and change his timezone so that it differs from the working schedule one. Reset previous/next day delete Work Entry (payroll) - Step to reproduce: after an attendance was created, go to "Work Entries" in payroll, select the previous/next day and hit "Reset Selected Work Entries". The Work Entry will disappear. - Cause: domain to nullify using wrong tz - Solution: adjust domain to use calendar tz - Test: testing positive ans negative tz in hr_work_entry_attendance (enterprise) Task: 6072325 Forward-Port-Of: odoo/enterprise#118940 Forward-Port-Of: odoo/enterprise#114148
A technical issue preventing users from configuring billing targets within the Timesheets module has been resolved. This change ensures that users can correctly set billing rates for employee time entries, improving the accuracy of billing data. The fix addresses a problem related to a required field within the Timesheets configuration.
Original PR description
… of employees Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `work_location_type` field, change made from https://github.com/odoo/odoo/commit/0496ed10636c7b2dfde7038a43494d4edbd9f95b. - Thus unavailability of field causing the traceback. Fix: - Add a related field for work_location_type from which we get the value. Forward-Port-Of: odoo/enterprise#97502
This update adds a warning banner to key Philippine tax reports (SAWT/QAP, BIR 2306/2307, SLSP) to alert users when contacts within the report lack a defined entity type. This ensures accurate reporting and helps users quickly correct missing information, preventing potential issues with tax compliance.
Original PR description
Add a warning banner on SAWT/QAP, BIR 2306/2307, and SLSP reports when one or more contacts appearing in the report do not have an entity type set. The banner includes a link to view and update the affected contacts. Community PR: https://github.com/odoo/odoo/pull/268460 task-6278053
This update corrects a previous issue in the overtime tour by changing the tracking method field from a dropdown to a checkbox. This simplifies the process for employees and administrators, ensuring consistent and accurate overtime tracking. The change also includes improvements to the tour's execution flow.
Original PR description
The tour previously matched the tracking method field with his previous implementation, where it was a dropdown selection, while now is a checkbox. task-6197878 Forward-Port-Of: odoo/enterprise#116733
This update corrects an issue where combo products incorrectly appeared in the 'Invoiced Not Delivered' report even after full delivery of their items. The fix ensures the report accurately reflects only genuinely undelivered items by excluding the combo parent line, which doesn't track actual stock movements.
Original PR description
**Problem:** A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered. **Steps…
**Problem:** A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered. **Steps to reproduce:** 1. Create a combo product bundling two storable items. 2. Sell the combo on a sale order, confirm and invoice it. 3. Deliver every combo item. 4. Open Accounting > Review > Invoiced Not Delivered. **Current behavior:** The combo parent line is listed. While items are partially delivered, both the parent and the items are listed, duplicating the same information. **Expected behavior:** The combo parent is not listed; only the combo item lines, which carry the real delivery state, appear when they are genuinely not delivered. **Cause of the issue:** A combo parent is a virtual sale order line with no stock move of its own, so its delivered quantity is never advanced and always reads 0. The accrual report selects lines where `qty_invoiced_at_date > qty_delivered_at_date`, so the parent (which does receive an invoiced quantity from the combo logic) matches forever. **Fix:** Combo parents carry no delivery information of their own, so excluding them from the accrual search domain is more accurate than inventing a delivered quantity for them. Their combo item lines already represent the real delivery state, so the report stays correct. opw-6215110 Forward-Port-Of: odoo/enterprise#119243 Forward-Port-Of: odoo/enterprise#118942
This update resolves a bug that prevented users from creating new social media posts when no social account was configured. The fix prevents a crash caused by attempting to measure the width of a read-only text area, ensuring a smoother post creation experience.
Original PR description
Steps to reproduce: 1. Install social module 2. Keep no social account set 3. Create a new post by social media > posts menu > new Issue: We got a traceback saying: `OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) TypeError: Cannot read properties of null (reading 'getBoundingClientRect')` Cause: When no social account is set, the message field renders in read-only mode, so the <textarea> is never mounted, and textareaRef.el is null. The useEffect tracking the textarea's width fires and crashes. https://github.com/odoo/enterprise/blob/77be4285785f9d8a462b99b23185a9aefeae4482/social/views/social_post_template_views.xml#L37-L41 Solution: Add a null guard on textareaEl inside the useEffect callback so that the width computation is skipped when the textarea is not present in the DOM. opw-6218431 Forward-Port-Of: odoo/enterprise#117599
This update corrects a bug in the Belgian payroll calculation that prevented the correct handling of the 'forced variable salary' for the 13th month pay structure. The fix ensures the system accurately incorporates this salary value during payslip computation, resolving a previous type error.
Original PR description
Steps to reproduce: * Create a new payslip in belgian localization * Set pay structure type to 13th month * Set the input value for the forced variable salary * Compute the payslip sheet Issue: * Despite the change of benefits to properties, the avg_variable_revenues was still being set as one of the benefit lines instead of ref_property value which was causing an type_error traceback Solution: A simple approach is to be followed to retrieve the value fo the forced variable salary from the actual property being set by the user at the payslip form view and will be accounted for in the payslip computation. Task: 6241608 Forward-Port-Of: odoo/enterprise#118862 Forward-Port-Of: odoo/enterprise#118644
This update fixes an issue preventing standard users from accessing timesheet configuration options and sharing rules with higher-level users. The change ensures all users with appropriate access, including those with 'All Timesheets' permissions, can correctly configure and share timesheet rules.
Original PR description
Issue 1: Assistant Rules inaccessible to standard users Steps to Reproduce: - Install sale_timesheet. - Disable the "Billing Rate Indicators" setting. - Log in as a user with only "Own Timesheets"…
Issue 1: Assistant Rules inaccessible to standard users Steps to Reproduce: - Install sale_timesheet. - Disable the "Billing Rate Indicators" setting. - Log in as a user with only "Own Timesheets" access. - Open the Timesheets app. Current Behavior: - The Configuration menu is completely hidden, making Assistant Rules inaccessible to the user. Cause: - When sale_timesheet is installed, the "All Timesheets" access restriction is inaccurately applied to the main Configuration parent menu rather than specifically targeting the Billing Rate child menus. - The Configuration menu is blacklisted using a strict AND condition, requiring the user to have the Use Assistant group and hold a Timesheets Admin / Administrator / Technical Features role. This prevents standard timesheet users from configuring their own rules. Fix: - Remove the "All Timesheets" access restriction from the parent Configuration menu and apply it directly to the Billing Rate menus instead. - Update the blacklisting logic to use an OR condition, ensuring the configuration menu is visible if a user has Admin access to timesheets or belongs to the Use Assistant group. --- Issue 2: Unable to share rules with higher-level users Steps to Reproduce: - Create a user with "All Timesheets" access. - Open the Timesheets app and navigate to Assistant Rules. - Attempt to share any rule with the newly created user. Current Behavior: - The new user is missing from the dropdown selection list. Cause: - The domain on the user selection field filters based on explicitly assigned groups (using group_ids for "Own Timesheets" access). Users with higher-level access, such as "All Timesheets" or "Timesheets Admin", have this access implied rather than explicitly assigned, meaning it only registers in `all_group_ids`. Fix: - Update the field domain to evaluate `all_group_ids` instead of `group_ids`. This ensures users with implied group access are correctly populated in the dropdown list. task-6236300 Forward-Port-Of: odoo/enterprise#117984
This update optimizes the timesheet grid by preventing unnecessary reloading of the entire form when you switch focus between the timer and other fields. This results in a smoother, faster experience for users entering and editing their timesheets. It’s a small but important improvement for efficiency.
Original PR description
This PR prevents re-rendering the whole systray form view when focusing in and out of the timer field. We instead handle the focus in the widget, ensuring only the field itself re-renders. Task-6251180 Forward-Port-Of: odoo/enterprise#118820 Forward-Port-Of: odoo/enterprise#118524
This update fixes an issue where the ICP export generated inconsistent XML reports by using values from multiple company contexts. The change ensures a single, reliable company context is used, improving the accuracy and clarity of the exported data. This resolves potential confusion and ensures data integrity for reporting.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#119549 Forward-Port-Of: odoo/enterprise#112995
This update fixes an issue where online orders with tax included were incorrectly calculating prices. The fix ensures that the unit price and total price accurately reflect the tax amount, providing correct order totals for UrbanPiper integrations. This improves the accuracy of online sales transactions.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#119587 Forward-Port-Of: odoo/enterprise#92854
This update ensures that plugins used within the Odoo Sign service are correctly set up as services. This improves the stability and reliability of the sign request process, preventing potential errors and ensuring a smoother user experience for customers.
This update resolves minor issues impacting payroll calculations for Philippine employees. Specifically, it corrects data group assignments and ensures accurate display of payroll information, improving the reliability of payroll processing. The changes also align with testing requirements for data updates.
Original PR description
- Fixes a small issue with the computation of the amounts, by updating the compute dependencies and following the parent view example of using force_save on the fields. - Correct the invisible condition on the rate fields to properly hide the column itself and not its content. - Correct the group set on the daily wage field of the employee model, which should be the payroll user group and not the hr user group - As required by test_hr_payroll_data_updatable, update the salary structure to not be no-update.
Code cleanup and technical improvements
This update simplifies the configuration of UOM views across various Odoo modules by renaming XML IDs. This change eliminates potential confusion between UOM and product UOM views, ensuring a cleaner and more consistent system. It’s a routine maintenance update to improve internal development processes.
Original PR description
This PR renames `uom.uom` xml ids to remove existing confusion with `product.uom` views and to match naming conventions. Community PR: https://github.com/odoo/odoo/pull/262588 Upgrade PR: https://github.com/odoo/upgrade/pull/10183 Task-6148914
7 changes
Resolved issues and error corrections
This update resolves an issue where uploading fillable PDFs with blank fields resulted in an error. The fix prevents a technical error (IndexError) that occurred when generating PDFs with no data, ensuring that all PDF generation processes now function correctly regardless of form field content.
Original PR description
Version: 19.0 Issue: - Uploading a fillable PDF with no filled-in values caused an error. Cause: - When all form fields are empty, nothing is drawn on the ReportLab overlay canvas, producing a 0-page PDF. - Calling getPage(0) on an empty page list raised an IndexError. Fix: - Skip the page merge when the overlay has no pages to avoid the IndexError on empty fillable forms.
This update fixes an issue where the activity rate used for payroll calculations was incorrectly tied to individual employees instead of the Odoo Enterprise version. This ensures consistent and accurate payroll processing across all users of the system, aligning with the correct version-based configuration. The change improves payroll accuracy and reduces potential discrepancies.
Original PR description
…ployee Forward-Port-Of: odoo/enterprise#119658
This update fixes an issue where credit limit warnings were incorrectly triggered when customers received bank payments. The system now accurately considers outstanding bank payments in its calculations, ensuring warnings only appear when the credit limit is genuinely exceeded. This improves the accuracy of credit risk management.
Original PR description
Before this fix: The credit limit warning calculation only considered credit notes but ignored outstanding bank payments when computing the partner's effective outstanding balance. For example, if a…
Before this fix: The credit limit warning calculation only considered credit notes but ignored outstanding bank payments when computing the partner's effective outstanding balance. For example, if a customer had a credit limit of 1,000 and an invoice of 2,000 was created, then a bank payment of 1,500 was received, the warning would still incorrectly appear showing the customer exceeded their limit (2,000 > 1,000), even though the actual outstanding amount was only 500. After this fix: The credit limit warning now properly includes outstanding bank payments in the calculation. Two cases are handled: - Bank payments received but not yet matched to any invoice, these are identified by their open suspense account entry and deducted from the partner's outstanding exposure. - Bank payments already matched to the invoice, the reconciled amount is read from the invoice's receivable line and deducted accordingly. So with this fix, after a 1,500 bank payment, the system correctly recognises the outstanding amount as 500 and does not show a warning since it is within the 1,000 credit limit. task-5427613 Forward-Port-Of: odoo/enterprise#119691 Forward-Port-Of: odoo/enterprise#118957
This update resolves an issue where the commission report displayed empty groups when linked to inactive commission plans. By excluding these plans from the report's initial data processing, the report now accurately shows populated groups, providing a cleaner and more reliable view of commission achievements. This ensures sales teams have accurate data for their performance analysis.
Original PR description
Steps to reproduce: 1. create a commission plan 2. invoice an SO with the linked salesperson to the plan to progress towards the target 3. Archive the commission plan 4. Go to Sales > Commissions > Commissions 5. Remove all filters The `sale.commission.report` includes empty groups for `sale.commission.achievement.report` that are linked to inactive commission plans By excluding said plans from the initial join, the report would display populated groups only without the clutter. opw-6177132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#119695 Forward-Port-Of: odoo/enterprise#117615
This update resolves a crash in the payslip PDF report that occurred when employees didn't have a bank account configured. The fix adds a conditional check to the report template, preventing it from attempting to access bank account information when it's not applicable. This ensures the report consistently generates without errors.
Original PR description
The payslip PDF report crashed when the employee had no bank account configured because the template tried to access bank_account_ids[0] unconditionally. Add a t-if guard on the bank account div to only render it when the employee has at least one bank account linked.
This update ensures that DATEV customer and supplier export files accurately reflect customer information. Previously, non-EU customers (like those in Switzerland) incorrectly included EU-specific fields. Now, the system correctly uses the customer's country code in the 'Land' field, aligning with DATEV's requirements and improving data accuracy for reporting.
Original PR description
### Issue: In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled However, these fields must only be used for EU countries…
### Issue: In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled However, these fields must only be used for EU countries For non-EU countries, the `Land` field should be filled instead, and is required whenever the country is not Germany https://developer.datev.de/en/file-format/details/datev-format/format-description/debitorskreditors ### Cause: `_l10n_de_datev_get_partner_list` did not distinguish between EU and non-EU countries As a result, any partner with a VAT number could populate `EU-Land` and `EU-UStID`, even if the country was outside the EU Greece also requires a special case: its VAT prefix is `EL` so the `EU-Land` too, while the country code used in `Land` must remain `GR` ### Steps to reproduce: - Install `l10n_de_reports` and switch to the DE company - Create a customer in Switzerland with a valid VAT number - Create and confirm an invoice for that customer - Go to Accounting → Audit Reports → General Ledger - Select the full year - From the gear menu, export DATEV DATA (zip) - Open the `EXTF_customer_accounts` file ### Before the fix: `EU-Land` and `EU-UStID` are filled for the Swiss customer, while `Land` is empty ### After the fix: `EU-Land` and `EU-UStID` are empty for non-EU countries such as Switzerland, while `Land` is correctly filled `Land` is filled using the following priority: 1. Partner country_code 2. Country extracted from the VAT number 3. Empty opw-5902565 Forward-Port-Of: odoo/enterprise#119593 Forward-Port-Of: odoo/enterprise#113835
This update resolves a minor issue where the displayed name for the Sendcloud website delivery module had a typo ("Sendcould"). All other references within the system use the correct spelling. This ensures consistent and accurate module identification.
Original PR description
The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary.
opw-6239003
Forward-Port-Of: odoo/enterprise#118416
Forward-Port-Of: odoo/enterprise#1182236 changes
Enhancements to existing features
This update includes necessary payment fields for Saltedge, enabling the processing of payments through this payment gateway. This change supports a key integration with Saltedge, improving payment processing capabilities. It's a necessary step to fulfill Saltedge payment requirements.
Original PR description
In order to be able to initiate payments using Saltedge we need to include a couple more fields in our payload. This commit adds them. Task ID: 6095729
Resolved issues and error corrections
This update fixes a bug that occurred when multiple 'phantom' Bills of Materials (BOMs) were associated with a product. Previously, updating a sales order would cause an error due to conflicting BOM selections. Now, the system automatically chooses the BOM with the highest priority (lowest sequence number), ensuring consistent and reliable sales order processing, particularly for kit-type products.
Original PR description
When multiple phantom BOMs existed for a product or template, the system attempted to use all matches, leading to a singleton error on sales order update. This fix ensures only the BOM with the…
When multiple phantom BOMs existed for a product or template, the system attempted to use all matches, leading to a singleton error on sales order update. This fix ensures only the BOM with the lowest sequence is selected, resolving the ambiguity. Closes #202645 Description of the issue/feature this PR addresses: Multiple phantom BOMs for a product or its template caused a singleton error during Sales Order updates. The system failed to correctly choose one BOM when more than one matched the criteria. Current behavior before PR: If a product had more than one phantom BOM (same type), confirming or updating a Sales Order line triggered a traceback error due to multiple BOMs being selected at once. Desired behavior after PR is merged: Only the BOM with the lowest sequence (highest priority) is selected, avoiding the singleton error and ensuring consistent behavior when handling Sales Orders with kit-type products. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when confirming purchase orders without a linked warehouse. The fix prevents a technical issue (a 'TypeError') from stopping the order confirmation process. It ensures the system correctly handles scenarios where a delivery location hasn't been set up, improving the reliability of purchase order processing.
Original PR description
When confirming a purchase order whose Deliver To operation type is not linked to any warehouse, a traceback is raised. Steps to reproduce the error: - Install ``purchase_stock`` module with demo…
When confirming a purchase order whose Deliver To operation type is not linked to any warehouse, a traceback is raised. Steps to reproduce the error: - Install ``purchase_stock`` module with demo data - Go to Inventory > Configuration > Settings > Enable Storage Locations - Create a new warehouse > add Short Name > save - Go to Inventory > Configurations > Operations Types > Open the receipts linked to the new warehouse > Unset the warehouse > Save - Create a Purchase order > Deliver To: select the above operation type > Add a product > Confirm Order Traceback: ```py TypeError: startswith first arg must be str or a tuple of str, not bool ``` https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/purchase_stock/models/purchase_order.py#L251-L255 When the warehouse is unset on the operation type, ``wh_stock_loc`` becomes an empty recordset. The method then calls ``_child_of(wh_stock_loc)``, which eventually evaluates ``other_location.parent_path`` inside ``startswith()``. Since ``other_location`` is empty, ``parent_path`` is ``False``, causing the traceback. https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/stock/models/stock_location.py#L457-L459 sentry-7529159473 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows businesses to set a configurable annual late payment penalty rate for French Electronic Invoicing (UBL) exports. When this rate isn't defined, the system automatically includes a standard note (PMD) based on ECB rates, ensuring compliance with French regulations. Updated tests and documentation support this new functionality.
Original PR description
## Summary - Add company-level `l10n_fr_pdp_late_payment_penalty_rate` (settings: French Electronic Invoicing). - Export a dynamic **#PMD#** note on outbound UBL FR invoices and credit notes (legal…
## Summary - Add company-level `l10n_fr_pdp_late_payment_penalty_rate` (settings: French Electronic Invoicing). - Export a dynamic **#PMD#** note on outbound UBL FR invoices and credit notes (legal default when rate is empty). - Extend `l10n_fr_pdp` tests (messages + UBL golden files). Fixes odoo/odoo#268149 ## Multi-repo issues | Repository | Issue | Branch | |------------|-------|--------| | odoo/odoo | #268149 | `dev_l10n_fr_pdp_pmd_penalty_rate` | ## Test plan - [ ] `-u l10n_fr_pdp --test-enable --stop-after-init --test-tags=/l10n_fr_pdp:TestL10nFrPdpXml` ## Reviewers & code owners - Requested review: @smetl @chklop - Prior authors on touched `l10n_fr_pdp` code: @baje @videc @sveaw (recent commits on `account_move`, `res.company`, tests) --- ## Résumé - Taux annuel `l10n_fr_pdp_late_payment_penalty_rate` sur la société (paramètres FE). - Note **#PMD#** dynamique sur factures / avoirs UBL FR exportés. - Tests `l10n_fr_pdp` mis à jour. Fixes odoo/odoo#268149 ## Tests - [ ] `--test-tags=/l10n_fr_pdp:TestL10nFrPdpXml` ## Revue - Review : @smetl @chklop - Auteurs récents du code modifié : @baje @videc @sveaw
This update resolves a test failure caused by incorrectly formatted data being passed to the system. Specifically, raw PDF content was mistakenly treated as base64, leading to an error. This fix ensures data is properly encoded, improving test reliability.
Original PR description
This commit fixes an error when running the `test_employee_job_change` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw PDF content was being passed when a base64 representation was actually expected (which is obviously invalid base64). runbot-938173 Forward-Port-Of: odoo/enterprise#118523
This update resolves a warning message appearing in the Point of Sale interface when editing partner records. The fix adds a placeholder component to load missing widgets, ensuring the POS functionality remains stable and reliable. This prevents potential disruptions for users.
Original PR description
Step to produce: - open pos, from partner list, open any partner record to edit Observation: - we get warning like `Missing widget: x2many_buttons for field of type many2many` in console Cause: - we do not load all the web assest in pos, hence this widgets are not loaded in registry in pos asset Fix: - we add a placeholder "DefaultField" for such missing widgets Note: - this was faced, in runbot, as it didn;'t pass the it with those warning when working on https://github.com/odoo/enterprise/pull/117527 https://runbot.odoo.com/runbot/batch/2534508/build/111089589 <img width="945" height="337" alt="image" src="https://github.com/user-attachments/assets/72ca2857-5ea6-4a64-9900-6012518f1047" /> opw-6198035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This update resolves a technical issue preventing users from confirming DHL deliveries when the scheduled date was missing or in the past. The system now automatically sets the delivery date to one hour in the future, eliminating the error and ensuring successful order confirmation.
Original PR description
When confirming the delivery of an order using DHL shipping method we get an error that the date must be in the future. This happens when the scheduled date was not set, or set for a time in the past. This commit automatically sets the time to 1 hour in the future and bypasses the user error. opw-6148927