Wednesday, February 25, 2026
30 changes · saas-19.2
Enhancements to existing features
This update adds the representation of 'page 2 bis' to the 390 tax report format used in Spain. This enhancement ensures that Spanish businesses can accurately report their financial data to tax authorities, complying with local regulations. It's a key step in supporting Spanish-specific reporting requirements within the Odoo Enterprise system.
Original PR description
In this commit: - We are adding representation of page 2 bis to the 390 boe.txt task-5881396 Forward-Port-Of: odoo/enterprise#106861
This update enhances UrbanPiper's functionality by allowing discounts to be applied to individual products within orders, rather than the entire order. This ensures that order totals, payments, and taxes accurately reflect these line-level discounts, improving pricing accuracy for our clients.
Original PR description
Before this commit: ================ - Discounts were only applied to the entire order. - Product-level (line) discounts were not handled in UrbanPiper. After this commit: ================ - Product-level discounts can be applied to individual products in UrbanPiper. - Order totals, payments, and taxes now correctly reflect line-level discounts. Task - 4977960 Forward-Port-Of: odoo/enterprise#108372 Forward-Port-Of: odoo/enterprise#97114
This update clarifies that commission adjustments can only be created using users who are part of an approved sales plan. Previously, adjustments could be linked to any active plan, leading to confusion. This change improves the accuracy and usability of commission management within the system.
Original PR description
Before this commit, when defining ajustment, the add_user_id and reduce_user_id could belong to any kind of active plan. It would make difficult to select the correct user when multiple plans were available. This commit ensure only approved plan can be used to create ajustments. Forward-Port-Of: odoo/enterprise#106637
Resolved issues and error corrections
This update resolves a bug preventing users from saving invoices in the Mexico (MX) edition of Odoo Enterprise. The issue stemmed from a requirement for a payment method when the payment policy was set to 'PUE,' which blocked saving functionality. The fix allows payment methods to be edited until the invoice is sent to the SAT, maintaining user flexibility.
Original PR description
After this commit 1e702a5, a bug in the invoice form view appeared that made it difficult (to not say impossible) to reset an invoice or do any operation that involves to save the invoice. How to reproduce (there are multiple ways but this is the easiest): 1.- Using mx demo company INNOVACION y DESARROLLO SA de CV 2.- Create an invoice with INMOBILIARIA CVA as contact 3.- Post the invoice 4.- Try to send or do a modification and save 5.- Missing required fields notification will appear. This error happens since the payment way is required if the payment policy is PUE but is not editable when not in draft, causing this deadlock. There multiple ways to fix this, but the simplest way and maintaining the flexibilty on the user to decide what value to use, we keep the logic on the view but make the payment method editable until the invoice is sent to the SAT just like with the payment policy. target: saas-19.2 -> master task-5962060
This update corrects an error that occurred when moving leads from a previous year to a 'won' stage in the CRM. The fix ensures the system handles leads with dates spanning multiple years correctly, preventing a technical error. This improves the reliability of lead management.
Original PR description
Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year. ### **Steps to Reproduce:** 1) Install CRM without demo data. 2) From the…
Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year.
### **Steps to Reproduce:**
1) Install CRM without demo data.
2) From the `CRM>Configuration>Stages` make `new` stage as **'won'** stage.
3) Create a lead with dated in the past (e.g., 30-12-2025 by changing system date)
and with some expected_revenue.
4) Change the system date to today and move the lead to the Won stage.
Ref Video: https://drive.google.com/file/d/18OCQ4Tl6Co_oh28XNag3qjxMkXJNSMOh/view?usp=sharing
### **Error:**
`TypeError: '<' not supported between instances of 'NoneType' and 'float'`
### **Root Cause:**
When a lead is moved to a won stage, `_get_rainbowman_message` is called and computes the values for `max_{team,user}_{31,7}`. However, when the lead spans different years, the condition of SQL query at [1] fails(because 2025 != 2026) due to which SQL query return null from the MAX() Function. As a result, subsequent comparisons at [2] fail, raising an Error.
### **FIX:**
Introduce small helper method(`_is_lower_than_expected_revenue`) to ensure comparisons
across different years only happen when we have meaningful numeric values.
[1]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1218
[2]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1232
**opw-5484887**
**sentry-7026119584**
Forward-Port-Of: odoo/odoo#244938This update allows branch companies to see and use contacts belonging to their parent company when creating invoices or vendor bills. Previously, branch companies were restricted from selecting these contacts. This change ensures seamless multi-company operations and improves workflow efficiency.
Original PR description
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills. ### **Steps to reproduce:** 1) Create a…
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.
### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B).
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.
### **Current/Buggy Behavior:**
The contact does not appear in the search results.
### **Expected Behavior:**
The contact should be selectable.
### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.
However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].
This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.
### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.
[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896
**opw-5484611**
Forward-Port-Of: odoo/odoo#244671This update resolves a visual issue affecting course cards on the website. Previously, descriptions containing links caused layout problems due to an incorrect assumption about HTML structure. This fix restores the original card design and ensures course cards display correctly, even when users include links in their descriptions.
Original PR description
This PR fixes an issue introduced by Commit[^1]. In Commit[^1], we decided to review the course card layout by removing the individual links that were wrapping the title, the cover image, and the…
This PR fixes an issue introduced by Commit[^1]. In Commit[^1], we decided to review the course card layout by removing the individual links that were wrapping the title, the cover image, and the description. | 19.0 and above | This PR | |--------|--------| | <img width="333" height="392" alt="image" src="https://github.com/user-attachments/assets/3dce73b3-0ce9-486e-b1de-f88a74e52e05" /> | <img width="313" height="381" alt="image" src="https://github.com/user-attachments/assets/25d75970-7f55-4967-87ba-3ecf5710835d" /> | #### Steps to reproduce: 1. Go to `website_slides` 2. Create a new course 3. Go to the description tab 4. Insert a link in the description and save 5. Go to the frontend to see the courses list 6. Course cards with a description containing a link are visually broken. While this looked like an improvement because it simplified the DOM, it was done with the assumption that the course card could not contain another link. This is, of course, not the case, as the description field is editable by the user and can therefore contain a link. Because this is not valid HTML, the layout removes all nested links and renders them separately. Since all the classes related to the card design are applied to that `<a>` tag, all links are rendered with a border and other styling. This PR fixes the issue by reassigning all the card styles to the card container. We then reassign each property to the corresponding element, adapt the styles to mimic the original card design, and hide extra links that are rendered empty. This should at least fix the layout for users. [^1]: https://github.com/odoo/odoo/commit/f632b8a9e74a050288e3ec75a4f49ae3ecb551d6 task-5957910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249969
This update resolves an issue where the HTML editor component was crashing due to aggressive sanitization by DOMPurify. The fix involves temporarily encoding and decoding values within the editor's data attributes to avoid conflicts with the sanitization process. This ensures the editor functions correctly without compromising security.
Original PR description
Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5 in Odoo), the JS sanitization process aggressively removes html attributes with `-->`, `<style` and `<title` for…
Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5 in Odoo), the JS sanitization process aggressively removes html attributes with `-->`, `<style` and `<title` for security reasons (see [1]). However `html_editor` embedded components use `data-attributes` (`data-embedded-props` and `data-embedded-state`) to store various kind of data as a JSON string. Obviously, such JSON strings easily match the DOMPurify regex and these attributes are therefore removed, which results in an Editor crash. There are multiple reasons why such values are acceptable as is for the `html_editor` usage: - only `HTMLElement` instances are sanitized, never a string, therefore there is no `DOMParser` to trick with invalid HTML. - values in these attributes are always/exclusively parsed as JSON strings, and the editor will crash if the value is not a legit JSON. - values in these attributes are HTML escaped by the python sanitizer when the serialized html is sent to the server. - values in the JSON parsed object are at worst rendered as plain text (never as HTML or other parsed formats). - values in the JSON parsed object are never executed as JS (only serializable primitives are stored). Therefore, the suggested solution is to encode the values during sanitization, and decode just after, to keep the rest of the codebase simple and explicit. [1]: https://mizu.re/post/exploring-the-dompurify-library-hunting-for-misconfigurations#dompurify-gt-3.1.2-safe-for-xml task-5960707 Forward-Port-Of: odoo/odoo#250475 Forward-Port-Of: odoo/odoo#250210
This update fixes a problem where subcontracting production orders weren't correctly displaying all associated move lines. By ensuring each move line is linked to the receipt picking, the 'Move' detail operations button now accurately shows all serial/lot numbers, improving traceability and reducing confusion for users.
Original PR description
*: mrp_subcontracting Issue: --------------------------------- When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New…
*: mrp_subcontracting Issue: --------------------------------- When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New Production" action, only the `first serial number line` appears in the "Move" detail operations smart button. Although all move lines are correctly created on the move, this behaviour is confusing for the user. Steps to reproduce: --------------------------------- 1. Install the `mrp_subcontracting_purchase` module. 2. Create a serial-tracked product and its subcontracting BoM. 3. Create a PO with a subcontracting vendor and a product quantity greater than 1. 4. Confirm the PO and validate the resupply. 5. Open the receipt and click on the "Subcontracting Production" smart button. 6. Generate serial numbers for the product. 7. Validate the receipt and open the "Move" detail operations smart button. 8. Only one line (the first serial number) is shown, while the move actually contains all move lines. Cause: --------------------------------- When serial numbers are generated from the subcontracting MO view, or when a new MO is created using the "Create New Production" action introduced in [PR](https://github.com/odoo/odoo/pull/218377), new move lines are created without setting the `picking_id`. As a result, these move lines are linked to the stock move but not directly to the picking. Since the "Move" detail operations smart button relies on the picking’s `move_line_ids`, the newly created move lines are not displayed. With this commit: --------------------------------- The `picking_id` is now set on newly created move lines. This ensures that all move lines are directly linked to the picking, allowing the "Move" detail operations smart button to display all serial/lot lines correctly and improving traceability for the user. And also When working with a subcontracting order, if the user opens the lot/serial number generation wizard from the subcontracting production and directly clicks 'Apply' without creating or assigning any lot/serial number, Odoo raises the following traceback: `IndexError: tuple index out of range` This issue has also been fixed here. Forward-Port-Of: odoo/odoo#243988
This update resolves issues preventing early bill printing with the Italian fiscal printer. The fix addresses a traceback caused by incorrect data handling and ensures the receipt prints correctly, improving the restaurant's order fulfillment process.
Original PR description
Fix 1: ------- Using the early receipt printing option leads to a traceback when using the italian fiscal printer. Steps to reproduce: ------------------- * Setup the italian fiscal printer for a…
Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback
Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.
To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.
After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.
This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4
If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```
Those two last issues are solved by not syncing the data to the server when we simply print the bill early.
-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt
Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.
We backport this fix that enables basic receipt printing and alter it to also work with early printing.
Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97
There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.
There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.
opw-5387572
Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />
Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />
Forward-Port-Of: odoo/enterprise#108161
Forward-Port-Of: odoo/enterprise#105511This update fixes a potential issue where special products used in point-of-sale (like those with discounts or tips) could be accidentally deleted or archived. This change adds a safeguard to ensure these products remain available in the POS, minimizing errors and maintaining accurate sales data. It's a critical fix to prevent disruptions to the point-of-sale system.
Original PR description
Before this commit, it was possible to delete or archive some products even if they were special for the pos (discount, tips, settle, etc.). This commit adds a mechanism to prevent this and reduce the risk of errors linked to missing products in the pos. Enterprise PR: https://github.com/odoo/enterprise/pull/95789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230865 Forward-Port-Of: odoo/odoo#229074
This update fixes a problem where users attempting to print resumes with incorrect templates received a generic error message. Now, when an invalid template is used, a detailed traceback is displayed, making it easier for support teams to diagnose and resolve the issue. This improves the user experience and streamlines troubleshooting.
Original PR description
Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong. **Steps to produce:** * Install `hr` with demo data * Modify the view…
Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong. **Steps to produce:** * Install `hr` with demo data * Modify the view `report_employee_cv` by adding `<div t-if=o.no/>` * Print resume of any employee **Observed Behavior:** Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" /> **After:** <img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related: https://github.com/odoo/enterprise/pull/100142 opw-5167898 Forward-Port-Of: odoo/odoo#250286 Forward-Port-Of: odoo/odoo#237262
This update fixes a problem where users wouldn't receive helpful information when trying to print PDF payroll reports with incorrect document layouts. Now, when an invalid layout is used, a detailed traceback is displayed, making it easier to identify and correct the issue. This improves the user experience and troubleshooting of payroll reports.
Original PR description
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. *…
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. * Settings > Configure Document Layout then Edit Layout * Add non-existent field `<div t-if='o.no'/>` * Payroll > All payslips > print any payslip **Observed Behavior:** * Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" /> **After:** <img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related:https://github.com/odoo/odoo/pull/237262 opw-5167898 Forward-Port-Of: odoo/enterprise#108438 Forward-Port-Of: odoo/enterprise#100142
This update fixes a bug in the Odoo 19.0 version where the 'Copy Existing Operations' button was missing from BoM operation tabs. This prevents users from easily copying operations from other bills of materials, impacting efficiency. The fix backports functionality previously introduced in 19.1 to ensure consistent user experience.
Original PR description
### Steps to reproduce the bug: - Install mrp - Go to manufacturing app - Go to products -> bills of materials - Create a new bill of material for a product - Go to the operations tab - No 'copy…
### Steps to reproduce the bug: - Install mrp - Go to manufacturing app - Go to products -> bills of materials - Create a new bill of material for a product - Go to the operations tab - No 'copy existing operations' button appears if at least one operation is already created ### The problem: In version 19.0, the "Copy Existing Operations" button is missing from the BoM operations tab when no operations have been defined yet for the current BoM. While this feature was fully functional in version 18.4, it became inaccessible in 19.0 to users due to a UI reorganization introduced in commit https://github.com/odoo/odoo/commit/80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 that accidentally omitted the "Copy Existing Operations" button. Currently, users are forced to manually create at least one operation before they can see the option to copy from other BoMs. ### The reason to introduce the fix: The ability to copy operations is useful also when starting with an empty BoM if operations in other BoM's have been already created. Since this fix has already been implemented in version 19.1 via commit https://github.com/odoo/odoo/commit/02e837c959381523170c653da099328e9855a4e4, this PR backports that changes to 19.0 to restore feature parity and improve the user experience. opw-5906667 Forward-Port-Of: odoo/odoo#250411 Forward-Port-Of: odoo/odoo#248225
This update fixes a bug where navigating to pages with breadcrumbs caused a crash when the website header was disabled. The change ensures the website interaction safely handles pages without a header, improving stability and user experience. This resolves a technical issue that could disrupt customer journeys.
Original PR description
When the header is disabled globally via the Theme tab in edit mode, navigating to a page containing a breadcrumb caused a crash. The PageBreadcrumb interaction did not handle the case where no header was present on the page. This commit updates the interaction to safely handle pages without a header. Task-ID: 5927177 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#248080
This update fixes a bug where shifts crossing midnight were incorrectly flagged as overtime for employees in timezones like India. The change ensures accurate overtime calculations regardless of the employee's timezone, improving payroll accuracy. It also includes updates to internal code and added testing for reliability.
Original PR description
**Description of the issue/feature this PR addresses:** Fix the overtime calculation logic for resources in timezones ahead of UTC (specifically Asia/Kolkata +05:30) where shifts crossing midnight incorrectly attribute the second half of the shift as overtime. **Current behavior before PR:** shifts crossing midnight incorrectly attribute the second half of the shift as overtime. **Desired behavior after PR is merged:** . Fix version_periods_by_employee interval . Update get_dates() method to return date objects . Add corresponding tests coverage task-5949757 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249410
This update adapts the MRP module to a new time display format (e.g., '1h 23m 45s') introduced with recent changes. It replaces outdated formatting functions and removes confusing references to 'minutes' to ensure consistent and intuitive reporting within the MRP system. This improves clarity and usability for users.
Original PR description
With the changes made to float_time, every display is now showing `1h 23m 45s` instead of `83:45` (for example). This PR aims to adapt the MRP module to the new display. We're also replacing all uses `formatFloatTime` by `formatDuration` since the former is being depreciated. Finally, we're removing mentions of `minutes` in MRP since it is now counter-intuitive with the new display. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that time-related data within the MRP modules (like production planning) is consistently recorded and displayed in minutes. The change replaces an older formatting method with a new one, improving the accuracy and reliability of time-based reports and calculations. This update affects how production schedules and work orders are managed.
Original PR description
Make sure that time fields in mrp modules are in minutes. Add a new widget in mrp_plm for updates on time data types. Replace formatFloatTime by formatDuration.
This update fixes an issue where CABA taxes were incorrectly included in tax reports when part of a tax group. The change ensures that CABA taxes are properly excluded from reports, preventing duplicate amounts and improving the accuracy of financial reporting. This resolves a bug impacting invoice and reconciliation processes.
Original PR description
How to reproduce: - Create one CABA tax and one normal tax. - Create a tax group containing both taxes. - Create an invoice using this tax group. - In the tax report, the CABA tax appears even when the invoice is unpaid. - After reconciliation, the CABA tax amount is duplicated in the report. When the CABA tax is part of a tax group, it is selected in _read_generic_tax_report_amounts_no_tax_details. Since the tax group has tax_exigibility = 'on_invoice', the CABA tax inside the group is incorrectly included by the query. opw-5468074 Forward-Port-Of: odoo/enterprise#105888
This update resolves an issue causing errors when editing addresses within the customer portal. The fix ensures accurate address validation by correctly comparing data, preventing form errors and improving the user experience. This was triggered by a recent code change.
Original PR description
**Steps to reproduce:** - Create a DB with l10n_ar and l10n_ar ecommerce - Go to Settings > Invoicing > Fiscal Localization - Select the 'Argentina - Argentine Generic Chart of Accounts for…
**Steps to reproduce:** - Create a DB with l10n_ar and l10n_ar ecommerce - Go to Settings > Invoicing > Fiscal Localization - Select the 'Argentina - Argentine Generic Chart of Accounts for Registered Accountants' package - Create a website, and a portal user - Add a main and a secondary address to the user using the website form in 'My Account' - Go to the secondary address and change any field - Click on Save Address - Multiple errors will appear on the form (reproducible with other similar config) (and in logs: `UserWarning: unsupported operand type(s) for "==": 'l10n_latam.identification.type()' == '1'`) **Issue:** In `address_form_fields` some hidden input field are used to add specific non-editable values to the forms. This breaks the address validation of `CustomerPortal` in `def _validate_address_values` due to the following comparison: `partner_sudo[commercial_field_name] != address_values[commercial_field_name]` which try to compare recordsets with the given ids. **Fix:** Cast relational field to their id values to ensure they can be properly compared to the website form values. related fix which introduces the input issue: https://github.com/odoo/odoo/commit/0ee91631214c34b650342a0210ee8db27764f252 opw-5247171 Forward-Port-Of: odoo/odoo#244532
This update fixes an issue where pasting content into the website editor, particularly within iframes, would unexpectedly remove unremovable elements. The change adjusts how the editor handles inline elements, ensuring that elements are preserved during the paste process. This improves the user experience and prevents data loss.
Original PR description
*: website Before this commit: when a editable container is wrapped inside a non-contenteditable, which could happen inside an iframe, pasting on a selection including an unremovable element will remove the element. This is because the config parameter `allowInlineAtRoot` is false by default, the editable container of Contact us button is considered as the edition boundary, and then `wrapInlinesInBlocks` is called on it at insert, which removes invisible nodes in the wrapping process. After this commit: we now use predicates to decide areInlinesAllowedAtRoot We add a predicate specifically for the container of Contact Us button, to allow inline element in the root. The `wrapInlinesInBlocks` won't be called on the container on paste anymore. task-5109662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246987 Forward-Port-Of: odoo/odoo#241836
This update fixes a bug where canceled POS orders with future dates weren't fully removed from the system. Now, cancellations are correctly applied in both the POS interface and the backend, ensuring accurate order tracking and preventing phantom orders. This improves the reliability of our self-checkout process.
Original PR description
Before this fix, when we placed an order from the self-checkout with a preset slot for a future date, we weren't able to cancel it from the POS. The UI showed it as canceled, but after refreshing, the order was still there. Now, when we cancel an order scheduled for the future, it is correctly canceled both in the UI and in the POS. task : 5246089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248616 Forward-Port-Of: odoo/odoo#235775
This update corrects a technical issue preventing the successful submission of GİB e-Dispatch documents through the Nilvera integration. The previous system incorrectly passed the stock picking company, leading to an error. Now, the correct company environment is passed, ensuring smooth document submission.
Original PR description
# Description of the issue this PR addresses - When sending a GİB e-Dispatch document using l10n_tr_nilvera_edispatch, an error is raised during document submission. - The issue occurs in StockPicking._l10n_tr_nilvera_submit_document when sending request with Nilvera client. - The signature of _get_nilvera_client was updated but the params were not # Current behavior before PR - When attempting to send a GİB e-Dispatch document, the system raises an error. - The method _l10n_tr_nilvera_submit_document calls _get_nilvera_client with self.company. - stock.picking does not have a company field. - This results in an attribute error during client initialization and prevents document submission. # Desired behavior after PR is merged - The correct field self.env.company is passed to _get_nilvera_client. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where validating purchase receipts for kits with different unit of measure categories caused errors. The fix ensures accurate quantity calculations when a purchase order is placed in a foreign currency, preventing receipt validation failures. This improves the reliability of purchase order processing.
Original PR description
Steps to reproduce ------------------ 1. Enable Units of Measure and Automatic Valuation. 2. Create: Product KIT, stockable, UoM category Unit, UoM = Units. BoM for KIT with at least one component…
Steps to reproduce
------------------
1. Enable Units of Measure and Automatic Valuation.
2. Create:
Product KIT, stockable, UoM category Unit, UoM = Units.
BoM for KIT with at least one component whose UoM is in a different
category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.
Issue
-----
Validating the receipt raises:
> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…
If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.
Cause of the issue
------------------
Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108
Fix
---
The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.
https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126
For kits, `qty_received` must be calculated by aggregating component
moves to accurately determine this status. Since the standard logic
crashes due to UoM mismatch, the override in `purchase_mrp` is
necessary to provide the correct quantity for this date selection.
opw-5030761
Forward-Port-Of: odoo/odoo#248883
Forward-Port-Of: odoo/odoo#236276This update fixes an issue where shift start and end times weren't correctly reflecting the assigned shift template, even when employees had fixed schedules. The change ensures shift times align with the template, providing accurate scheduling for employees with varying working hours. This improves the reliability of shift planning.
Original PR description
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a…
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours. As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours. ## Reproduction Steps 1. Go to Planning. Click on Configuration tab > roles. 2. Create a role and add an employee as a resource This employee has to have a fixed working schedule. 3. Click on Configuration tab > Shift Templates. 4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created. 5. Click on Schedule tab > By resource and click on New. 6. Select the role you just created. ### Expected behavior The start and end hours should align with the shift template start and end hours. ### Unexpected behavior The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36. ## Origin of the issue We kept computing the working intervals of employees, even if a shift template was set: https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule. __ opw-5898509 Forward-Port-Of: odoo/enterprise#108187 Forward-Port-Of: odoo/enterprise#107018
This update fixes an issue where Verifactu invoices were incorrectly generating an 'F1' type instead of the required 'F3' type when fully invoicing. The change ensures the correct invoice type is used, aligning with Spanish tax regulations and preventing potential compliance problems. This update ensures accurate VAT reporting for Spanish customers.
Original PR description
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then…
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then go to PoS > Orders, and select the previously made order 4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order. 5. Click invoice to invoice the order; the invoice is no longer simplified. Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead. The fix ------- When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1. Sources: -------- Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD opw-5343973 Forward-Port-Of: odoo/odoo#242274
This update resolves an issue affecting the Gantt view of work orders, specifically related to planning and display. The changes include a revised calendar structure and the ability to exclude 'blocked by' workorders, improving workflow clarity and accuracy. This ensures a more reliable and user-friendly experience for managing production schedules.
Original PR description
- Use the old 'workcenter' gantt view rather than the 'production' (and remove it) - Create a new Work Center calendar - Add variant name in workorder display name - Add the falsy label to employee_assigned_ids (for Gantt view mainly) - Restore the possibility of not planning the 'blocked by' workorders - Reload after Plan in Gantt view task: 5946267
This update resolves an issue impacting the Gantt view used to manage work orders. The changes enhance the visual representation of work orders and improve the functionality of the Gantt chart, specifically regarding planning and scheduling. It corrects a display issue and ensures accurate planning capabilities.
Original PR description
- Use the old 'workcenter' gantt view rather than the 'production' (and remove it) - Create a new Work Center calendar - Add variant name in workorder display name - Add the falsy label to employee_assigned_ids (for Gantt view mainly) - Restore the possibility of not planning the 'blocked by' workorders - Reload after Plan in Gantt view task: 5946267
This update fixes an issue where selling kit products through Point of Sale (POS) would incorrectly calculate stock valuation lines. The fix ensures that the UoM of kit components is properly considered when determining the cost of goods sold and stock levels. This ensures accurate inventory tracking and financial reporting for kit sales.
Original PR description
When selling a kit product in POS, if the component of the kit use a different UoM than the UoM defined on the product, the stock valuation lines are wrong. Steps to reproduce: ------------------- * Create a storable product A with a UoM "Dozen" and a cost price of 10€ * Create a kit product B with a BoM of 1 unit of product A * Sell 1 unit of product B in POS > Observation: The valuation lines have the wrong value Why the fix: ------------ The product qty was not considering the UoM when computing the expense and stock valuation lines. opw-5471923 Forward-Port-Of: odoo/odoo#249583 Forward-Port-Of: odoo/odoo#248694
This update ensures that freight charges for international UPS deliveries are accurately reflected on the commercial invoices used for customs clearance. Previously, invoices were set to $0, but the fix now correctly includes freight charges based on the UPS API parameters. This improves accuracy and compliance for international shipments.
Original PR description
Issue ----- For international deliveries, the commercial invoice used for customs does not include the freight charges (it is set to 0). Steps to reproduce ----- - Create an international UPS sale - Confirm the delivery - Open the "UPSCommercialInvoice.pdf" file > In the price breakdown, freight is set to 0.0 Cause ----- It has to be specified in the `ship` request as `ShipmentServiceOptions.InternationalForms.FreightCharges.MonetaryValue` (source https://docs.rocketshipit.com/rs/docs/ups-api-parameters.html#shipment) Expected result ----- <img width="1912" height="963" alt="image" src="https://github.com/user-attachments/assets/170e49f7-6575-4524-b186-3829f4c20430" /> ----- Ticket: opw-5135494 Forward-Port-Of: odoo/enterprise#108465 Forward-Port-Of: odoo/enterprise#105505