Daily updates from Odoo
Navigate
Branch
Saturday, March 7, 2026
37 changes
9 changes
Enhancements to existing features
This update enhances the demo data loading process within Odoo by ensuring the system accurately reflects demo module states and automatically installs demo modules. This results in a more realistic and functional demo environment for users, streamlining the onboarding and training experience.
Original PR description
[IMP] core: improve force demo Improve the force demo function 1. update registry when demo data triggered module state changes 2. add ``install_demo`` to the context when loading demo data enterprise https://github.com/odoo/enterprise/pull/109792 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#250868
Resolved issues and error corrections
This update resolves an issue where Romanian customers without a company registry were incorrectly assigned the default VAT instead of the standard VAT. The fix removes a redundant condition that was causing this misassignment, ensuring accurate VAT application for all Romanian customers.
Original PR description
Problem --------- In a recent fix, in the Tax Scheme customer node, the scheme type was recomputed correctly depending on the companyID node. However, during the fix, a condition was wrongly introduced. This will lead to some issue: when a customer has no VAT, he should be given the default VAT. However, due to condition, the customer gets given the Default VAT only when he does not have a vat NOR A COMPANY REGISTRY. Solution --------- Remove the condition no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252475
This update corrects an issue where generating PIX payment QR codes would fail if company names included special characters like emojis. The fix ensures company names only contain valid characters, guaranteeing QR code validity and successful payment processing. This improves the reliability of PIX payments for Brazilian customers.
Original PR description
When generating the QR code for PIX payment, if the company name contained incorrect characters (like emojis), the generated code was invalid and the payment could not be processed. Steps to reproduce: ------------------- * Install l10n_br and PoS * Create a PIX payment method and set it on the PoS session * Change the company name to contain an emoji (e.g. "Company emoji 😇") * Open the PoS session and try to pay with PIX > Observation: If you try to verify the generated QR code, it will be invalid Why the fix: ------------ We apply the same regex as defined here: https://github.com/odoo/odoo/blob/72654c3596660e3ec4b6885c5b957739465de097/addons/l10n_br/models/res_partner_bank.py#L81 To make sure the company name only contains valid characters, and the generated QR code is correct. This also modify the other tests because it removes the `_` that is not an allowed character. opw-5907530 Forward-Port-Of: odoo/odoo#250917
This update resolves an issue where invoice content overlapped with the header on subsequent pages when generating PDFs. The fix addresses a technical problem related to how wkhtmltopdf handles tables across pages, ensuring the header and invoice content are properly separated.
Original PR description
**Steps to reproduce:** * Install `Accounting` module. * Create an invoice with enough lines to span multiple pages. * Print the invoice to PDF (or use the 'Print' action). **Observed behavior:** *…
**Steps to reproduce:** * Install `Accounting` module. * Create an invoice with enough lines to span multiple pages. * Print the invoice to PDF (or use the 'Print' action). **Observed behavior:** * On the second page (and subsequent pages), the invoice table rows overlap with the company header (logo, address). * This regression was introduced in saas-19.1 after the flexible document layout refactoring (commit). **Cause:** * The invoice's main table (`o_main_table`) is wrapped in a `<div class='table-responsive-sm'>`. * `table-responsive-sm` applies `overflow-x: auto` at narrow viewports, which creates a Block Formatting Context (BFC). * In wkhtmltopdf's WebKit engine, a BFC container does not participate in normal page fragmentation. When the table spans multiple pages, the content bleeds into the next page without respecting the header spacing defined by `--margin-top` and `--header-spacing`. * This causes the continued table rows (and any repeated `<thead>`) to render at the very top of the content area, overlapping with the page header. **ref:** https://github.com/odoo/odoo/commit/15697add5751181544fb61302ddb745a354a2935#diff-c85e75bc27fc841662ca0598c09a22670e0a0b4e5120815934c0a50999ff02bfR172 with this commit `table-responsive-sm` added to invoice pdf layout. **Fix:** * Add `overflow: visible` on the `table-responsive-sm` wrapper div to prevent the creation of a scroll container / BFC. * This ensures wkhtmltopdf can properly fragment the table across pages and respect the header spacing on all pages. **Before:** <img width="874" height="250" alt="image" src="https://github.com/user-attachments/assets/2da0a82a-abc9-49d6-9788-c8e89283e4b2" /> **After:** <img width="872" height="256" alt="image" src="https://github.com/user-attachments/assets/cd38b7e3-b2b6-4c03-a1d8-5ac31cad0925" /> opw-5949713 Forward-Port-Of: odoo/odoo#249998
This update ensures that the 'Insert in spreadsheet' action is only visible to users with the necessary permissions for Documents and Dashboards. Previously, users without these permissions could still see the action, which has now been corrected for a more streamlined and secure user experience.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards. Desired behavior after PR is merged: - The action is shown in the list view action menu only if the user has the required permissions. Task: 5930184 Forward-Port-Of: odoo/enterprise#109739 Forward-Port-Of: odoo/enterprise#108099
This update ensures that users only see the 'Insert in spreadsheet' option in the kanban view if they have the necessary permissions. Previously, users without these permissions could still see the option, leading to potential confusion. The update also removes a restriction that prevented inserting records from kanban views grouped by m2m fields, streamlining the process.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the kanban view action menu, even when the user lacked access rights for Documents or Dashboards. - Inserting records from a kanban view into a spreadsheet was blocked when the view was grouped by an m2m field. Desired behavior after PR is merged: - The action is shown in the kanban view action menu only if the user has the required permissions. - The m2m field check is removed when inserting from kanban views. Task: 5930184 Forward-Port-Of: odoo/enterprise#108098
This update allows all agents with live chat access to edit the description of a live chat conversation, regardless of whether they are a member of the channel. Previously, only channel members could make these changes. This improves agent flexibility and efficiency in managing live chat interactions.
Original PR description
…cription **Before this PR**, only users who were channel members could edit the description of a live chat conversation. With this change, agents who have live chat access can now edit the channel description **even if they are not members** of that specific live chat channel. task-5046015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251451
This update resolves an issue that occurred when the demo version of Odoo Enterprise was used. Specifically, certain buttons were incorrectly triggered, causing unexpected behavior within the accounting module. This fix ensures the demo mode functions reliably and prevents potential disruptions for users.
Original PR description
community https://github.com/odoo/enterprise/pull/97209 Forward-Port-Of: odoo/enterprise#109792
This update fixes an issue where the system incorrectly rejected valid Non-Resident (NRI) GSTINs. The change adjusts the validation process to accept a wider range of valid NRI GSTIN formats, ensuring accurate tax ID processing for international customers. This improves data integrity and prevents errors when entering tax information.
Original PR description
Currently, valid GSTINs for certain Non-Resident taxpayers are rejected. **Steps to reproduce:** - Install the `l10n_in` module. - Navigate to Settings > Users & Companies > Companies. - Open `IN…
Currently, valid GSTINs for certain Non-Resident taxpayers are rejected. **Steps to reproduce:** - Install the `l10n_in` module. - Navigate to Settings > Users & Companies > Companies. - Open `IN Company` and set `Tax ID` to `9922JPN29001OSU` and try to `save`. **Error:** `The VAT number [9922JPN29001OSU] for partner [IN Company] does not seem to be valid.` `Note: the expected format is 12AAAAA1234AAZA` The system rejects the GSTIN, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root cause:** At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a different structure and are not matched by the existing regex. **Fix:** This commit ensures that valid NRI GSTIN formats are accepted during validation. Confirm with IN PO. [1]: https://services.gst.gov.in/services/searchtp [2]: https://github.com/odoo/odoo/blob/5e59f4b3def44aa84c06ba4c2ed34bf2e8da928f/addons/base_vat/models/res_partner.py#L712-L723 opw-5956299 Forward-Port-Of: odoo/odoo#252647 Forward-Port-Of: odoo/odoo#251760
5 changes
Enhancements to existing features
This update enhances the demo data loading process in Odoo by ensuring the system accurately reflects demo module states and automatically installs demo modules. Previously, demo data didn't always update the system's state correctly. Now, the demo data loading is more reliable and consistent, providing a better starting point for users.
Original PR description
[IMP] core: improve force demo Improve the force demo function 1. update registry when demo data triggered module state changes 2. add ``install_demo`` to the context when loading demo data enterprise https://github.com/odoo/enterprise/pull/109792 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#250868
Resolved issues and error corrections
This update ensures that the 'Insert in spreadsheet' action is only visible to users with the necessary permissions for Documents and Dashboards. Previously, users without these permissions could still see the action, which has now been corrected for a more streamlined and secure user experience.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards. Desired behavior after PR is merged: - The action is shown in the list view action menu only if the user has the required permissions. Task: 5930184 Forward-Port-Of: odoo/enterprise#109739 Forward-Port-Of: odoo/enterprise#108099
This update fixes a restriction that prevented users from inserting records directly into spreadsheets from the Kanban view, particularly when the view was organized by related data. Now, the 'Insert in spreadsheet' action appears only for users with the necessary permissions and the system no longer blocks insertion based on m2m field groupings within the Kanban view.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the kanban view action menu, even when the user lacked access rights for Documents or Dashboards. - Inserting records from a kanban view into a spreadsheet was blocked when the view was grouped by an m2m field. Desired behavior after PR is merged: - The action is shown in the kanban view action menu only if the user has the required permissions. - The m2m field check is removed when inserting from kanban views. Task: 5930184 Forward-Port-Of: odoo/enterprise#108098
This update resolves an issue that occurred when the demo version of Odoo Enterprise was used. Specifically, certain buttons were being triggered unnecessarily, causing unexpected behavior in the accounting module. This change ensures a smoother and more reliable experience for users in demo mode.
Original PR description
community https://github.com/odoo/enterprise/pull/97209 Forward-Port-Of: odoo/enterprise#109792
This update corrects a bug that prevented the system from accepting valid GSTINs for Non-Resident Indian (NRI) taxpayers. The previous validation rule was too restrictive, rejecting numbers that followed a different format. This change ensures accurate tax ID processing for NRI customers.
Original PR description
Currently, valid GSTINs for certain Non-Resident taxpayers are rejected. **Steps to reproduce:** - Install the `l10n_in` module. - Navigate to Settings > Users & Companies > Companies. - Open `IN…
Currently, valid GSTINs for certain Non-Resident taxpayers are rejected. **Steps to reproduce:** - Install the `l10n_in` module. - Navigate to Settings > Users & Companies > Companies. - Open `IN Company` and set `Tax ID` to `9922JPN29001OSU` and try to `save`. **Error:** `The VAT number [9922JPN29001OSU] for partner [IN Company] does not seem to be valid.` `Note: the expected format is 12AAAAA1234AAZA` The system rejects the GSTIN, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root cause:** At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a different structure and are not matched by the existing regex. **Fix:** This commit ensures that valid NRI GSTIN formats are accepted during validation. Confirm with IN PO. [1]: https://services.gst.gov.in/services/searchtp [2]: https://github.com/odoo/odoo/blob/5e59f4b3def44aa84c06ba4c2ed34bf2e8da928f/addons/base_vat/models/res_partner.py#L712-L723 opw-5956299 Forward-Port-Of: odoo/odoo#252647 Forward-Port-Of: odoo/odoo#251760
3 changes
Resolved issues and error corrections
This update ensures that the 'Insert in spreadsheet' action is only visible to users with the necessary permissions for Documents and Dashboards. Previously, users without these permissions could still see the action, which has now been corrected to enhance security and streamline the user experience.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards. Desired behavior after PR is merged: - The action is shown in the list view action menu only if the user has the required permissions. Task: 5930184 Forward-Port-Of: odoo/enterprise#109739 Forward-Port-Of: odoo/enterprise#108099
This update fixes a printing issue that occurred when creating duplicate vendor bills using DIAN support documents. The fix ensures that the report template only attempts to print related information when a valid DIAN attachment exists, preventing a crash caused by parsing errors.
Original PR description
**Steps to reproduce:** * Install the **l10n_co_dian** module. * Enable DIAN 2.1 operation mode: **Support Documents** in settings. * Create a vendor bill using a **DIAN support document** journal. * Confirm the vendor bill. * Click **Print**. **Observed behavior:** * Printing fails with `ValueError: can only parse strings`. **Cause:** * The report template unconditionally called `_l10n_co_dian_get_extra_invoice_report_values()`, which parses `l10n_co_dian_attachment_id.raw` via `etree.fromstring()`. * On duplicated bills, `l10n_co_dian_document_ids` (and thus the computed `l10n_co_dian_attachment_id`) is empty, so `.raw` is `False`. **Fix:** * Wrap the QR code / CUFE / signing section in the report template with `t-if='o.l10n_co_dian_attachment_id'` so it is only rendered when the DIAN attachment exists. opw-5930173 Forward-Port-Of: odoo/enterprise#108645
This update fixes a previous issue where users without proper permissions could see the 'Insert in spreadsheet' option in the Kanban view. Now, the option is only displayed for users with the necessary access rights, and inserting records from Kanban views grouped by m2m fields is now supported.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the kanban view action menu, even when the user lacked access rights for Documents or Dashboards. - Inserting records from a kanban view into a spreadsheet was blocked when the view was grouped by an m2m field. Desired behavior after PR is merged: - The action is shown in the kanban view action menu only if the user has the required permissions. - The m2m field check is removed when inserting from kanban views. Task: 5930184 Forward-Port-Of: odoo/enterprise#108098
5 changes
Resolved issues and error corrections
This update ensures that the 'Insert in spreadsheet' action is only visible to users with the necessary permissions for Documents and Dashboards. Previously, users without these permissions could still see the action, which has now been corrected for a more streamlined and secure user experience.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards. Desired behavior after PR is merged: - The action is shown in the list view action menu only if the user has the required permissions. Task: 5930184 Forward-Port-Of: odoo/enterprise#109739 Forward-Port-Of: odoo/enterprise#108099
This update fixes an issue where the system incorrectly rejected valid Non-Resident Indian (NRI) GSTINs. The change adjusts the validation process to accept a wider range of valid GSTIN formats, ensuring accurate tax ID input for NRI company records. This prevents errors and improves data integrity.
Original PR description
Currently, valid GSTINs for certain Non-Resident taxpayers are rejected. **Steps to reproduce:** - Install the `l10n_in` module. - Navigate to Settings > Users & Companies > Companies. - Open `IN…
Currently, valid GSTINs for certain Non-Resident taxpayers are rejected. **Steps to reproduce:** - Install the `l10n_in` module. - Navigate to Settings > Users & Companies > Companies. - Open `IN Company` and set `Tax ID` to `9922JPN29001OSU` and try to `save`. **Error:** `The VAT number [9922JPN29001OSU] for partner [IN Company] does not seem to be valid.` `Note: the expected format is 12AAAAA1234AAZA` The system rejects the GSTIN, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root cause:** At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a different structure and are not matched by the existing regex. **Fix:** This commit ensures that valid NRI GSTIN formats are accepted during validation. Confirm with IN PO. [1]: https://services.gst.gov.in/services/searchtp [2]: https://github.com/odoo/odoo/blob/5e59f4b3def44aa84c06ba4c2ed34bf2e8da928f/addons/base_vat/models/res_partner.py#L712-L723 opw-5956299 Forward-Port-Of: odoo/odoo#252540 Forward-Port-Of: odoo/odoo#251760
This update resolves a printing error that occurred when generating invoices with DIAN support documents. The fix prevents a crash caused by an attempt to print sections of the invoice when the necessary DIAN attachment wasn't available. This ensures invoices with multiple support documents can be printed correctly.
Original PR description
**Steps to reproduce:** * Install the **l10n_co_dian** module. * Enable DIAN 2.1 operation mode: **Support Documents** in settings. * Create a vendor bill using a **DIAN support document** journal. * Confirm the vendor bill. * Click **Print**. **Observed behavior:** * Printing fails with `ValueError: can only parse strings`. **Cause:** * The report template unconditionally called `_l10n_co_dian_get_extra_invoice_report_values()`, which parses `l10n_co_dian_attachment_id.raw` via `etree.fromstring()`. * On duplicated bills, `l10n_co_dian_document_ids` (and thus the computed `l10n_co_dian_attachment_id`) is empty, so `.raw` is `False`. **Fix:** * Wrap the QR code / CUFE / signing section in the report template with `t-if='o.l10n_co_dian_attachment_id'` so it is only rendered when the DIAN attachment exists. opw-5930173 Forward-Port-Of: odoo/enterprise#108645
This update fixes a previous issue where users without proper permissions could access the 'Insert in spreadsheet' action in Kanban views. Now, the action is only visible to users with the necessary permissions, and the restriction on inserting records based on grouped m2m fields has been removed, streamlining the process of adding data from Kanban to spreadsheets.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the kanban view action menu, even when the user lacked access rights for Documents or Dashboards. - Inserting records from a kanban view into a spreadsheet was blocked when the view was grouped by an m2m field. Desired behavior after PR is merged: - The action is shown in the kanban view action menu only if the user has the required permissions. - The m2m field check is removed when inserting from kanban views. Task: 5930184 Forward-Port-Of: odoo/enterprise#108098
This update fixes an issue where manufacturing order end dates were incorrectly calculated, assuming work centers operated 24/7. The change now accurately considers work center availability, ensuring more precise scheduling and reducing potential delays in production. This improves the reliability of production planning.
Original PR description
**Issue** The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day. **Steps to reproduce** 1. Create a manufacturing order with: - A work order…
**Issue** The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day. **Steps to reproduce** 1. Create a manufacturing order with: - A work order with an expected duration of 1440 minutes. - A work center configured to work 8 hours per day. 2. Observe that the scheduled end date is computed as if the work center operates 24h/day resulting in an end date 1 day instead of 4 after the starting date. **Cause** The `date_finish` computation: https://github.com/odoo/odoo/blob/680085b55728dcb000e7bb4277bb83b0e4e2ce91/addons/mrp/models/mrp_production.py#L745C1-L746C105 does not take into account neither the work center’s calendar nor the workorder dependency when estimating the duration. **Solution** Use `_get_first_available_slot`: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workcenter.py#L332 to consider workcenter availability, inspired from when a workorder is planned: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workorder.py#L527 **Additionnal notes** - If a workcenter of at least one workorder is unavailable, just fallback on the previous computation. - The solution does not take workorder dependencies into account due to related technical limitation see https://github.com/odoo/odoo/pull/232805 for an earlier attempt to handle dependencies. - Our test rely on the assertAlmostEqual for the same reason than https://github.com/odoo/odoo/commit/e6c958ca226bd8ef7e518243c93e40b92b9b5919 opw-[5084120](https://www.odoo.com/web#id=5084120&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#240617
1 change
Resolved issues and error corrections
This update fixes a bug that caused printing of vendor bills using DIAN support documents to fail. The issue stemmed from a report template that incorrectly processed duplicate bills, leading to a parsing error. The fix ensures that printing only occurs when a valid DIAN attachment is present, improving printing reliability.
Original PR description
**Steps to reproduce:** * Install the **l10n_co_dian** module. * Enable DIAN 2.1 operation mode: **Support Documents** in settings. * Create a vendor bill using a **DIAN support document** journal. * Confirm the vendor bill. * Click **Print**. **Observed behavior:** * Printing fails with `ValueError: can only parse strings`. **Cause:** * The report template unconditionally called `_l10n_co_dian_get_extra_invoice_report_values()`, which parses `l10n_co_dian_attachment_id.raw` via `etree.fromstring()`. * On duplicated bills, `l10n_co_dian_document_ids` (and thus the computed `l10n_co_dian_attachment_id`) is empty, so `.raw` is `False`. **Fix:** * Wrap the QR code / CUFE / signing section in the report template with `t-if='o.l10n_co_dian_attachment_id'` so it is only rendered when the DIAN attachment exists. opw-5930173 Forward-Port-Of: odoo/enterprise#108645
11 changes
Enhancements to existing features
This update enhances the Odoo VoIP system by allowing calls to proceed without requiring a microphone upfront, improving usability and flexibility. It introduces features for managing microphone status, selecting audio devices, and handling errors, ultimately providing a more robust and user-friendly call experience.
Original PR description
(Originally started at https://github.com/odoo/enterprise/pull/103404) (Follow-up of https://github.com/odoo/enterprise/pull/105215) Introduce the VoIP AudioManager, to handle everything that is audio related during a call. It now allows to proceed with any calls without microphone, select input and output device in and out of calls, always see the microphone status at the top, handle errors, use Discuss utils, etc etc. See commit messages for details. task-5108259
Resolved issues and error corrections
This update removes a display field ('Visible Internally Only') from the customer rating form in the Helpdesk module. This field was no longer needed as customer ratings are no longer visible on the website. This cleanup improves the user experience and reduces unnecessary complexity.
Original PR description
**Steps to reproduce:** - Open a Helpdesk ticket with a customer rating. - View the rating form. - Observe the field ‘Visible Internally Only’ still showing. **Issue:** - The field is displayed even though ratings are no longer shown on the website. **Reason:** - The field is now irrelevant but still present in the view. **Fix:** - Invisible the ‘Visible Internally Only’ field from the customer rating form in the affected version. **Task id - 5359052** Forward-Port-Of: odoo/enterprise#109287 Forward-Port-Of: odoo/enterprise#100686
This update corrects a visual issue where the unit display (hours/days) for KPIs in the sale timesheet was misaligned. The change restores the original layout, ensuring accurate and consistent KPI reporting. This resolves a minor display problem impacting user readability.
Original PR description
Due to the recent refactoring of the `formatFloatTime` formatter in odoo/enterprise#108072, the KPIs lost their layout, resulting in a misaligned display. This commit restores the original layour for the KPI header, ensuring the unit (hours/days) is correctly shown next to the value. Forward-Port-Of: odoo/enterprise#109809
This update resolves an issue where by-products tracked with serial numbers incorrectly displayed extra lines in the shop floor manufacturing order view when a specific setting was enabled. The change ensures by-products only show lines that are manually added, aligning with the intended workflow and improving data accuracy.
Original PR description
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in…
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in shopfloor MO cards (both in overview and work center views). Steps to reproduce: 1. Create a bill of materials for a final product 2. Add a consumable component 3. Create an operation without steps 4. Add a by-product tracked by serial number 5. Specify that the by-product is produced in the operation above 6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves" 7. Create a manufacturing order for the BOM and confirm it 8. Open the Shop Floor view from the MO 9. Observe the extra line for the by-product in both overview and work center views Root cause: The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button. Solution: Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled. Task-5431295 Forward-Port-Of: odoo/enterprise#109761 Forward-Port-Of: odoo/enterprise#103260
This update removes unnecessary debugging code that was inadvertently included in account reports. Previously, this code was being sent to the JavaScript interface, causing potential issues with report data. This change ensures cleaner report data and a more stable user experience.
Original PR description
Since this commit https://github.com/odoo/enterprise/commit/265629249ec71797b6387b46d2245154159b0c00 the code has been returned in the report information, therefore the 'code' key is present in the JSON sent to the JS. no-task <img width="884" height="676" alt="image" src="https://github.com/user-attachments/assets/1f22cc29-2d3d-4c61-9380-e1de77543339" />
This update addresses a technical issue where discussion counters and comments weren't being properly updated after recent improvements to the Odoo Enterprise platform. The fix ensures accurate tracking of discussion activity, improving the overall functionality of the discussion module.
Original PR description
The file was not updated following recent improvements. https://github.com/odoo/odoo/pull/252508
This update resolves an issue where tags in German financial reports were incorrectly sorted, causing problems with the auto-complete feature. The fix ensures tags are properly ordered, improving the user experience and report accuracy. Additional tests have been added to prevent similar issues in the future.
Original PR description
Commit https://github.com/odoo/odoo/commit/db0d499952192ede0def2a070e103ba67952387c inverted some tags which is wrong Tags must be sorted for the auto complete to work properly Improving tests to catch more errors opw-5415426 Forward-Port-Of: odoo/enterprise#108848
This update resolves an issue where users received empty deprecation schedule reports if customer customizations to their accounting records caused conflicts with Odoo's internal calculations. The fix ensures accurate report generation by granting administrative access, guaranteeing correct data retrieval for asset depreciation schedules.
Original PR description
Following odoo/enterprise@ece0405785, in case a customer modified the `account.move.line` record rules in a way which is incompatible with the AML shadowing, user will only get an empty deprecation schedule report. This commit as a sudo, to ensure we get a correct report, access rights being already check for `account.asset` records. Forward-Port-Of: odoo/enterprise#108901
This update fixes a previous issue where users without proper permissions could access the 'Insert in spreadsheet' action from the kanban view. Now, the action is only visible to users with the necessary permissions, and inserting records from kanban views grouped by m2m fields is now fully supported. This enhances usability and allows for more flexible data entry.
Original PR description
Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the kanban view action menu, even when the user lacked access rights for Documents or Dashboards. - Inserting records from a kanban view into a spreadsheet was blocked when the view was grouped by an m2m field. Desired behavior after PR is merged: - The action is shown in the kanban view action menu only if the user has the required permissions. - The m2m field check is removed when inserting from kanban views. Task: 5930184 Forward-Port-Of: odoo/enterprise#108098
This update refines how Odoo handles binary files (like invoices or statements) by ensuring they are consistently represented as `BinaryValue` objects. This change improves data integrity and compatibility across various Odoo modules, particularly those dealing with financial reporting and document imports. It's a standard best practice for data type consistency.
Original PR description
https://github.com/odoo/odoo/pull/244421
This update resolves a problem that occurred when the demo version of Odoo Enterprise was used. Specifically, certain buttons were triggered unexpectedly, causing disruptions. This change ensures the demo mode functions correctly, providing a stable and reliable experience for testing and evaluation.
Original PR description
community https://github.com/odoo/enterprise/pull/97209 Forward-Port-Of: odoo/enterprise#109792
1 change
Resolved issues and error corrections
This update fixes a bug that caused printing of vendor bills using DIAN support documents to fail. The issue stemmed from a report template that incorrectly processed duplicate bills, leading to a parsing error. The fix ensures that printing only occurs when a valid DIAN attachment exists, improving printing reliability.
Original PR description
**Steps to reproduce:** * Install the **l10n_co_dian** module. * Enable DIAN 2.1 operation mode: **Support Documents** in settings. * Create a vendor bill using a **DIAN support document** journal. * Confirm the vendor bill. * Click **Print**. **Observed behavior:** * Printing fails with `ValueError: can only parse strings`. **Cause:** * The report template unconditionally called `_l10n_co_dian_get_extra_invoice_report_values()`, which parses `l10n_co_dian_attachment_id.raw` via `etree.fromstring()`. * On duplicated bills, `l10n_co_dian_document_ids` (and thus the computed `l10n_co_dian_attachment_id`) is empty, so `.raw` is `False`. **Fix:** * Wrap the QR code / CUFE / signing section in the report template with `t-if='o.l10n_co_dian_attachment_id'` so it is only rendered when the DIAN attachment exists. opw-5930173 Forward-Port-Of: odoo/enterprise#108645
1 change
Resolved issues and error corrections
This update corrects a bug that was preventing valid Non-Resident Indian (NRI) GSTINs from being accepted in the system. The original validation process was too restrictive, rejecting numbers that followed a different format. This change ensures all valid NRI GSTINs are now correctly processed.
Original PR description
Currently, valid GSTINs for certain Non-Resident taxpayers are rejected. **Steps to reproduce:** - Install the `l10n_in` module. - Navigate to Settings > Users & Companies > Companies. - Open `IN…
Currently, valid GSTINs for certain Non-Resident taxpayers are rejected. **Steps to reproduce:** - Install the `l10n_in` module. - Navigate to Settings > Users & Companies > Companies. - Open `IN Company` and set `Tax ID` to `9922JPN29001OSU` and try to `save`. **Error:** `The VAT number [9922JPN29001OSU] for partner [IN Company] does not seem to be valid.` `Note: the expected format is 12AAAAA1234AAZA` The system rejects the GSTIN, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root cause:** At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a different structure and are not matched by the existing regex. **Fix:** This commit ensures that valid NRI GSTIN formats are accepted during validation. Confirm with IN PO. [1]: https://services.gst.gov.in/services/searchtp [2]: https://github.com/odoo/odoo/blob/5e59f4b3def44aa84c06ba4c2ed34bf2e8da928f/addons/base_vat/models/res_partner.py#L712-L723 opw-5956299 Forward-Port-Of: odoo/odoo#251760
1 change
Resolved issues and error corrections
This update resolves an issue where bills were incorrectly grouped during import when linked to a purchase order. The fix ensures that bill lines are not grouped if a PO link exists, improving the accuracy of invoice processing. It also streamlines the process of ungrouping bills by linking the XML file used to create the move.
Original PR description
[FIX] account{_edi_ubl_cii}: don't group lines at import if link with PO
Move the grouping lines logic at bill import after the link with PO was made, so that we can make sure not to group if there's a link
Link the XML used to create the move in the `ubl_cii_xml_file` field to find it more easily when ungrouping
Also, call `ensure_one` in all grouping related method
no-task