Daily updates from Odoo
Navigate
Branch
Wednesday, April 8, 2026
199 changes
13 changes
Resolved issues and error corrections
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which team they were linked to. Now, the website only shows articles connected to the specific helpdesk team, improving the user experience and ensuring relevant information is presented. This change was driven by a bug fix (opw-5913355).
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves a crash issue that occurred when opening Gantt views on days with Daylight Saving Time transitions. Specifically, the change addresses a calculation error related to time zones, preventing the Gantt view from freezing during these transitions. This ensures a more reliable experience for users across different time zones.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view. Forward-Port-Of: odoo/enterprise#112840
This update resolves an error that occurred during the registration of super payments in the Australian payroll system. By initializing the error message to an empty string, the system now correctly handles data and avoids returning NULL values. Associated tests have been added to ensure this fix is reliable.
Original PR description
. Initialize the error message with an empty string to avoid returning NULL. . Add corresponding tests task-6091444 Forward-Port-Of: odoo/enterprise#112930
This update ensures that account moves are automatically created when closing a POS session containing Urban Piper future orders (orders with a delivery date). Previously, these orders were excluded, preventing proper accounting record generation. This change improves financial reporting accuracy for orders processed through the Urban Piper integration.
Original PR description
Before this commit, when all orders coming from Urban Piper in a POS session are paid future orders (i.e. have a delivery_datetime), closing the session would not generate an account move. The cause was that the code was excluding future orders when creating the account move. The fix is to exclude only unpaid orders instead. How to reproduce: - Set up Urban Piper (a test account needed). - Place an order from the Urban Piper platform. - Receive the order, accept it, and mark it as ready. - Close the session. - The session will not have an account move. opw-5995985 Forward-Port-Of: odoo/enterprise#113078 Forward-Port-Of: odoo/enterprise#111137
This update fixes an issue where chart links didn't correctly direct users to the appropriate view for each data source (e.g., a list view for a list datasource). Previously, users were directed to a default action view, which was confusing. This change ensures links within charts now consistently navigate to the correct data source view type.
Original PR description
Currently, if the user clicks on a datasource link (inside a chart) they will be directed to the default view of the action realted to the datasource model but it will not go to the corresponding type of view (e.g. a list datasource should direct to a list view). Task-5957004 Forward-Port-Of: odoo/enterprise#108158
This update fixes an issue related to how dates and times are displayed, specifically the inclusion of seconds. The change restores the original behavior of showing seconds when requested, and clarifies the datetime format system. This ensures consistent and accurate time representation across the Odoo Enterprise platform.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo/odoo@062b140 opw-6030342 Forward-Port-Of: odoo/enterprise#112505
This update resolves an issue where the system incorrectly identified employees as eligible for late hours reporting when they hadn't recorded a check-in time. The fix ensures that late hours visibility is only calculated for employees with a valid check-in record, preventing errors and improving data accuracy.
Original PR description
_compute_l10n_sa_late_hours_visible, calling min() on the mapped check_in values and then .date() would crash with an AttributeError when check_in is False (e.g. during an onchange triggered by clearing the check_in field in the form view). Filter out records without a check_in before computing the date range, and mark them as not visible since late hours cannot apply without a check-in time. task-6067640 Forward-Port-Of: odoo/enterprise#111935
This update fixes an issue where users couldn't validate delivery orders when using the 'To Pickup' button. The fix removes a technical restriction that prevented opening the form view from the list, now enabling users to properly complete the delivery order process. This improves efficiency and accuracy in order fulfillment.
Original PR description
Steps to reproduce: - Install `industry_fsm_stock` - Create a task and add a product - Click on the "Sale Order" button - Add another product with the Invoicing Policy set to "Delivered quantities" - Click on the "To Pickup" button Issue: Users are unable to validate the delivery order from the products pick up button. Cause: In pr https://github.com/odoo/odoo/pull/227630 the parent view is set with `editable="bottom"`, which prevents opening the form view from the list. Fix: Allow opening the form view from the list view so users can validate the delivery order. Task-5969303 Forward-Port-Of: odoo/enterprise#110125
This change adjusts the VAT number used in the 'L10nThaiTaxReportTest' test case to align with recent updates in how companies and individuals are created within the Odoo system. This ensures the reports accurately reflect current Thai tax regulations and avoids potential discrepancies.
Original PR description
in this commit:- - We're changing partner's vat in 'L10nThaiTaxReportTest' and adopting new vat as per new way of creating company and individual. as `branch name` is depend upon 'is_company'. - see https://github.com/odoo/odoo/commit/f6e431c813787958897526a4d6570124048b428a task-6002111 Forward-Port-Of: odoo/enterprise#112434
This update corrects a bug where discounts were applied twice to service tasks, resulting in incorrect pricing. The fix ensures discounts are applied correctly based on sales order settings, preventing overcharging and improving accuracy for service order calculations. This impacts how discounts are applied to field service tasks.
Original PR description
Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service. <h2>Steps to produce:</h2> * Install `industry_fsm_sale` and enable…
Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service. <h2>Steps to produce:</h2> * Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings. * Create a pricelist with a price rule of type discount that applies 10 percent discount to every product. * Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist. * Go to Field Service > Create a Task, and set `Customer` to Acme Corporation. * Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order <h2>Observed behavior:</h2> The discount is applied twice to the product on SO: **Product**: Service on Timesheets **Unit Price**: `$40` (excluding tax) **First discount:** The 10 percent discount on the unit price of the product. Product unit price is set from `$40 -> $36 ` **Second discount:** The 10 percent discount on the SO line itself. `$36 -> $32.4 ` The untaxed amount is: `$32.40` which should be `$36.00` <h2>Root cause:</h2> This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice. <h2>Solution:</h2> When creating the sales order: * **Discount setting is on:** use list price so the discount is applied from the sales order. * **Discount setting is off:** set the product unit price to the discounted price. [1]- https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 [2]- https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788 opw-5432088 Forward-Port-Of: odoo/enterprise#112948 Forward-Port-Of: odoo/enterprise#103950
This update resolves an issue where the breadcrumb navigation within the Barcode app was sometimes showing blank entries instead of the originating document's name. Now, when navigating from Barcode actions to related records, the breadcrumb correctly displays the document name, improving user clarity and ease of navigation. This ensures users can quickly identify the source document when working within the Barcode interface.
Original PR description
*: stock_barcode_mrp, stock_barcode_picking_batch ## Issue Before This PR: When navigating from the Barcode client action (e.g. picking, inventory, etc.) to related form views (such as lot, product,…
*: stock_barcode_mrp, stock_barcode_picking_batch
## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.
## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
- Delivery Orders.
- Manufacturing Orders
- Batch Pickings
- Inventory Count
- From any of these open a record
(e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.
## Cause of the Issue:
- When switching views inside the Barcode client action,
the FormController calls `setDisplayName(this.displayName())`.
In some cases, this returns an empty string, overwriting the
previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
preventing the controller from retrieving a proper name.
## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.
TaskID: 4978997
Forward-Port-Of: odoo/enterprise#112988
Forward-Port-Of: odoo/enterprise#99165This update fixes a layout issue in the Italian Libro Giornale PDF report. When accounts with long names are used, the report's formatting was broken, causing excessive column expansion and gaps. The fix adds a CSS class to handle these long account names, resulting in a cleaner and more readable PDF report.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103 Forward-Port-Of: odoo/enterprise#112743
This update corrects a technical issue that prevented users from accessing the timesheet assistant. A duplicate file was identified and removed during the update process, resolving an error related to duplicate keys within the configuration. This ensures a smoother experience for users managing their timesheets.
Original PR description
In PR: https://github.com/odoo/enterprise/pull/108360/changes `aw_local_config.js` was replaced by `frequency_viewer_local_config.js` but in the Forward from saas-19.1 to saas-19.2, both files were maintained https://github.com/odoo/enterprise/commit/3ced9cf68affd973c570e92627361cd0db8eb518
13 changes
Resolved issues and error corrections
This update adjusts the VAT number used in the 'L10nThaiTaxReportTest' test case to align with recent changes in how companies and individuals are created within Odoo. This ensures accurate reporting for Thai tax purposes and maintains consistency with updated business processes.
Original PR description
in this commit:- - We're changing partner's vat in 'L10nThaiTaxReportTest' and adopting new vat as per new way of creating company and individual. as `branch name` is depend upon 'is_company'. - see https://github.com/odoo/odoo/commit/f6e431c813787958897526a4d6570124048b428a task-6002111
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which team the helpdesk was associated with. Now, the website only shows articles linked to the specific helpdesk team or its related teams, improving the user experience and ensuring relevant information is presented.
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves a technical issue preventing the accurate registration of super payments in the Australian payroll system. The fix initializes an error message to avoid returning NULL values, ensuring data integrity. New tests have been added to verify the corrected functionality.
Original PR description
. Initialize the error message with an empty string to avoid returning NULL. . Add corresponding tests task-6091444 Forward-Port-Of: odoo/enterprise#112930
This update resolves a crash in the Gantt view that occurred when opening the view on days with Daylight Saving Time transitions. The fix addresses an issue where incorrect time calculations led to a data error, preventing users from accessing the Gantt chart. This ensures the Gantt view remains stable across different time zones.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view. Forward-Port-Of: odoo/enterprise#112840
This update resolves a technical issue in the UrbanPiper Test Order wizard where clicking an 'open product' icon caused a system error. The fix disables the product form opening functionality within this specific wizard, preventing the error and improving stability. This ensures the test order process functions correctly.
Original PR description
Steps to Reproduce ---------- - Make an UrbanPiper Test Order - Select a product - Click the external-link (open) icon - POS traceback appears Issue ----------- Clicking the “open product” icon triggered a traceback because the POS attempted to load the missing hr_expense_product_form view. Fix -------------- Disable form open/create for the product field to remove the quick-open product icon, as there is no need to open the product form from this wizard. Task-6089707
This update fixes an issue related to how dates and times are displayed in the Enterprise version of Odoo. The system now correctly shows seconds when requested, and previously hidden formatting options have been removed for clarity. This ensures consistent and accurate time representation across the application.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo/odoo@062b140 opw-6030342 Forward-Port-Of: odoo/enterprise#112505
This update resolves an issue where manufacturing orders weren't correctly incorporating component variants during intercompany purchases. The fix ensures that the correct variant information is retrieved from the purchase order, allowing for accurate production scheduling and fulfilling intercompany transactions properly. This improves the reliability of intercompany order fulfillment.
Original PR description
In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost. Steps to reproduce: ------------------- * Enable intercompany transaction * Enable variant…
In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost.
Steps to reproduce:
-------------------
* Enable intercompany transaction
* Enable variant grid entry
* Enable multistep routes
* Unarchive MTO
* Settings>Users & Companies>Companies
* Enable Generate Sales Orders in company A
* Create a product:
- Never variant with at least two values
- MTO and manufacture
* Create a bom,
- Company : company B
- Add a component with apply on variant: choose one of the variants
* Create and confirm a purchase order, for a never variant of the product, in company A with vendor as company B
* Confirm the sales order in company B
-> The manufacture order does not include the components that are applied on variant
Observation:
-------------
When creating a sale order for an intercompany rule, button_approve is overwritten and it calls the function "inter_company_create_sale_order.
That function will create the sale order from the data of the purchase order:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
When preparing the value for each order line, the attribute value for the never variant will not be retrieved:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
Since the attribute value is lost, it will not be retrived by the mto since it should get the value from the PO.
opw-5438723
Forward-Port-Of: odoo/enterprise#107122This update fixes an issue where users couldn't validate delivery orders when using the 'To Pickup' button in the industry_fsm_stock module. The fix removes a technical restriction that prevented the form view from opening, now enabling users to properly complete the delivery order process.
Original PR description
Steps to reproduce: - Install `industry_fsm_stock` - Create a task and add a product - Click on the "Sale Order" button - Add another product with the Invoicing Policy set to "Delivered quantities" - Click on the "To Pickup" button Issue: Users are unable to validate the delivery order from the products pick up button. Cause: In pr https://github.com/odoo/odoo/pull/227630 the parent view is set with `editable="bottom"`, which prevents opening the form view from the list. Fix: Allow opening the form view from the list view so users can validate the delivery order. Task-5969303 Forward-Port-Of: odoo/enterprise#110125
This update resolves a display issue in the Danish balance sheet and profit & loss reports. The changes simplify the report format by using account names directly, and ensure accurate Danish translations for both the report and its English counterpart. This improves the clarity and usability of financial reports for Danish users.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#113097 Forward-Port-Of: odoo/enterprise#112430
This update fixes an issue where rental order confirmations didn't properly update the shift status in Planning. Now, shifts are automatically marked as 'published' when a rental order is created, ensuring accurate status tracking. Additionally, access to certain buttons has been restricted for users without sales permissions to prevent access errors.
Original PR description
sale_renting_planning: fix shift state after creating rental order -------- **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in…
sale_renting_planning: fix shift state after creating rental order -------- **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in Planning it is still in draft. **Issue:** The shift stays in draft even after the rental order is confirmed. **Cause** When creating a rental order from a shift, the shift is not marked as planned. It only gets linked to the order after saving, so it never updates its status. **Fix:** Mark the shift as published when confirming a new rental order. This makes the shift show the correct status right away and keeps it consistent with the “Add to Last Order” button. sale_renting_planning: fix access error on clicking new order button ---------------- steps to reproduce: user has no sale access (only planning access) create a new shift click on 'New Order' or 'ADD to Last Order' button access error occurs cause: the 'New Order' and 'Add to Last Order' buttons were visible to users without sales access rights. issue: The buttons open the sale order form view, but users without sales access cannot read sale orders data, resulting in access errors. fix: Hide both buttons for users who do not have sale access rights. task-5075839 Forward-Port-Of: odoo/enterprise#112373 Forward-Port-Of: odoo/enterprise#99642
This update corrects a test within the Odoo Enterprise web_studio module to reflect a recent change in the user interface label for a text formatting option. Specifically, the test now correctly identifies the new label 'Select text style' instead of the previous 'Select font style'. This ensures the test accurately validates the functionality after the label update.
Original PR description
#### Description of the change: - Update the expected test string from "Select font style" to "Select text style" after the label change. community-https://github.com/odoo/odoo/pull/236904 task-5155813
This update resolves an issue where the breadcrumb navigation within the Barcode app was sometimes showing a blank entry instead of the originating document's name. Now, when navigating from Barcode actions to related records, the breadcrumb correctly displays the document name, improving user clarity and ease of navigation. This ensures users can quickly understand the context of their work.
Original PR description
*: stock_barcode_mrp, stock_barcode_picking_batch ## Issue Before This PR: When navigating from the Barcode client action (e.g. picking, inventory, etc.) to related form views (such as lot, product,…
*: stock_barcode_mrp, stock_barcode_picking_batch
## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.
## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
- Delivery Orders.
- Manufacturing Orders
- Batch Pickings
- Inventory Count
- From any of these open a record
(e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.
## Cause of the Issue:
- When switching views inside the Barcode client action,
the FormController calls `setDisplayName(this.displayName())`.
In some cases, this returns an empty string, overwriting the
previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
preventing the controller from retrieving a proper name.
## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.
TaskID: 4978997
Forward-Port-Of: odoo/enterprise#112988
Forward-Port-Of: odoo/enterprise#99165This update fixes a layout issue in the Italian Libro Giornale PDF report. When accounts with long names are used, the report's formatting was broken, causing excessive column expansion and gaps. The fix adds a CSS class to handle long account names, resulting in a cleaner and more readable report.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103 Forward-Port-Of: odoo/enterprise#112743
5 changes
Resolved issues and error corrections
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which team they were linked to. Now, the website only shows articles connected to the specific helpdesk team, improving the user experience and ensuring relevant information is presented. This change was driven by a bug fix (opw-5913355).
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves an issue where the breadcrumb navigation within the Barcode app was sometimes displaying incorrect or blank entries when moving between related records. Now, the breadcrumb correctly displays the name of the originating document, making it easier for users to track their workflow and understand where they are within the system.
Original PR description
*: stock_barcode_mrp, stock_barcode_picking_batch ## Issue Before This PR: When navigating from the Barcode client action (e.g. picking, inventory, etc.) to related form views (such as lot, product,…
*: stock_barcode_mrp, stock_barcode_picking_batch
## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.
## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
- Delivery Orders.
- Manufacturing Orders
- Batch Pickings
- Inventory Count
- From any of these open a record
(e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.
## Cause of the Issue:
- When switching views inside the Barcode client action,
the FormController calls `setDisplayName(this.displayName())`.
In some cases, this returns an empty string, overwriting the
previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
preventing the controller from retrieving a proper name.
## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.
TaskID: 4978997
Forward-Port-Of: odoo/enterprise#99165This update resolves a crash in the Gantt chart view that occurred when opening the chart on Daylight Saving Time (DST) transition days. The issue stemmed from a calculation error related to time zone differences, specifically impacting users in locations like Beirut. This change ensures the Gantt chart remains stable and functional across all time zones.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view. Forward-Port-Of: odoo/enterprise#112840
This update fixes an issue preventing users from editing their Amazon fulfillment channel settings. The previous display used a read-only widget, blocking changes. Now, the channel is displayed correctly, allowing users to manage their Amazon fulfillment options as intended.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended. Forward-Port-Of: odoo/enterprise#112866
This update fixes an issue where the Libro Giornale (IT) PDF report would break its layout when an account with a long name was used. By adding a CSS class, the column width is now properly controlled, preventing excessive expansion and ensuring a clean, readable report. This improves the user experience for generating financial reports.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103 Forward-Port-Of: odoo/enterprise#112743
16 changes
Resolved issues and error corrections
This update fixes a technical issue preventing users from opening the 'Split Production' view within the MRP module. The problem stemmed from a missing product unit of measure, causing an error. This change ensures the view opens correctly and reliably for all users.
Original PR description
Steps to reproduce: - Install `mrp` module - Active debugger > Open view - Open `Split Production` view Traceback: `AssertionError: precision_rounding must be positive, got 0.0 (saas-18.3) ` `ValueError: Expected singleton: uom.uom() (19.0)` When trying to open the view directly, we do not receive the `product_uom_id` from the wizard in compute method `_compute_num_splits`, which leads to an error. sentry-7379431482
This update resolves a problem where tours weren't running correctly after editing views in Studio. The issue stemmed from a misleading module entry ('studio_customization') being included in the tour process. This fix filters out these invalid entries to ensure tours function reliably.
Original PR description
Step to reproduce: - start a fresh db, install studio and pos - using studio, edit any view (add or remove a field) - run any tour Observation: - we are not able to run any tour Traceback ``` File…
Step to reproduce:
- start a fresh db, install studio and pos
- using studio, edit any view (add or remove a field)
- run any tour
Observation:
- we are not able to run any tour Traceback
```
File "/home/odoo/odoo/codebase/odoo/18.0/odoo/addons/base/models/ir_qweb.py", line 2703, in _get_lazy_bundles_from_js
for fname in glob.iglob('**/static/src/**/*.js', root_dir=modroot, recursive=True):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/glob.py", line 46, in iglob
root_dir = os.fspath(root_dir)
^^^^^^^^^^^^^^^^^^^
TypeError: expected str, bytes or os.PathLike object, not bool
```
Cause:
- `_get_lazy_bundles_from_js` fetches module path for all installed module in addons
https://github.com/odoo/odoo/blob/05d0944a7640e196db989039140ae5ddb12152ac/odoo/addons/base/models/ir_qweb.py#L2686-L2697
- in case we have a view edited, we get the `studio_customization` as installled module, which doesn't have any path in addons. i.e. False
Fix:
- filter out such pseudo-modules from the list
Note: this is not a reported issue, i stumbled across it, hence made a fix
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257806This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which team the helpdesk was associated with. Now, the website only shows articles linked to the specific helpdesk team or its related teams, improving the user experience and ensuring relevant information is presented.
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves an issue where the breadcrumb navigation within the Barcode app was displaying incorrect or blank entries when moving between related records. Now, users can easily identify the originating document when navigating from the Barcode interface, improving usability and reducing confusion.
Original PR description
*: stock_barcode_mrp, stock_barcode_picking_batch ## Issue Before This PR: When navigating from the Barcode client action (e.g. picking, inventory, etc.) to related form views (such as lot, product,…
*: stock_barcode_mrp, stock_barcode_picking_batch
## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.
## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
- Delivery Orders.
- Manufacturing Orders
- Batch Pickings
- Inventory Count
- From any of these open a record
(e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.
## Cause of the Issue:
- When switching views inside the Barcode client action,
the FormController calls `setDisplayName(this.displayName())`.
In some cases, this returns an empty string, overwriting the
previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
preventing the controller from retrieving a proper name.
## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.
TaskID: 4978997
Forward-Port-Of: odoo/enterprise#99165This update resolves a crash in the Gantt chart view that occurred when opening the chart on days with Daylight Saving Time transitions. The fix addresses an issue where incorrect time calculations led to a data error, causing the chart to malfunction. This ensures the Gantt chart remains stable across different time zones.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view. Forward-Port-Of: odoo/enterprise#112840
The search panel was displaying an error message when dealing with large datasets. This update adds a filter to limit the number of results shown, resolving the 'Too many items to display' error and ensuring a smoother user experience when searching for partners. This improves the usability of the search functionality.
Original PR description
Have a search view with searchpanel having a filter or a category with a limit. For exemple in sale.order:
```
<searchpanel>
<field name="partner_id" icon="fa-filter" groupby="parent_id" limit="80" enable_counters="True"/>
</searchpanel>
```
On a database with a lot of data, in the category partner of search panel, there is an error 'Too many items to display.'.
Now in the search view, add a filter to restrict the number of records, and hence the number of partners in the search panel below the limit.
Before this commit, the error was still displayed. Now, it isn't, and the data are properly displayed.
Closes #257749
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#257908
Forward-Port-Of: odoo/odoo#257821This update ensures the category selector in Point of Sale displays consistently across all devices and user experiences. Previously, styling was inconsistent due to conditional application, now both product and category lists are always styled, improving the user interface and overall presentation.
Original PR description
Before this commit: ==================== Previously, the `category-list` class was conditionally applied based on `show_category_images`, which caused inconsistent styling and layout issues. After this commit: ======================= This commit ensures that both `product-list` and `category-list` classes are always present, providing consistent rendering of the category selector. Task-6092404 Forward-Port-Of: odoo/odoo#257251
This update resolves an issue where the invoice generation process would fail if a tax wasn't properly configured on an invoice line. The fix adds a check to prevent the system from attempting to calculate tax when none is defined, ensuring invoices are generated correctly. This improves invoice accuracy and prevents potential errors.
Original PR description
Issue: Attempting to generate facturae document for an invoice without a tax set on one or more line resulted in an IndexError. Solution: adding a check that prevents the function from trying to build tax values when there is no tax on the line. task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256819
This update corrects a flaw in how the digest KPI calculates user connections. Previously, it only considered a user's default company, leading to inaccurate metrics. Now, it correctly accounts for users working across multiple companies, providing a more reliable view of connected users.
Original PR description
**Problem:** Currently, the digest KPI for connected users checks the "company_id" field (as with all other models), but this field corresponds to "Default Company" on res.users, meaning a user can only be considered for one company when computing the digest KPI. This can cause misleading digest KPIs if users work in multiple companies, or mainly in a company that isn't their default company. **Solution:** Instead of always using the "company_id" field, we use the "company_ids" field if present on the model. opw-5404940 Forward-Port-Of: odoo/odoo#247806
This update addresses a situation where outdated, zero-value account entries were sometimes created, causing potential issues. The fix allows users to remove these entries, streamlining account management and improving data accuracy. This change ensures a cleaner and more efficient accounting process.
Original PR description
-added some conditions to allow the user to remove some zero move lines as they may have been created and do not have good information. task-4590580 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#256369 Forward-Port-Of: odoo/odoo#202272
This update ensures that the milestone list view, regardless of whether it's accessed from the Kanban or top bar, displays all relevant sales-related information like 'Quantity (%)'. Previously, the top bar action used a simplified view, leading to incomplete data. This change standardizes the view for a more complete and accurate representation of project milestones.
Original PR description
Steps to reproduce: - 1. Install the sale_project module. 2. Open a project and ensure it is billable. 3. Compare the view opened from the "Milestones" link in the Kanban view with the view opened from the "Milestones" top bar action. Issue: - The milestone list view opened from the top bar action does not display sales-related fields (e.g., "Quantity (%)"). Cause: - The Kanban view calls the `action_get_list_view` python method, which is overridden in sale_project to add a custom list view including sales-related fields. The top bar action was using a static XML action, bypassing this python logic. Fix: - Update the Milestones embedded actions to call the `action_get_list_view` python method instead of using a static XML action, ensuring top bar uses the same view as others. task-5993183
This update corrects a bug in the reconciliation process within Odoo. Previously, creating a reconciliation model without specifying a partner or account would default to a liquidity account, causing errors. Now, the system requires either a partner or account to be set, ensuring accurate reconciliation reporting.
Original PR description
**Steps to reproduce:** - Go to Accounting dashboard - From Bank journal, open Reconciliation Models list - Create a new reconciliation model - Add counterpart line without partner and account - Click on "Automate" **Issue:** The operation fails because the default account of the bank journal is used as there is no user and no account configured for the counterpart. Which results on several lines using a liquidity account (i.e. the cause of the error). Either a partner or an account should be set on a counterpart line. opw-6056737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where event descriptions in Outlook Calendar downloads were displayed as raw HTML code instead of properly converted. The team added formatting to ensure HTML content is correctly translated to text for Outlook, improving the accuracy of event details when users download and view them.
Original PR description
### Steps to reproduce: - Download Events app. - Pick an event and click "Go to website". - Download the Outlook Calendar. ### Issue: - The HTML content within the event description is displayed as raw code and not converted properly - This happens because outlook takes the description as text and displays it in the ics file without conversion ### Solution: - Since we're working with *Outlook Calendar*, X Alt formatting was added to format HTML to text opw-5237027 Forward-Port-Of: odoo/odoo#246603
This update fixes an issue where the Libro Giornale (IT) PDF report would break its layout when an account with a long name was used. The change adds a CSS class to manage column width, preventing excessive expansion and ensuring a cleaner, more readable report. This improves the user experience for generating financial reports.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103 Forward-Port-Of: odoo/enterprise#112743
This update fixes an issue where payments wouldn't automatically update to 'paid' status after fully reconciling vendor bills, particularly when early payment discounts were involved. The change ensures payments accurately reflect the status of associated bills, improving financial reporting and reducing manual adjustments.
Original PR description
Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without…
Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without outstanding accounts. Steps to reproduce: - Create an early payment term. - Create a Vendor Bill with EPD and post it. - Register a payment for this bill (no outstanding account set on journal => no move created). - Create a bank transaction fully paying the bill. - Reconcile the transaction with the bill. Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'. Analysis: The issue occurs because the reconciliation process misses the trigger to set the payment state to 'paid'. Specifically: - The payment amount does not match the bill total due to the EPD. - The payment compute method does not monitor 'reconciled_bill_ids', causing it to ignore the status of linked vendor bills. This change adds 'reconciled_bill_ids' to the compute dependencies and ensures that if a payment is reconciled with any moves (invoices or bills), their payment_state is considered to determine the final state of the payment. Test in enterprise: https://github.com/odoo/enterprise/pull/112398 opw-5881976
This update resolves a problem where EPD bill payments weren't correctly marked as 'paid' in the accounting system. The fix ensures that payments are accurately reflected after reconciliation, improving the reliability of financial reporting. This was triggered by a specific test scenario involving early payment terms and bank transactions.
Original PR description
Steps to reproduce: - Create an early payment term. - Create a Vendor Bill with EPD and post it. - Register a payment for this bill (no outstanding account set on journal => no move created). - Create a bank transaction fully paying the bill. - Reconcile the transaction with the bill. Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'. Fix in community: https://github.com/odoo/odoo/pull/256486 opw-5881976
4 changes
Resolved issues and error corrections
This update corrects a technical issue preventing users from editing their Amazon fulfillment channel settings. The fix ensures the channel is displayed correctly and allows for necessary adjustments to be made. This improves the flexibility and control users have over their Amazon sales operations.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended. Forward-Port-Of: odoo/enterprise#112866
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which team they were linked to. Now, the website only shows articles connected to the specific helpdesk team, improving the user experience and ensuring relevant information is presented. This change was driven by a bug fix (opw-5913355).
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves an issue where price changes within the Blackbox module were failing due to incorrect handling of decimal separators in different user language settings. The fix ensures that price updates are now consistently applied regardless of the user's locale, improving order accuracy and preventing lost sales.
Original PR description
Before this commit, when changing the price of an orderline with the blackbox installed, if the decimal separator of the user language was not a dot and was used during the price change, the price was not changed. This was due to the fact that we were comparing a string with a number, the string would be implicitly be converted to a number and, when there was a comma for example, it would return a NaN which would cause the discount to not be applied and thus the price to not change.
This update resolves a crash in the Gantt chart view that occurred when opening the chart on days with Daylight Saving Time transitions. The fix addresses an issue where incorrect time calculations led to a data error, causing the chart to malfunction. This ensures the Gantt chart remains stable across different time zones.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view. Forward-Port-Of: odoo/enterprise#112840
29 changes
Enhancements to existing features
This update streamlines payroll reporting by tracking and saving deadline dates for key reports. This prevents payroll officers from missing critical submission deadlines, improving accuracy and compliance. The changes include a new system for managing report deadlines and automated recalculations.
Original PR description
Purpose: - A lot of "reports" must be done and submitted monthly, quarterly, yearly... For a payroll officer it can quickly become a mess and he can quickly miss a deadline. - We need the date of warnings to be saved when it should be displayed in order to be able to display it in the Databases application in another database. Current behavior: - Added a field on the warning to store the deadline - Added more ways for warning date computation - Added a scheduled action to recompute warning deadlines - Added warnings for belgian reports (dmfa, 281.xx, 274.xx, 273s) task-id: 5909165
This update improves the accuracy of financial reports for Chinese businesses within Odoo Enterprise. Specifically, the formulas used to categorize assets in balance sheet and profit & loss reports (ASBE & ASSBE) have been revised to align with Chinese accounting standards. This ensures more reliable reporting for our Chinese customers.
Original PR description
- update "account_codes_formula" for assets in ASBE & ASSBE reports [5985488]
This update enhances the Belgian payroll settings within Odoo Enterprise, specifically adding new configurations related to Belgian tax regulations (ONSS, insurance). The changes improve data accuracy and compliance with local requirements, streamlining payroll processing for Belgian companies.
Original PR description
- Remove Benefits and Employee Configuration settings blocks - Add ONSS, Company Information, Accident Insurance, Cash Register, Hospital Insurance and Ambulatory Insurance settings to the Belgian Localization block - Display FFE field as radio buttons instead of a dropdown - Add `l10n_be_has_cp302_employees` and `l10n_be_pos_blackbox_installed` computed fields on res.config.settings - Restrict Cash Register setting visibility to companies with CP302 employees - Make Cash Register fields read-only when pos_blackbox_be is installed task-5979696
This update to Odoo Studio allows users to easily configure lazy-loaded search filters directly within the editor interface. Previously, this required manual XML changes. This simplifies the process of creating dynamic search views, improving user efficiency and flexibility.
Original PR description
This commit exposes the newly introduced lazy-loaded search filters to the Studio interface. When editing a search view, users can now configure the `values` attribute for filters based on `selection`, `many2one`, or `many2many` fields directly from the Studio properties sidebar. This allows users to easily enable dynamic, lazy-loaded filter options without needing to modify the XML manually. task-6047969
This update enhances the automated testing process for leave requests created by officers within Odoo. By adapting the tests, we ensure greater accuracy and reliability in verifying leave calculations and reporting across various payroll modules. This improves data integrity and reduces the risk of errors related to leave management.
Original PR description
Adjusting tests for the implemented changes in https://github.com/odoo/odoo/pull/250142 task-5952413
This update introduces group-based access control for documents, making it easier to manage permissions. Users are now added to groups, and their permissions are automatically applied, streamlining access management. Existing individual permissions will still apply if a user has them, ensuring a layered approach to security.
Original PR description
### PURPOSE
Add group support for documents sharing to ease access management. It will now
be easier to add users to an already existing scheme of permissions... you'll
only have to add the users to the group and that's all.
Here are several things to know with this change:
- If a user belongs to multiple groups or has individual rights on a document,
their final permission will be the highest level granted by any of those
sources.
- When adding permission to a group, all users belonging to this group will
be notified. Users added later to the group won't be notified.
### TECHNICAL
A new model has been created to handle these groups: 'res.group.functional'
which contains 'res.users'. It also has some responsible users to avoid being
updated/deleted by everyone.
Task-5122979This update adjusts how the 13th month payment is calculated for sales representatives. It ensures the payment never falls below the minimum salary for their category based on seniority, aligning with legal requirements. This change improves payroll accuracy and compliance for this specific employee group.
Original PR description
The 13th month is computed based on fixed wage and the average of variable salaries but for Sales representatives there is a limit which is the maximum between: - the fixed salary of the employee - the minimum salary of the category D based on seniority task-6072379
Resolved issues and error corrections
This update fixes a misleading chart in the Purchase & Vendor Analysis dashboard. The chart title was previously inaccurate, suggesting supplier dependency instead of showing purchase orders by buyer. The title has been corrected to accurately reflect the data displayed, improving clarity for users.
Original PR description
Issue Before This Commit: ====================== Currently, the pie chart titled `Supplier Dependency Chart` in the Purchase & Vendor Analysis under the Logistics section is misleading because it…
Issue Before This Commit: ====================== Currently, the pie chart titled `Supplier Dependency Chart` in the Purchase & Vendor Analysis under the Logistics section is misleading because it suggests that the chart represents dependency on each supplier. However, the chart actually shows how many purchase orders are created by each buyer. Additionally, when there are no purchase orders, the sample pie chart displayed uses the title `Purchase Orders by Buyer`, which creates inconsistency between the actual chart title and the sample chart title. Steps to Reproduce: ================= - Install the **purchase_stock** module with demo data. - Go to the **Dashboard** app. - Open the **Purchase & Vendor Analysis under the Logistics** section. - Scroll down to locate the pie chart titled **Supplier Dependency Chart**. Cause of the Issue: ================ In this [PR](https://github.com/odoo/enterprise/pull/93921), at [this line](https://github.com/odoo/enterprise/pull/93921/changes#diff-61d19b77200011a8808542c134a675631e6d4b4dbc88ca99353cacfe3448b396), The pie chart title was incorrectly set to `Supplier Dependency Chart`, which does not reflect the underlying data, as the chart displays purchase orders grouped by buyer. After This Commit: ================ The pie chart title is corrected from `Supplier Dependency Chart` to `Purchase Orders by Buyer`, ensuring it accurately repersent the underlying data and avoids misleading users. TaskID-5891759 Forward-Port-Of: odoo/enterprise#110434
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which helpdesk team was viewing them. Now, the website only shows articles linked to the specific team or its associated teams, improving the user experience and ensuring relevant information is presented.
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves a crash in the Gantt chart view that occurred when opening the chart on days with Daylight Saving Time transitions. The fix addresses an issue where incorrect time calculations led to a data error, preventing users from accessing the Gantt chart. This ensures the Gantt chart remains stable across different time zones.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view. Forward-Port-Of: odoo/enterprise#112840
This update fixes misleading low wage warnings in Odoo's Belgian payroll module (l10n_be_hr_payroll). Previously, warnings appeared regardless of contract start dates, causing confusion. Now, warnings only appear if the contract starts in the past or if the wage is zero and the contract starts in the future, ensuring accurate and relevant alerts for HR users.
Original PR description
Before this change, if you created an employee from scratch in a belgian company with l10n_be_hr_payroll installed, you would automatically get a warning saying that you were below minumum wage. This would happen even if there was no contract defined on the version which doesn't make sense. Here, we add the showing condition that the contract date start on the version should be in the past. Another warning that was showing inappropriately is the one saying that the annual salary is below a certain amount and to add transport benefits. This was, for example, showing even if the contract was starting in the future. The new conditions are: - If contract starts in the future and the wage is 0 we don't show it. - If the contract starts in the future, the wage is != 0 but still insufficient, we show. - If the contract starts in the past, we show even if the wage is 0. Task: 6064262
This update restores the previous template structure used in the M3 project, incorporating necessary adaptations. It addresses a technical issue related to existing code and ensures compatibility with current functionality. This change focuses on stability and aligns with previous design standards.
Original PR description
This commit reverts the changes made for M3 to the arch, and bring back the previous template with some adaptation when needed. Note: * M3: some class are still present task-6054024 Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
This update resolves an issue where the XML generated for Swiss payments (iso20022_ch) was using an outdated payment schema. The fix ensures the XML adheres to the required Swiss banking standards, specifically the pain.001.001.09 format, improving payment processing accuracy and compliance. It also includes enhancements for validator schema and QR-IBAN handling.
Original PR description
**PROBLEM** According to documentation (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf) PstlAdr must be structured. This isn't the case when generating a xml for the payment method iso20022_ch. **STEP TO REPRODUCE** 1. install l10n_ch and account_iso20022. 2. Create a swiss contact with a full address. And activate payment on the bank account of this contact. 3. Select the Company CH, and set a bank account in the bank journal configuration. 4. Create a vendor payment to the swiss contact. 5. Create a batch payment with it, and validate to get the xml. 6. Open the xml, and notice the PstlAdr isn't structured. Ticket [link](https://www.odoo.com/odoo/project.task/5880247) opw-5880247 Forward-Port-Of: odoo/enterprise#112526 Forward-Port-Of: odoo/enterprise#107025
A bug was preventing users with access rights from checking out visitors in the Frontdesk module. This update corrects a filtering issue within user groups, ensuring the 'Check Out Visitor' button now redirects to the correct confirmation page. This resolves a frustrating user experience and ensures proper functionality.
Original PR description
## Short functional explanation of the error When a user checks in, a mail is sent in the chatter, containing a button 'Check out Visitor'. When a user who should have access to the Check Out feature…
## Short functional explanation of the error When a user checks in, a mail is sent in the chatter, containing a button 'Check out Visitor'. When a user who should have access to the Check Out feature clicks on the button, we are redirected to a 'Not Found' page. ## Reproduction Steps 1. Go to Frontdesk. Click on Open Desk and check in a visitor. 2. Go back to the Frontdesk app. Click on visitors. 3. Click on the visitor you just checked in. 4. Click on the 'Check Out Visitor' button in the chatter. ### Expected behavior A page should appear with the text: 'The visitor has been successfully checked out'. ### Unexpected behavior A 'Not found' page pops up. ## Origin of the issue We filter users who can benefit from the check-out feature using groups. However, the group used to perform this filter is written incorrectly, leading to a condition that is always True, and always returning a request not found. __ opw-5937326 Forward-Port-Of: odoo/enterprise#110022 Forward-Port-Of: odoo/enterprise#108331
This update fixes an issue related to how dates and times are displayed in Odoo. The system now correctly shows seconds when requested, and previously hidden formatting options have been removed to avoid confusion. This ensures consistent and accurate time representation across the application.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo/odoo@062b140 opw-6030342 Forward-Port-Of: odoo/enterprise#112505
This pull request addresses a small typographical error within the l10n_be_hr_payroll module. The fix ensures accurate calculations related to employee payroll in Belgium. This update improves the overall reliability of the payroll processing system.
Original PR description
typo in https://github.com/odoo/enterprise/pull/113076
This update improves the Master Production Schedule (MPS) by accurately incorporating safety stock levels for indirect demand. Previously, the system didn't properly account for this, leading to inaccurate demand forecasts. This change ensures more reliable production planning and reduces the risk of stockouts.
Original PR description
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a…
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days * Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days * Open MPS and add your three products: - Child, Parent: activate indirect demand - Parent: Safety Stock Target of 10 * Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second Observation: ------------- Usefull comment form the function : https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447 When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars) When calculating the production schedule. we wil we calculate each product for each date_range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509 When calculating the values for a product, we will set the indirect demand qty for it component The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time): https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555 If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560 In our case this will create the issue, since it will try to compensate each time on the previous week. opw-5413838 Forward-Port-Of: odoo/enterprise#113023 Forward-Port-Of: odoo/enterprise#107671
This update resolves an issue where the system incorrectly identified employees without a recorded check-in time as eligible for late hours calculations. The fix ensures that records without a check-in are excluded from late hours visibility, preventing errors and ensuring accurate reporting. This improves the reliability of late hours tracking.
Original PR description
_compute_l10n_sa_late_hours_visible, calling min() on the mapped check_in values and then .date() would crash with an AttributeError when check_in is False (e.g. during an onchange triggered by clearing the check_in field in the form view). Filter out records without a check_in before computing the date range, and mark them as not visible since late hours cannot apply without a check-in time. task-6067640 Forward-Port-Of: odoo/enterprise#111935
This update resolves a potential error in the l10n_hk_hsbcnet module that could have prevented correct assignment of HSBC bank accounts for autopay. The change adds a check for valid account numbers before assigning sanitized account numbers, ensuring accurate processing of financial data. This improves the reliability of HSBC bank integration.
Original PR description
. Add account_number check before assign sanitized_account_number task-6049640 Forward-Port-Of: odoo/enterprise#112864
This update resolves an issue where users couldn't complete the delivery order validation process when using the 'To Pickup' button. The fix allows users to open the necessary form view directly from the list, ensuring accurate order tracking and fulfillment. This improves the efficiency of the pickup process.
Original PR description
Steps to reproduce: - Install `industry_fsm_stock` - Create a task and add a product - Click on the "Sale Order" button - Add another product with the Invoicing Policy set to "Delivered quantities" - Click on the "To Pickup" button Issue: Users are unable to validate the delivery order from the products pick up button. Cause: In pr https://github.com/odoo/odoo/pull/227630 the parent view is set with `editable="bottom"`, which prevents opening the form view from the list. Fix: Allow opening the form view from the list view so users can validate the delivery order. Task-5969303 Forward-Port-Of: odoo/enterprise#110125
This update ensures that when scanning barcodes in batches, the correct lot is always used, regardless of the initial barcode serial number. Previously, the system incorrectly defaulted to the reserved serial number, leading to inaccurate inventory tracking. This fix guarantees accurate lot updates during batch processing.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921
Forward-Port-Of: odoo/enterprise#112528
Forward-Port-Of: odoo/enterprise#109671This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to paid time off. The change ensures accurate tracking and reporting of employee leave entitlements, aligning with Belgian labor regulations. This update improves payroll accuracy and compliance.
Original PR description
Update belgium paid time off calculation method and related tests. Task-6064503
This update resolves an issue where intercompany purchase orders with 'never' product variants were failing to include the correct components in the subsequent manufacturing order. The fix ensures that the variant information is properly retrieved from the purchase order, allowing for accurate production planning in the intercompany setting.
Original PR description
In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost. Steps to reproduce: ------------------- * Enable intercompany transaction * Enable variant…
In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost.
Steps to reproduce:
-------------------
* Enable intercompany transaction
* Enable variant grid entry
* Enable multistep routes
* Unarchive MTO
* Settings>Users & Companies>Companies
* Enable Generate Sales Orders in company A
* Create a product:
- Never variant with at least two values
- MTO and manufacture
* Create a bom,
- Company : company B
- Add a component with apply on variant: choose one of the variants
* Create and confirm a purchase order, for a never variant of the product, in company A with vendor as company B
* Confirm the sales order in company B
-> The manufacture order does not include the components that are applied on variant
Observation:
-------------
When creating a sale order for an intercompany rule, button_approve is overwritten and it calls the function "inter_company_create_sale_order.
That function will create the sale order from the data of the purchase order:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
When preparing the value for each order line, the attribute value for the never variant will not be retrieved:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
Since the attribute value is lost, it will not be retrived by the mto since it should get the value from the PO.
opw-5438723
Forward-Port-Of: odoo/enterprise#113031
Forward-Port-Of: odoo/enterprise#107122This update resolves an issue related to payroll calculations by ensuring the 'Company Executive' (CP999) category is correctly included in all employer categories. This correction addresses a previous error and ensures accurate payroll processing for businesses using the Odoo Enterprise module.
Original PR description
In this commit, we fixed the issue introduced in allowed JC by employer category, by including the CP999 (company executive) in all employer categories. task-6105431
This update resolves an issue where Italian tax returns weren't automatically marked as 'green' due to a technical dependency. The fix removes a specific keyword ('new') that was causing this behavior, ensuring Italian tax reports are correctly validated and displayed. This improves the accuracy of tax reporting for Italian businesses.
Original PR description
Due to this PR: https://github.com/odoo/enterprise/pull/103149 the tax return on italian l10n is automatically all greened out as the compute_visible_states depends on the 'new' keyword which was removed in the forementionned PR. This fix refacotrs the _compute_record_states_for_it to remove its dependancy on the 'new' keyword. Currently now 'new' keyword exists on the states of the return and the default state is False. task: 6106083
This update fixes a layout issue in the Italian Libro Giornale PDF report. When accounts with long names are used, the report's column width expands too much, causing text to shrink and creating unsightly gaps. The fix adds a CSS class to manage the column width, resulting in a cleaner and more professional report layout.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103 Forward-Port-Of: odoo/enterprise#112743
This update resolves an issue preventing the download of Intrastat reports for languages that use commas instead of periods as decimal separators. The fix also addresses a previous error related to product weights, improving the overall stability and reliability of the Intrastat reporting process. A more informative error message has been added for better troubleshooting.
Original PR description
Before this commit, in 19.0+, languages that use commas instead of periods for decimals could not download the intrastat report. Simply attempting to change a string to a float was not enough. Also, when a product had a NoneType weight assigned to it another trace back would occur. This also adds a more descriptive and helpful error message. opw-6026730 Forward-Port-Of: odoo/enterprise#112627
This update fixes how default customer partners are assigned when creating orders in our point-of-sale system. Previously, each localized version of the system handled this separately. Now, the system uses a central method to determine the default partner, ensuring consistency across all locations and reducing potential errors.
Original PR description
Replace the `createNewOrder()` override with `getDefaultPartnerId()` in l10n_cl_edi_pos, l10n_co_edi_pos, l10n_ec_edi_pos and l10n_gt_edi_pos. The default partner assignment is now handled centrally in `point_of_sale`'s `createNewOrder()`. opw-6077656 Forward-Port-Of: odoo/enterprise#112467
Code cleanup and technical improvements
This update standardizes the styling of the AI logo across Odoo by renaming the CSS class from `ai-logo-icon` to `oi-ai-logo`. This change improves the overall consistency and maintainability of the codebase, making future updates easier to manage.
Original PR description
*=ai,ai_knowledge,ai_website,test_discuss_full_enterprise Rename `ai-logo-icon` class to `oi-ai-logo` to follow Odoo icon naming conventions This change aligns the AI logo CSS class with the standard `oi-*` naming pattern used by Odoo icons, improving consistency and maintainability across the codebase.
9 changes
Resolved issues and error corrections
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which team the helpdesk was associated with. Now, the website only shows articles linked to the specific helpdesk team or its related teams, improving the user experience and ensuring relevant information is presented.
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves a crash in the Gantt chart view that occurred when opening the chart on days with Daylight Saving Time transitions. The fix addresses an issue where incorrect time calculations led to a data error, causing the chart to malfunction. This ensures the Gantt chart remains stable regardless of time zone settings.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view. Forward-Port-Of: odoo/enterprise#112840
This update resolves an issue where the breadcrumb navigation within the Barcode app was displaying incorrect or blank entries when moving between related records. Now, the breadcrumb accurately reflects the originating document name, providing users with clear traceability and a better user experience.
Original PR description
*: stock_barcode_mrp, stock_barcode_picking_batch ## Issue Before This PR: When navigating from the Barcode client action (e.g. picking, inventory, etc.) to related form views (such as lot, product,…
*: stock_barcode_mrp, stock_barcode_picking_batch
## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.
## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
- Delivery Orders.
- Manufacturing Orders
- Batch Pickings
- Inventory Count
- From any of these open a record
(e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.
## Cause of the Issue:
- When switching views inside the Barcode client action,
the FormController calls `setDisplayName(this.displayName())`.
In some cases, this returns an empty string, overwriting the
previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
preventing the controller from retrieving a proper name.
## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.
TaskID: 4978997
Forward-Port-Of: odoo/enterprise#99165This update prevents rental products from displaying the 'out of stock' ribbon on the website when their quantity is low. This change ensures a more accurate representation of product availability for rental customers, aligning with the time-based stock management of rental products. The fix corrects a technical issue where the system incorrectly flagged rental products as out of stock.
Original PR description
Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product. Steps to produce: --- - Install the `eCommerce Rental with Stock…
Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product. Steps to produce: --- - Install the `eCommerce Rental with Stock Management` module. - Create a rental product and set Quantity On Hand to 1. - Under the Sales tab, disable `Sell when Out of Stock`. - Under the Rental Prices tab, add pricing. - Go to `website > ecommerce > products > product ribbons`. - Open `out of stock` ribbon > set assign as `when out of stock`. - Create and Confirm a rental order for that product and validate the pickup. - The product's Quantity On Hand drops to 0. - Opening the product on the website Observation: --- - The product shows the out-of-stock ribbon. Cause: --- - At [1], the or condition evaluates to True because the ribbon is configured as `when out of stock`, `Sell when Out of Stock` is disabled under the Sales tab, and `_is_sold_out` also returns True since the quantity dropped to 0 after the pickup was validated. As all conditions are met, the ribbon is returned and displayed without ever checking whether the product is a rental. Skip the out-of-stock ribbon assignment for rental products, since their stock availability is time-based. [1]: https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/website_sale_stock/models/product_ribbon.py#L21-L28 opw-6081483 ---
This update resolves an issue in Odoo 19.0 where manual digitization of vendor invoices was blocked if the Bill Date wasn't initially set. A recent change required a Bill Date, but also prevented the automatic digitization process. This fix allows users to trigger digitization without a Bill Date, while still ensuring data consistency through validation.
Original PR description
### Issue: When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set A missing required fields error is raised ###…
### Issue: When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set A missing required fields error is raised ### Cause: This PR: https://github.com/odoo/odoo/pull/238911 introduced a required field to prevent an error modal from appearing While this works as intended, it also blocks the `Digitize Document` action, which is supposed to populate the Bill Date automatically ### Fix: A condition similar to the one used for the Digitize Document button is applied to allow triggering digitization without a Bill Date The validation modal is still enforced afterward to ensure data consistency in case of manual edits ### Steps to reproduce: - Install `account` - In Settings, set `Document Digitization` for `Vendor Bills` to `Digitize on demand only` - Create and print an invoice (any data) or use an existing one - Import it into Vendor Bills - Click Digitize Document ### Before the fix: A missing required fields notification is raised, preventing digitization opw-5886012
This update fixes an error in the Italian tax returns that was incorrectly including taxes beyond withholding taxes (like INPS). The fix ensures the total amount calculated on the return accurately reflects only the withholding tax, improving the reliability of Italian tax reporting. This resolves a previous issue impacting financial accuracy.
Original PR description
### Issue before this commit: Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes…
### Issue before this commit: Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes such as 4% INPS were included in the computed total amount to pay, even though they should not be part of the withholding tax return. As a result, the final amount shown in the return was incorrect. ### Steps to reproduce the issue: 1. Download Accounting and l10n_it and switch to italian company 2. Create an invoice and a bill with a witholding tax (ex. 20% RIT PF) 3. Mark them as paid and reconcile them 4. Open a tax return and validate it 5. See that the total amount calculated includes also other taxes than only witholding taxes ### Cause of the issue: The issue was caused by a missing domain restriction when computing the tax closing entries. The method _get_vat_closing_entry_additional_domain did not properly apply a filter on tax tags for the withholding tax return type l10n_it_reports.it_withh_tax_return_type. Because of this, the query used to compute tax balances included all taxes matching the generic conditions (date, company, posted state, etc.), without restricting them to the relevant withholding tax tags. Consequently, unrelated taxes were included in the computation. ### Reason to introduce the fix: To restore the correctness of the tax return totals. opw-5905355
This update resolves a critical issue where users could cancel documents after all parties had signed, potentially compromising legal records. Now, the cancel button disappears automatically after signing is complete, and backend cancellations are blocked to ensure document permanence and security. This strengthens the integrity of agreements recorded in Odoo.
Original PR description
Before this commit, users could cancel documents after everyone had signed. This weakened legal records and proof of agreement. After this commit, the cancel button disappears once signing is complete. We also blocked backend cancellations to keep finished documents permanent and secure. task-5980337 Forward-Port-Of: odoo/enterprise#110884 Forward-Port-Of: odoo/enterprise#109353
This update fixes an issue related to how default customer partners are assigned when creating orders in Odoo Point of Sale for specific countries (Chile, Colombia, Ecuador, and Guatemala). The change centralizes partner assignment, ensuring more consistent order creation across these localized versions. This improves order processing reliability.
Original PR description
Replace the `createNewOrder()` override with `getDefaultPartnerId()` in l10n_cl_edi_pos, l10n_co_edi_pos, l10n_ec_edi_pos and l10n_gt_edi_pos. The default partner assignment is now handled centrally in `point_of_sale`'s `createNewOrder()`. opw-6077656
This update fixes a layout issue in the Italian Libro Giornale PDF report. When accounts with long names are used, the report's column width expands, causing font shrinkage and excessive spacing. The change adds a CSS class to manage column width, resulting in a cleaner and more readable PDF report.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103 Forward-Port-Of: odoo/enterprise#112743
7 changes
Resolved issues and error corrections
This update fixes a minor issue with the SendCloud delivery module by adding a clearer error message to users when delivery problems occur. This helps users quickly understand the reason for the failure and take appropriate action, improving the overall delivery process. The change was driven by a specific user feedback ticket.
Original PR description
Add hint with error message. ----- Ticket: opw-6072855
This update resolves a bug that caused Odoo reports to crash when comparing data containing string values. The fix ensures the report accurately handles different data types during comparisons, improving overall stability and reliability. This prevents unexpected errors when users utilize the report comparison feature.
Original PR description
To reproduce: - Create a company in LU - Open the annual tax report for LU - Click on the comparison filter, compare with 1 period in the past ==> Traceback. This happens because that report contains a string value (an editable one, but it's not important here). Since there are only 2 comparison periods, we try creating the "%" column, comparing their amounts. The condition checking whether or not to display "N/A" was wrong, as it considered the values could only be int/float or None. Here, they are strings, so we don't enter that condition and crash when trying to evaluate float_is_zero on a string.
This update fixes a bug that prevented product descriptions from appearing on barcode receipts. Previously, only the product name was shown. Now, when a product has a description, it's correctly displayed on the barcode receipt, improving clarity and accuracy for users.
Original PR description
**problem:** The description/internal notes of a product is not displayed on the barcode interface. **steps to reproduce:** 1. Create a product with a "Description" 2. Create and confirm a request…
**problem:** The description/internal notes of a product is not displayed on the barcode interface. **steps to reproduce:** 1. Create a product with a "Description" 2. Create and confirm a request for quotation for this product through the purchase app 3. Open the receipt in the barcode app 4. The description is not visible on the line **cause:** - The JS barcode model (`/stock_barcode/barcode_picking_model.js`) never propagated the description_picking from the parent stock.move record to the stock.move.line data used by the UI template. - The view did not have a tag for the description. - In Python (`_get_stock_barcode_data()`) in `stock_barcode/stock_picking.py` did not filter out the redundant default description_picking, which was set to product.name when no specific picking description exists on the product. **fix:** - In `_get_stock_barcode_data()`, recompute the move description to be the actual description (or `False` when empty/default 'product.name'). - We need to propagate the description_picking from stock.move to the stock.move.line data, and render it in the views. opw-6058584
This update ensures that negative values in the Mod 390 tax reports for Spain are accurately marked with the 'N' indicator, as required by Spanish tax regulations. The fix addresses a previous issue where these negative values were not being properly formatted for export, ensuring compliance and accurate reporting.
Original PR description
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export ### Note: According to the official specification, negative amounts must be explicitly marked with N Latest documentation: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` with demo data and switch to the ES company - Create a Bill (Price: 100, Taxes: 21% G) - Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year - Open the VAT Deductible tab - The last line (65) should be negative - Export the BOE file using the gear menu - Check the last value of section 4 in the file ### Before the fix: Negative values were not marked with N opw-5482706 Forward-Port-Of: odoo/enterprise#111262
This update resolves an issue preventing non-stock users from duplicating helpdesk tickets with associated sales. The fix sets the product ID to 'false' during duplication, allowing users without stock access to create copies of tickets. This improves usability for all users.
Original PR description
Steps to reproduce: - Install helpdesk_sale_timesheet. - Create a Helpdesk Ticket and set its sale_line_id. - Log in as a user without stock.group_stock_user access. - Try to duplicate the ticket. Issue: Duplicating a ticket raises an AccessError because the user lacks stock rights required when copying the product_id. Fix: Set `product_id` to False during duplication for non-stock users. Reference: https://github.com/odoo/enterprise/pull/9100 task-5356318
This update resolves a technical issue that prevented users from closing sessions when generating the DSFinV-K export for German Point of Sale certifications. The change ensures a fallback user ID is used, allowing session closure to proceed smoothly. This improves the reliability of the certification export process.
Original PR description
Before this commit, closing a session was blocked if an order was missing the user_id field during DSFinV-K export generation. opw-6067382
This update resolves a technical issue preventing the correct return of invoice data during import through the Peppol system. The change ensures that the system now accurately reports the newly created invoice move, addressing a previous bug. This improves the reliability of invoice processing within the Peppol integration.
Original PR description
Due to 271d6f2af4eea1ac2a79850069118c00dd97db97, the import invoice method in Peppol should return the created move and not just True. With the documents_account_peppol module, that change was not fully merged. opw-6102218
4 changes
Resolved issues and error corrections
This update fixes a warning related to employee sick leave durations. Previously, the system incorrectly flagged employees with sick leaves exceeding 31 days. The change now accurately identifies employees who have been on sick leave for the past 31 days, ensuring accurate reporting and compliance.
Original PR description
-**Issue**: The warning shows employees who had a long sick leaves before 31 days, which is incorrect. -**Fix**: Adjust the logic to include employees who have been on a sick leave for the past 31 days (at least).
This update corrects a problem where '&' characters in vendor bill references were causing errors during SEPA payment file generation. The fix replaces '&' with '+' to ensure compliance with SEPA/SIX specifications, preventing payment rejection by banks. This ensures accurate and compliant SEPA payment processing.
Original PR description
Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net &…
Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer. 4. Create a batch payment with the SEPA payment and validate it. Issue: The `&` character is exported as `&` in the generated PAIN XML, while according to the SIX specification it should be replaced with `+` Cause: The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed. Solution: Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML. Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf opw-5941724 Co-authored by @bhra-odoo
This update resolves an error that occurred when removing products from POS orders, specifically when a product lacked a POS category. The fix prevents a program crash (IndexError) that could disrupt order cancellation processes. This ensures smoother and more reliable order management within the POS system.
Original PR description
When a product is removed from a POS order, _process_preparation_changes sorts the preparation display lines by their current stage sequence to determine cancellation priority. This relies on `order_stage_ids[-1]`, which raises an IndexError when a preparation display order has no stage assigned. Steps to reproduce: 1. Create a preparation display with at least one category filter. 2. Add a product to the POS with no POS category assigned. 3. Add that product to an order and send it. 4. Remove the product from the order and proceed to payment. 5. → IndexError: tuple index out of range opw-6089731
This update corrects a display issue where the product count in the stat button on Sale Order Lines created from tasks would incorrectly show '0 products' until the task was saved. Now, the counter accurately reflects the products associated with the task, providing a more reliable view of sales activity.
Original PR description
Previously, when creating a Sale Order Line on the fly from a task, the product count in the stat button showed '0 products' until the task was saved. Now, the counter no longer drops to 0 when the record is not saved. task-4276677