Daily updates from Odoo
Friday, June 5, 2026
41 changes · master
New functionality added to Odoo
This update adds camera support within the Odoo Manufacturing (MRP) module, allowing users to visually inspect products and quality control processes. This enhancement improves accuracy and efficiency in identifying defects and ensuring product standards are met. The change is part of a broader Obox integration.
Original PR description
We now support scales and cameras in mrp using an Obox. see odoo/obox#181 task-6241713
This update adds unit tests for key Obox components – discover_obox, obox_report_action, and the json_tags_field widget. These tests enhance the reliability and stability of the Obox functionality, reducing the risk of future issues and improving overall product quality.
Original PR description
This commit adds unit tests for the following: - `client_actions/discover_obox.js` - `client_actions/obox_report_action.js` - `widgets/json_tags_field.js`
This update adds a new feature to the bank reconciliation widget that allows users to automatically reconcile bank statements on-demand. Previously, reconciliation was triggered only by a scheduled cron job. Now, users can quickly reconcile outstanding transactions, improving efficiency and reducing manual effort.
Original PR description
Add a "Run Auto Reconciliation" entry to the bank reconciliation widget cogs menu, allowing users to trigger the automatic reconciliation without waiting for the next cron run. Selecting the entry opens a wizard pre-filled with the active journal and a default starting date of today minus one month. On validation, the wizard collects the unreconciled bank statement lines of the chosen journal between the selected date and today, and runs _cron_try_auto_reconcile_statement_lines on them. A success notification is displayed and the bank reco view will reload the affected records. task-6095773
Enhancements to existing features
This update allows users to automatically associate return reasons with barcode scans during picking. By adding a return reason ID to the OBTRETU barcode, the system now correctly creates returns and links them to the selected reason, streamlining the return process.
Original PR description
This commit adapts OBTRETU to also fetch and select the return reason with the barcode. Details: Here we have added the `return.reason` ID after the OBTRETU barcode. When this barcode is scanned, it will also scan the return reason and pass that ID in the context of `_returnProducts`. Then it will retrieve that context and set it on the generated return for this delivery. For example is user select `return.reason` with ID 4 new barcode will be OBTRETU:4, so when user scan this QR in picking it will create return and set `return.reason` with ID 4. task-4160966 Community PR: https://github.com/odoo/odoo/pull/234112
This update streamlines the invoicing process by automatically reconciling invoices created directly from sales orders. Previously, this required manual steps; now, a new system passes a context key, enabling automatic reconciliation within the accounting system. This improves efficiency and reduces the risk of errors when generating invoices from sales transactions.
Original PR description
This commit will allow to automatically reconcile the invoice create from the sale order by passing a context key that will be used in the create_invoices function. task-5502964 Forward-Port-Of: odoo/enterprise#117875 Forward-Port-Of: odoo/enterprise#108546
This update ensures that stacked bar charts created within Odoo spreadsheets automatically include a total line, mirroring the standard behavior of charts in the main Odoo graph view. This improves consistency and makes spreadsheet charts more intuitive for users who are familiar with Odoo's charting capabilities. It addresses a visual discrepancy between spreadsheet and standard charts.
Original PR description
## Description When inserting a stacked bar graph view into a spreadsheet, enable showTotalLine on the generated chart definition. This keeps inserted spreadsheet charts aligned with the Odoo graph view, where stacked bar charts display the Sum line by default. Task: [5886277](https://www.odoo.com/odoo/project/2328/tasks/5886277)
This update adds detailed labels to LLM requests, identifying the source (like agents or web search) and the specific model used. This enhanced tracking allows us to better understand how our AI tools are being utilized and optimize token usage for cost efficiency.
Original PR description
Tag each completion request with a human-readable label identifying what issued it (the agent, web search, AI field, AI server action, ...) so token usage can be attributed to a given source-model combination. Agent-driven requests are prefixed with "Agent:" to set them apart from feature calls. Example: ``` AI: [Agent: Ask AI] gemini-2.5-flash-lite request [0.68s] - Tokens: 115 in (0 cached)|5 out|0 reasoning AI: [Agent: Ask AI] gemini-3-flash-preview request [2.64s] - Tokens: 5295 in (4050 cached)|79 out|186 reasoning AI: [web search] gemini-3-flash-preview request [21.24s] - Tokens: 562 in (226 cached)|708 out|1343 reasoning AI: [Agent: Odoo Image Generation Agent] gemini-2.5-flash-image request [8.25s] - Tokens: 423 in (0 cached)|1324 out|0 reasoning ``` Forward-Port-Of: odoo/enterprise#118811
This update enhances the creation of TSS (Tax Service Statements) in the Odoo Enterprise system by requiring user confirmation before creation. Once created through Fiskaly, the associated IDs are made read-only, and a copy button is added for easy record retrieval. This improves data accuracy and simplifies tracking.
Original PR description
In this commit: -------------- - We have introduced a “Create TSS” button. The system now asks for user confirmation before creating the TSS and client. - Once the TSS and client are successfully created in Fiskaly, the fields displaying their IDs become read-only. Additionally, a Copy button has been added to allow users to easily copy these values for later investigation or reference. task- 5457231
This update streamlines the import of invoices by introducing a generic reload flow. The system now intelligently prioritizes structured XML attachments over OCR-processed versions, ensuring data accuracy and efficiency. This change improves the reliability of invoice data within the system.
Original PR description
The account module now provides a generic reload flow for imported invoices. Keep the OCR-specific reload data behavior for invoices which must be handled by OCR, while letting invoices with regular imported source attachments fall back to the generic account reload flow. task-6159853 ----------------------------------------------------------------------------------------------------------------- In case there is a structured attachment like xml whether it's the original imported attachment or an embedded one, disable the OCR logic as structured attachments are 100% accurate and don't require digitization tokens so we should always prefer them, for example if the uploaded file is an xml having a pdf as an embedded attachment or the uploaded is a pdf having an xml as an embedded attachment then in both cases we will prefer the xml. task-6158911
Resolved issues and error corrections
This update ensures that the IPA reduction amount is now correctly displayed in the payroll summary tab (274.XX form). The change adjusts calculations to accurately reflect deductions and provides a clearer view of employee earnings. This improves reporting accuracy and transparency.
Original PR description
Previously, the IPA reduction was introduced on its own dedicated tab on the 274.XX form but was not shown in the summary tab. Added the IPA reduction to the Summary tab by updating the form view to display the "IPA Reduction" field inside the "Exempted Amounts" group, conditionally visible only when active. Modified the `_compute_amounts` method to: - Add `sme_exempted_amount` to the total `deducted_amount` when active. - Delay the calculation of `amount_to_pay` so it correctly reflects the updated total deductions. Task: 6268701
This update resolves compatibility issues with the latest o-spreadsheet library. The changes ensure the spreadsheet edition continues to function correctly after the library's update, improving stability and preventing potential disruptions to users. It addresses minor UI adjustments related to comment popups and layout configurations.
This update ensures all survey results spreadsheets now include a 'Participant' column, linking responses to the correct respondent. This was previously missing for surveys without login requirements, allowing for better tracking of survey data. The change preserves anonymity for truly anonymous surveys by leaving the column blank when no respondent information is available.
Original PR description
Problem: The "Analyze Results" spreadsheet only added a participant column when the survey required login (users_login_required). For surveys that do not require login, such as recruitment screening or surveys launched from CRM, no participant column was produced at all, so the exported answers could not be tied to a respondent. The response already stores partner_id, email and nickname, and the Participations list shows them regardless of login, so the omission was an oversight rather than anonymity protection. Solution: Always emit a "Participant" column, filled with the partner name and falling back to email then nickname. Responses carrying no identity stay blank, preserving anonymity for genuinely anonymous surveys.
This update ensures the HR payroll payslip run Kanban overlay continues to function correctly after a recent update to Odoo's core framework. The change replaces outdated XPath targeting with more reliable CSS selectors, guaranteeing consistent overlay functionality regardless of the underlying form structure. This prevents potential disruptions to payroll processing.
Original PR description
## Summary Companion to the `odoo/odoo` PR on the same `master-tref-pr-1-nby` branch, which migrates `web.KanbanHeader`'s root `<div>` from `t-custom-ref="root"` to `t-ref="this.rootRef"` (Owl 3 signals). The `hr_payroll` payslip-run kanban overlays that `<div>` with an xpath targeting `[@t-ref='root']`. After the migration that attribute no longer exists — and the same xpath also fails against the pre-migration `t-custom-ref` form. ## Change Switch both xpaths in `hr_payslip_run_kanban.xml` to `hasclass()` selectors so they match regardless of which ref form the upstream template uses, keeping the overlay working across the migration. ## Notes - odoo/odoo#267687
This change fixes a problem where DHL shipping labels weren't using the correct template dimensions, resulting in labels printed in the wrong size (8x4 instead of 6x4). The code now maps the selected label template to the correct DHL API format, ensuring accurate label dimensions are generated.
Original PR description
Issue ----- Labels generated with DHL do not respect the template (dimensions) set on the delivery method. Steps to reproduce ----- - Set up DHL - set label template as 6X4_A4_PDF - Create a delivery…
Issue
-----
Labels generated with DHL do not respect the template (dimensions) set on the
delivery method.
Steps to reproduce
-----
- Set up DHL
- set label template as 6X4_A4_PDF
- Create a delivery using the method
- Validate the delivery
> The generated label is in 8x4 inch format instead of 6x4 full page
Explanation
-----
All info below was found in DHL's API doc from the following YAML file
https://developer.dhl.com/sites/default/files/2026-05/dpdhl-express-api-3.3.0.yaml
There are 2 issues with the current implementation regarding the label format.
1. The formats defined on the model (the `ProviderDHL` `delivery.carrier`) do not match the ones of the API. From the API, the accepted values are the following:
- ECOM26_84_A4_001
- ECOM26_84_001
- ECOM_TC_A4
- ECOM26_A6_002
- ECOM26_84CI_001
- ECOM26_84CI_002
- ECOM26_84CI_003
- ECOM_A4_RU_002
- ECOM26_84_LBBX_001
- ECOM26_64_LBBX_001
(values taken from the excerpt below)
```
templateName:
description: >-
Please enter DHL Express document template name.
<BR> Sample Transport label
templates:<BR> ECOM26_84_A4_001
<BR> ECOM26_84_001 - default<BR>
ECOM_TC_A4<BR> ECOM26_A6_002<BR>
ECOM26_84CI_001<BR> ECOM26_84CI_002 - supported
single customer barcode<BR> ECOM26_84CI_003 -
to be used if customer barcodes are used<BR>
ECOM_A4_RU_002<BR>
ECOM26_84_LBBX_001 - supported for loose BBX shipment<BR>
ECOM26_64_LBBX_001 - supported for loose BBX shipment<BR>
[...]
type: string
maxLength: 25
example: ECOM26_84_001
```
[...]: additional info unrelated to labels (useful only for other `typeCode` values)
Since `ProviderDHL` is a model, the `dhl_label_template` selection values cannot be changed and must thus be mapped to the corresponding API values.
- 8X4_A4_PDF => ECOM26_84_A4_001
- 8X4_thermal => ECOM26_84_001
- 8X4_A4_TC_PDF => ECOM_TC_A4
- 6X4_thermal => ECOM26_A6_002
- 6X4_A4_PDF => ECOM26_A6_002
- 8X4_CI_PDF => ECOM26_84CI_001
- 8X4_CI_thermal => ECOM26_84CI_001
- 8X4_RU_A4_PDF => ECOM_A4_RU_002
- 6X4_PDF => ECOM26_A6_002
- 8X4_PDF => ECOM26_84_001
Couple notes about this matching:
- There is no 6x4 in the API, so A6 is used instead (A6 is 105x148mm, 4x6 is 101.6x152.4mm so not a perfect match but the best option still)
- ECOM26_84_001 and ECOM26_A6_002 are used as default values for the respective formats when there is no exact match possible (eg 6x4 only has one option in the API, the default one)
- "A4" is being ignored, because of point 2
2. There is a specific field to force the label to be in A4 format (according to the API, see excerpt below)
```
fitLabelsToA4:
description: >-
To print respective Transport Label and Waybill document into
A4 margin PDF.<BR> Note:
ECOM26_A6_002,ECOM26_84CI_001,ECOM26_84CI_002,ARCH_6X4,ARCH_8X4
template. <BR> This option is applicable only
for PDF encodingFormat selection.<BR> false:
Transport Label and Waybill document will use default margin
settings (default behavior) <BR> true:
Transport Label and Waybill document will print into A4 margin
PDF
type: boolean
example: false
```
-----
Ticket:
opw-6148713
Forward-Port-Of: odoo/enterprise#117281This update resolves an issue where large product weights (over 150kg) triggered errors when calculating shipping rates through Sendcloud in the e-commerce flow. The fix ensures that the system correctly identifies the need to split orders into multiple packages, preventing errors and improving order processing.
Original PR description
Issue ----- Traceback when trying to get a rate through the e-commerce if the order has to be split into multiple packages due to weight being too high. Steps to reproduce ----- - Setup Sendcloud…
Issue ----- Traceback when trying to get a rate through the e-commerce if the order has to be split into multiple packages due to weight being too high. Steps to reproduce ----- - Setup Sendcloud delivery method - make it available in e-commerce - Create a 150kg product and publish it - Go to e-commerce - Add the product to cart - Checkout the cart > Traceback Cause ----- We retrieve the order's weight through the context. https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L108 If the call to `_get_shipping_rate` returns that the delivery requires multiple packages, we go into https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L126-L128 If `order_weight` was not present in the context, this will cause an error in `sendcloud_convert_weight` since it expects a numerical value but receives the `None` fallback. This context key is only present when going through `choose.delivery.carrier` (so not in the e-commerce flow). https://github.com/odoo/odoo/blob/058e640e6687ed3f709dc846f0fa7a1f45226849/addons/delivery/wizard/choose_delivery_carrier.py#L69 ----- Ticket: opw-6210398 Forward-Port-Of: odoo/enterprise#119186 Forward-Port-Of: odoo/enterprise#117028
This update resolves an issue where a validation error was incorrectly triggered when setting an intrastat code on product templates. The change now accurately checks for product templates with dynamic attributes and no variants, ensuring the error is raised only in the intended scenario. This improves data integrity and prevents unnecessary errors during product template creation.
Original PR description
Problem: When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template. Solution: The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error. Forward-Port-Of: odoo/enterprise#118986
This update corrects a minor error in the AI service that prevented the system from correctly handling responses from Google's Gemini models. Specifically, the code was incorrectly trying to access an ID field that wasn't always present, leading to a system error. This fix ensures consistent and reliable operation of the AI tool call functionality.
Original PR description
The functionCall parts returned by Gemini may or may not have an id depending on the LLM model used (Gemini 2.5 doesn't include an id in functionCall parts but Gemini 3 does). So, there is some code that checks whether there is an id and generates a uuid if none exists. This code had a bug because it was accessing the id directly on the functionCall part which may not exist and a keyerror was thrown in such cases. This commit solves the issue by using get instead of direct key access. Forward-Port-Of: odoo/enterprise#118837
A recent test failure related to demo data installation has been resolved. The fix ensures that a simulation offer is hidden during testing, preventing errors that occurred when expecting an empty list view. This improves the reliability of the system's testing process.
Original PR description
**Problem**: The test fails when demo data is installed because some steps expect an empty list view. **Fix**: Ensure the simulation offer is hidden by applying a custom filter on the simulation employee Task: 6246575 Forward-Port-Of: odoo/enterprise#119142 Forward-Port-Of: odoo/enterprise#118358
This update fixes an issue where auto-filling fields in sign requests was causing unintended side effects. The changes isolate the auto-fill functionality, preventing these unexpected behaviors and ensuring data integrity within the sign request process. This improves the reliability and accuracy of sign request creation.
Original PR description
task-6269354 Forward-Port-Of: odoo/enterprise#119148
This update fixes a bug in the Thai accounting localization module that prevented users from exporting the P.P.30 - VAT Report. The missing export buttons have been restored, allowing users to generate reports in various formats. This ensures accurate tax reporting compliance for Thai businesses.
Original PR description
Current behavior: -- Missing buttons in the P.P.30 report Expected behavior: -- When clicking on the wheel icon for the P.P.30 - VAT Report, the 3 buttons should show Export for RD Prep, Sales Tax Report, Purchase Tax Report Steps to reproduce: -- In Master version, 1.Install Thai accounting localization module. 2. Navigate to Accounting > Reporting > Tax Report. 3. Select Report: P.P. 30 - VAT Report (TH) from the report dropdown. 4. Click on the gear icon next to "Tax Return". 5. Observe that the export options are missing and only "Copy to Documents" and "Insert in article" are available. Cause of the issue: -- Wrongfully removed the buttons. Caused by commit: https://github.com/odoo/enterprise/commit/ccee902284ab2fd91217ae9a59c1557b7f49433f opw-6267145
This update resolves an issue where negative line items in Mexican CFDI invoices were incorrectly distributed across other lines. The change addresses a conflict introduced by new features like discounts and down payments, making the previous method for checking line types obsolete. This ensures accurate CFDI invoice processing.
Original PR description
In MX CFDI, negative lines are not allowed so they are distributed over other lines. But because this PR introduces some other `special_type` like `global_discount` and `down_payment`, it becomes useless to check `base_line['special_type'] == False`. Fix for https://github.com/odoo/odoo/pull/267435 task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#119327 Forward-Port-Of: odoo/enterprise#119254
This update addresses a technical issue related to the Spreadsheet Edition's pivot table layout configuration. The changes ensure compatibility with a recent update to the core Odoo spreadsheet functionality, resulting in a smoother and more reliable user experience. This primarily impacts how users customize and manage pivot table layouts.
This update resolves an issue where the Studio sidebar's checkboxes had a broken appearance due to a conflict with Bootstrap's styling. The fix globally applies a background image to indeterminate checkboxes, eliminating the need for a separate workaround and ensuring consistent display across the Enterprise module.
Original PR description
The Studio sidebar had its own `&:indeterminate { background-image: url(...) }` override to work around the broken Bootstrap indeterminate dash. This is now handled globally (see PR #268326 / master-fix-indeterminate-bg-image-jesc): `.form-check-input:indeterminate` sets `background-image` directly, bypassing the Bootstrap CSS variable that carries the broken `stroke='unset'`.
source: `web_enterprise/static/src/scss/bootstrap_overridden.scss` sets `$component-active-color: unset !default;` before `web/bootstrap_overridden.scss` in the bundle, so Bootstrap's indeterminate SVG compiles with `stroke='unset'` and the dash is invisible everywhere except where `background-image` is overridden directly.
fix: the global `.form-check-input:indeterminate { background-image: url(...) }` rule in `web/static/src/core/checkbox/checkbox.scss` now covers all checkboxes, making this local Studio override redundant.This update fixes an issue where the DIAN-compliant electronic invoices generated for Colombia were incorrectly using a generic line number instead of the correct document ID. This prevented the invoices from passing validation checks by the DIAN platform and external systems. The fix ensures invoices now accurately reflect the required document ID, resolving compatibility problems.
Original PR description
### Issue When generating the attached document (AttachedDocument) for Colombia, the parent document reference tag <cbc:ID> incorrectly exported a generic line counter instead of the actual document…
### Issue
When generating the attached document (AttachedDocument) for Colombia, the parent document reference tag <cbc:ID> incorrectly exported a generic line counter instead of the actual document identification number
While the DIAN platform itself accepted the file, this caused rejections in external validation tools and third-party software because they could not resolve the link back to the original invoice
DIAN Documentation: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo_tecnico_factura_electronica_vr_1_7_2020.pdf
On page 213 there is an example for ParentDocumentLineReference
On page 216 there is the specification that does not show any check
Example of the incorrect XML structure:
```xml
<cac:ParentDocumentLineReference>
<cbc:LineID>1</cbc:LineID>
<cac:DocumentReference>
<cbc:ID>1</cbc:ID>
</cac:DocumentReference>
</cac:ParentDocumentLineReference>
```
Expected XML structure:
```xml
<cac:ParentDocumentLineReference>
<cbc:LineID>1</cbc:LineID>
<cac:DocumentReference>
<cbc:ID>SETP990001021</cbc:ID>
</cac:DocumentReference>
</cac:ParentDocumentLineReference>
```
### Cause
In the template, the value for <cbc:ID> was retrieved using `parent_document.get('id')` which fetched the sequential loop index https://github.com/odoo/enterprise/blob/cd25713fd2c35737d98db29df72b2d07ae9146e8/l10n_co_dian/views/templates.xml#L272-L275
The dictionary parsing logic did not extract the true document identifier from the XML tree response or the original XML data https://github.com/odoo/enterprise/blob/13dc30679e382df5845993c880a97df600c39ed4/l10n_co_dian/models/l10n_co_dian_document.py#L429-L432
### Steps to reproduce
- Install `l10n_co_dian`
- Setup DIAN configuration
- Generate an attached document for a commercial event or invoice
- Open the generated XML file
Before the fix, the `<cac:ParentDocumentLineReference>/<cac:DocumentReference>/<cbc:ID>` tag contains a technical integer like "1" instead of the official document sequence number
opw-6164321
Forward-Port-Of: odoo/enterprise#118319This update corrects a previous issue where website forms were incorrectly translated into the user's language instead of the website's default language. Now, all forms displayed on the website will automatically use the website's language setting, ensuring a consistent and accurate experience for users regardless of their browser language.
Original PR description
When the website is in a different language A to the user language B, forms are translated into the language B of the builder. They should be in the website default language. Task-6171271
This update fixes a technical error that prevented refunds in the Colombian Point of Sale (PoS) system. The issue stemmed from outdated code referencing an old function name, which caused a traceback during the refund process. This change ensures refunds are processed correctly for Colombian customers.
Original PR description
**Steps to reproduce:** - Setup a columbian company, DIAN should be in demo mode - Go to the PoS and make a sale with a columbian customer - Refund it - A traceback appears **Why the fix:** Some legacy code was left untouched when we changed the old **get_partner()** to the new **getPartner()** so we got a traceback as this function does not exist anymore. We also change the **set_partner(partner)** to **setPartner(partner)** as it was also forgotten. opw-6231856 Forward-Port-Of: odoo/enterprise#118651 Forward-Port-Of: odoo/enterprise#118054
This update corrects a bug in the appointment Gantt view that caused new bookings to default to midnight instead of the intended start time. The fix replaces a mistaken override with the correct method, ensuring accurate booking start times are used.
Original PR description
The [commit] replaced the `onAddClicked` method with `_onNewClicked`, and updated all related calls and overrides accordingly. However, the appointment Gantt view override was mistakenly changed to override a non-existent `_onAddClicked` method, leaving the custom logic unused. As a result, bookings created through the `New` button in the Gantt view used midnight (12:00 AM) instead of the time derived from the custom logic as the default start datetime. This commit fixes the issue by correctly overriding `_onNewClicked`. [commit]: https://github.com/odoo/enterprise/commit/bc779c9ec5295f8d1fe06e8432c518c78c606ea2 Forward-Port-Of: odoo/enterprise#118799
This update resolves an issue where inserting a prompt banner using the `/prompt` command wouldn't allow users to undo the banner's creation. The fix ensures that undo functionality correctly removes prompt banners, improving usability and preventing unexpected content.
Original PR description
Problem: After inserting a prompt banner, undo does not remove it. Cause: History commands were ignored when the selection was inside the prompt banner, preventing undo from handling banner insertion. Solution: Handle history commands even when the selection is inside the prompt banner. Steps to reproduce: - Insert a prompt banner using `/prompt` + Enter. - Press Ctrl + Z. - Observe that the banner is not removed. task-6230530 Forward-Port-Of: odoo/enterprise#118248 Forward-Port-Of: odoo/enterprise#117845
This update fixes an issue where check amounts weren't being properly rounded in the Philippines (PH) version of Odoo. Previously, the check amount in words displayed with a decimal component and 'ONLY'. Now, the decimal is rounded, ensuring accurate check formatting and compliance with PH regulations.
Original PR description
Current behaviour: --- When paying with checks, the amount is not rounded in the check amount in words string. Steps to reproduce: --- 1. Switch to PH company 2. Set setting Check Layout as "Print Check - PH" 3. Create a new vendor bill 4. Add a product with a specific price like 91490.15 5. Confirm the bill, click on Register Payment 6. Select Payment Method "Checks", Create Payment 7. Go to the payment, Amount in Words is wrong 8. Ninety-One Thousand Four Hundred Ninety And 15000000001/100 ONLY Expected behaviour: --- The decimal amount should be rounded, and "ONLY" shouldn't appear. Fix: --- Rounded the pay amount And backported: https://github.com/odoo/enterprise/commit/bb6c9848665709c14c5113b2c98976f869cd473b opw-6058344 Forward-Port-Of: odoo/enterprise#117679 Forward-Port-Of: odoo/enterprise#116717
This update resolves an issue where the company's XBRL reports were failing validation by the NBB due to missing data disclosures. The changes add the necessary disclosures, ensuring reports pass validation and comply with regulatory requirements. This prevents potential delays or errors in report submission.
Original PR description
This commit adds missing explanatory disclosure datapoints to the generated XBRL report. The missing disclosures resulted in failing validation when report is submitted to NBB. The datapoints are only added if the original value was non-zero. For example, the tangible assets disclosures are only added if the tangible assets in balance sheet is non-zero. Additionally, only disclosures that were reported as causing a failing validation were added. task-5977199 Forward-Port-Of: odoo/enterprise#117853
This update corrects a bug that prevented quality checks from running correctly when a product's manufacturing operations were modified. The change adjusts how the system handles lot references, ensuring compatibility with recent Odoo updates. This resolves an error related to invalid data and improves the reliability of the quality control process.
Original PR description
## Steps to reproduce: - Install the `quality_mrp` module. - Create a new product. - Create a Quality Point with: Type: Measure, Control per: Product/Operation Operations: Manufacturing - Create and…
## Steps to reproduce: - Install the `quality_mrp` module. - Create a new product. - Create a Quality Point with: Type: Measure, Control per: Product/Operation Operations: Manufacturing - Create and confirm MO for the product. - Update the Quality Point: Remove the 'manufacturing' operation type and add 'receipts' type. Change Control per to 'Quantity'. - Open the MO and start a quality check. - Enter an invalid measure and try to validate it. ## Error: `AttributeError - 'mrp.production' object has no attribute 'lot_producing_id'` ## Cause: Since commit https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e, the `lot_producing_id` field on MO was replaced by the Many2many field `lot_producing_ids`. Invalid references to the removed field lead to an error. ## Fix: This commit uses the first lot/serial from the MO. Note: Multiple produced lots are only possible for serial-tracked products. sentry-7511513479 Forward-Port-Of: odoo/enterprise#119231
A recent update incorrectly removed filtering during automatic Stripe expense reconciliation, causing all expense lines to be incorrectly reconciled. This fix ensures that only the relevant transaction lines are reconciled, resolving a critical issue with Stripe expense reporting and preventing inaccurate financial records.
Original PR description
In 1f6f4ee3, the account reconciliation filtering was removed from the automatic reconciliation. This broke the reconciliation as all lines would be taken into the reconciliation after-hand Steps to reproduce: - Install `hr_expense_stripe_demo` - Create a Stripe account in the settings - Refresh the account status until validated - Top-up the account in the accounting dashboard - Create a virtual card and activate it - Simulate a transaction with capture - Submit the expense created after checking it has at least one tax - Approve and post the expense - Check the reconciled transaction in the stripe journal - All the lines of the expense move have been reconciled Forward-Port-Of: odoo/enterprise#119269
This update resolves an issue where users were blocked from uploading documents to requests linked to records they didn't have full access to. By adding a '.sudo()' function to the attachment creation process, users can now successfully upload documents, regardless of their access rights to the related record. This improves usability and ensures requests can be properly documented.
Original PR description
Issue: Users are currently blocked from uploading requested documents if the request is linked to a record they do not have access to (e.g., User A links Record X to a request assigned to User B, but User B lacks read/write access to Record X). The system throws an error because the user cannot create an attachment for that record. Fix: Add .sudo() on the attachment creation process. task-6107099 Forward-Port-Of: odoo/enterprise#113698
This update fixes an issue where payments for Mexican invoices were being sent to CFDI multiple times, leading to inaccurate reporting. The fix ensures the 'Update Payments' button only appears after the full invoice payment is reconciled, preventing duplicate submissions and maintaining accurate financial records.
Original PR description
Issue: Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI. Steps to reproduce: - In a Mexican company - Create an invoice A of…
Issue: Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI. Steps to reproduce: - In a Mexican company - Create an invoice A of $40 to Inmobiliaria CVA - Confirm and send to CFDI - Go to bank, create a new Bank transaction of $80 - reconcile with Invoice A - Go to invoice A => click on button "Update payments" (it doesn't appear in previous versions) - Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A - Create an invoice B of $40 to Inmobilira CVA - Confirm and send to CFDI - reconcile the transaction with Invoice B - Go to invoice B - Click on button "Update payments" - Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B Invoice A payment was sent twice to CFDI Expected behavior: - The "Update payment" button should appear only once the invoice payment is fully reconciled. Current behavior: - The update payment button appear once the invoice is reconciled with a payment. The method `_l10n_mx_edi_cfdi_invoice_get_payments_diff` is called twice, once to check whether it's needed to display the "Update button" and once when you try to update the payment (called only after clicking on said button). opw-5432421 Forward-Port-Of: odoo/enterprise#119244 Forward-Port-Of: odoo/enterprise#108355
This update fixes a calculation error in the Canadian Profit and Loss report. Previously, operating expenses were incorrectly added to gross profit, leading to inaccurate Net Operating Income figures. Now, the report correctly calculates Net Operating Income as Gross Profit minus Operating Expenses, ensuring accurate financial reporting.
Original PR description
Steps to reproduce: 1. Install the Accounting app with the Canadian localization (l10n_ca) 2. Open the Profit and Loss report 3. Review the Net Operating Income line Issue: The Net Operating Income value is incorrectly calculated; operating expenses are being added to gross profit instead of subtracted, producing an incorrect result. Expected behavior: Net Operating Income should equal Gross Profit - Operating Expenses opw-6265192 Forward-Port-Of: odoo/enterprise#119165
This update dynamically adjusts the number of pages processed when uploading PDFs to the AI chat feature. Previously, uploads were limited to 5 pages. Now, the system can handle larger documents, improving the efficiency of AI-powered conversations. This change ensures a smoother experience for agents and users.
Original PR description
Prior to this commit, when uploading a document (i.e. during a chat with an agent). Only a part of its pages would get parsed and sent to the API (5 pages). With this commit, the number of pages is made dynamic by the use of a new context key `ai_max_pdf_pages`. This variable is still set for the document autosorting features since it is not required to read the full document. Default value is None (no limit). Forward-Port-Of: odoo/enterprise#119452 Forward-Port-Of: odoo/enterprise#119338
Features or functions removed from Odoo
This pull request removes redundant sudo permissions that were incorrectly added when calling the image generation tool. The change corrects a prior mistake and simplifies the system's security posture. This ensures the application functions as intended without unnecessary elevated privileges.
Original PR description
The sudo used for calling the image generation tool isn't needed and shouldn't have been added here 99f76c1 in the first place. So, it is removed. Forward-Port-Of: odoo/enterprise#119220
Code cleanup and technical improvements
This update simplifies access to the document portal by using a dedicated URL (/my/documents) instead of an accidental override. This change removes unnecessary complexity and improves the user experience for accessing and managing documents.
Original PR description
Currently, the general webclient route is overriden
to manage custom documents URLs with access_token.
The code needs to work around several things to make it
work:
- manage db and auth explicitely
- override `readonly`
With this commit, we now use a new dedicated route
which is more specific than the normal webclient route.
It doesn't need any of the workarounds and it's generally
easier since it doesn't involve any override.
`/odoo/documents_portal` only resolved by accident: it matched the
`/odoo/<subpath>` route overriden by `documents`, passed the
`subpath.startswith('documents')` check, and the literal string
`documents_portal` was then interpreted as an access token. The
portal user was redirected to `/documents/documents_portal`, where
`documents_portal` was treated as an access token, which is
nonsense.
Expose the portal entry under `/my/documents` URL instead.This update resolves a technical issue related to an outdated React component method (useLayoutEffect) that was causing performance problems and potential instability. Replacing it with the recommended onMounted + onPatched approach ensures the system runs smoothly and aligns with current Odoo standards.
Original PR description
Replaces useLayoutEffect with onMounted + onPatched WHY: UseLayoutEffect is deprecated in OWL3 Community PR: https://github.com/odoo/odoo/pull/267715
This update replaces `useState` with `proxy` across several Odoo addons (Owl3) to enhance stability and performance. This refactoring primarily impacts the web_enterprise, web_gantt, web_grid, and web_studio modules, ensuring a smoother user experience and more reliable operation.
Original PR description
In Owl3, uses of `useState` or replace with `proxy`. This commit changes all those uses for addons in the range [w..]. *: web_enterprise,web_gantt,web_grid,web_map,web_mobile,web_studio,web_studio_ai_fields,website_generator,website_helpdesk_forum,website_knowledge,whatsapp,
This update replaces a reliance on global website settings with a context-based approach, ensuring consistent website behavior across different Odoo environments (like CRON jobs). This change improves the stability and predictability of website-dependent features, resolving a potential issue with inconsistent website identification. The goal is to eliminate fallback mechanisms for a more robust system.