Daily updates from Odoo
Thursday, April 2, 2026
94 changes · master
Enhancements to existing features
This commit restores a previous design style (M3.1) for various Odoo modules, focusing on consistent box styling across views. It reverts changes made for a previous update and adapts the templates as needed. Further work is needed to ensure icons are consistently visible.
Original PR description
In some view outside the groups we want the boxes anyway so we introduce the o_outlined class. This commit reverts the changes made for M3 to the arch, and bring back the previous template with some adaptation when needed. Note: * clipboard: more refactoring needed in some case icons are not visible * M3: some class are still present task-6054024 Co-authored-by: Adrien Dieudonné <adr@odoo.com> Co-authored-by: Romain Estievenart <res@odoo.com> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures each job position is linked to only one company, simplifying job management and reducing potential confusion. When a job position is created, the current company is automatically set. Additionally, demo data has been updated to consistently use 'My Company (San Francisco)' for empty company records.
Original PR description
Purpose A job position cannot be linked to multiple company. 1 JP = 1 company Specifications Remove the "Visible to all" possibility On Jon position At creation set the current company Adapt runbot data: All empty company must be My Company (San Fransisco) Task-6064945
This update strengthens Odoo's dynamic analysis capabilities by providing more granular error handling and optimizing object validation. It improves security by centralizing object checks and enhances performance by leveraging reference-based validation for frequently used objects. This ensures safer execution of dynamic code within Odoo.
Original PR description
[x] add granularity for `UnsafeObjectError` [x] complete auto checked objects [x] add hook for bound object and C descriptors Fixes: [x] add "no-operation" iterators check [x] define module for custom functions [x] centralize object validation in `_SafeWhitelist` Task-6041164
This update simplifies how data is sent to client applications by introducing a more efficient method for converting data to JSON. Previously, versioning complexities caused performance issues and made updates difficult, now data is delivered more smoothly and reliably.
Original PR description
To feed data to the client, discuss uses the Store class, which eventually transforms collected data into a dict using `get_result`. The `@store_version` decorator then injects a version so the client can distinguish stale from new data. This approach has several drawbacks. Each method expecting a versioned result must be decorated, but the version is only correct once all changes are flushed and assigned a transaction id. Returning the raw dict makes overrides cumbersome, and bus notifications require complex logic to enqueue and send them only once the version is available. This commit solves these issues by implementing an `as_dict` method on Store. Both bus notifications and the HTTP stack use this method to convert objects into JSON. The version is now fetched once, at the very end, and the Store instance can be returned, making overrides easier and reducing boilerplate. part of task-5242369 https://github.com/odoo/enterprise/pull/112159
This update improves the RFQ list view by adding key information like receipt status and expected arrival dates. This eliminates the need for users to manually check purchase records, streamlining the procurement process and ensuring data consistency across purchase and purchase order views.
Original PR description
Adding `receipt status` and `expected arrival date` to the RFQ list view, allowing users to avoid opening records manually to check this data and ensure consistency with the Purchase Order list view. TaskID-6013968
This update allows maintenance stages to be assigned to specific teams, providing greater control and organization for maintenance workflows. Previously, all teams shared the same maintenance stages. Now, requests will automatically filter to only show stages authorized for the team assigned to the maintenance request, improving efficiency and accuracy.
Original PR description
Currently, maintenance stages are global and shared across all teams. This improvement allows stages to be restricted to one or more maintenance teams, or left empty to remain available to all teams.…
Currently, maintenance stages are global and shared across all teams. This
improvement allows stages to be restricted to one or more maintenance teams,
or left empty to remain available to all teams.
- Add 'maintenance_teams' M2M field to 'maintenance.stage' model.
- Update tree view to display maintenance teams using many2many_tags.
- Create a new form view for stages to allow team selection.
- Add domain to 'stage_id' on maintenance requests to filter by team.
- Update '_get_default_team_id' to infer the correct team when creating
requests from specific Kanban columns.
- Enhance '_compute_maintenance_team_id' to maintain consistency between
the request team and the equipment's assigned team.
- Add onchange on 'maintenance_team_id' to automatically reset the
stage to the first valid option when the team changes.
- Update '_read_group_stage_ids' to get only the stages that the
maintenance team can work on.
task-5104582
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-prThis update optimizes the way the system checks user group memberships, speeding up the attendance process. By running these checks concurrently, the system responds faster and reduces potential delays. This change improves the overall user experience.
Original PR description
In AttendanceActionHelper, replaced two sequential user.hasGroup() calls with Promise.all() so both requests fire simultaneously, reducing the time window during which the component is vulnerable to destruction. **Task: 5972786** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves product labels by displaying the base unit price alongside the regular product price, ensuring accurate pricing information is printed. This change consolidates label formats and adapts to pricelist settings, enhancing clarity for customers and internal reporting. It also streamlines the process for generating labels.
Original PR description
### redo of #185040 (Part 2) ### Part 1: odoo/odoo#247010 Priced and unpriced product label formats were consolidated to avoid duplicate code. The option to print the price is now a separate option in the view. The pricelist field is hidden from the view if the price isn't set to be printed. Additionally, it is now possible to print the price on every product label format, as well as the base unit price, if enabled and set. NB: The branch is based on odoo/odoo#247010, to be merged thereafter. The duplicate commit will disappear from this PR after a rebase. TODO: ~~Migrate ZPL labels from `stock` to `product`.~~ TODO: ~~Use pricelists for base unit prices too, not just product prices.~~ Task ID: [4277792](https://www.odoo.com/odoo/my-tasks/4277792)
This update optimizes the website's attribute filters, ensuring that only relevant product options are displayed on the shop page. This change improves page loading speed and provides a smoother user experience for customers browsing products. It's a key enhancement to our website's performance.
Original PR description
Change the current behaviour of the Attributes filters by displaying only the values that are relevant on the loaded /shop page. task-4423954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the Odoo website form builder by allowing users to insert 'Title', 'Text', and 'Separator' snippets between existing form fields. Previously, the '+ Field' button only added fields after the selected one, limiting design flexibility. This change simplifies the process of creating more complex and visually appealing forms.
Original PR description
Currently, the "+ Field" button only supports adding a field after the selected one, making it difficult to insert snippets in between. This commit extends the feature to also allow inserting "Title", "Text", and "Separator" snippets after a selected field. task-5436870
This update allows businesses to specify unique units of measure (UoMs) and packagings for individual product variants. Previously, UoMs were only configurable at the product template level. This change restores a previous functionality, providing greater control over how variants are tracked and sold, particularly for products with diverse packaging options.
Original PR description
This commit enables defining dedicated units of measure, or packagings per product variant. Since 18.1, it was only possible to set UoMs on the template level. However, before 18.1, it was possible to define different packagings on the variant level. This commit partially restores the old behavior, and users can select dedicated UoMs on the variant from the new field `extra_uom_ids`. Task-5152612
This update restores a previous design style (M3.1) for certain views, focusing on a more consistent look and feel across Odoo. It reverts changes made for a previous feature and adapts the template as needed. Further work is needed to ensure icons are consistently visible.
Original PR description
In some view outside the groups we want the boxes anyway so we introduce the o_outlined class. This commit reverts the changes made for M3 to the arch, and bring back the previous template with some adaptation when needed. Note: * clipboard: more refactoring needed in some case icons are not visible * M3: some class are still present task-6054024 Co-authored-by: Romain Estievenart <res@odoo.com>
This update adds a warning system to alert users when DIMONA payroll declarations don't align with contract versions or have mismatched categories. This ensures accurate reporting for Belgian payroll, reducing potential errors and compliance issues. The change improves the reliability of payroll data.
Original PR description
add warning when DIMONA declarations don't cover the same date ranges as contract versions or when dimona category doesn't match between periods and versions. Task Id: 5951989
This update simplifies the payslip summary widget for pay officers by dynamically hiding worked day lines for certain pay structures (like bonuses). This change reduces confusion and streamlines the information presented, making it easier for pay officers to review payroll data.
Original PR description
In order to improve the experience of pay officers and prevent any confusion, some pay structures will not require the display of individual work day lines such as bonuses. Accordingly, the worked day widgets will be dynamic. Task: 6030842 Forward-Port-Of: odoo/enterprise#111470
This update standardizes the formatting of key reports related to French tax filings (2033C and 2033D). Specifically, section titles have been adjusted to align with a preferred style, enhancing clarity and consistency for reporting. This ensures accurate and streamlined tax reporting.
Original PR description
This commit updates the section titles for the 2033D report to make them consistent with the 2033C. The preferred format is to use a dash. No task ID
This update streamlines the HR payroll reporting by removing outdated views and actions. A key change improves the default measure in the payslip line pivot, now showing 'total' instead of 'amount' for more accurate reporting.
Original PR description
This removes a few views and actions not used anymore. It also changes the default measure for the pivot view of payslip lines from amount to total which is way more relevant. Task: 6032743
This update adjusts Odoo's payroll processing to correctly handle company executives classified under Joint Committee 999 (JC999) in Belgium. It excludes these employees from standard Belgian payroll obligations, simplifying reporting and ensuring compliance with specific legal requirements. Key changes include filtering data for Dimona, social reports, and holiday allocations.
Original PR description
Company executives under Joint Committee 999 (JC999) are not classified as travailleurs under Belgian law, so standard Belgian payroll obligations do not apply to them. This PR introduces the…
Company executives under Joint Committee 999 (JC999) are not classified as travailleurs under Belgian law, so standard Belgian payroll obligations do not apply to them. This PR introduces the necessary exclusions across Dimona, holiday attests, termination flows, social reports, and paid holiday allocation. A new l10n_be_egov3_code computed field (related to l10n_be_joint_committee_id.egov3_code) is added on both hr.employee and hr.employee.departure to expose the JC code in views invisibility conditions. Dimona: No declaration should ever be sent for a JC999 employee. _compute_l10n_be_dimona_next_action short-circuits to False for JC999 versions, and switching a version to JC999 via write() automatically clears the worker code, dimona category, and next action. All Dimona-related UI elements are hidden for JC999: - "Check Dimona" header button - Dimona relation stat button - Dimona next action pill/widget - ONSS group (worker code + dimona category fields) - Dimona debug group End-of-contract: for JC999 on both the employee form and the departure wizard it is shown the standard view bypassing the Belgian-specific termination fee flows. DMFA, social reports, and paid holiday allocation: JC999 payslips and contracts are filtered out of the DMFA XML generation, the social balance sheet (contract list, payslip search, and end-of-period contract list), the social security certificate payslip query and the query in the paid leave allocation wizard.
This update optimizes the Web Studio interface by preventing certain widgets from being used in record set views (like lists). Using these widgets in these views causes significant performance slowdowns. This change improves overall Odoo performance and stability.
Original PR description
Certain widgets such as the form status bar widget are designed to be used on single records. While, it is technically possible to use these widgets on record set views such as the list view, this leads to massive performance issues even for basic selection fields. This commit adds a widget blacklist organised by view type. This allows to blacklist some widget types for some views which are still available in debug mode. task-5194320
Task: 5973879
Original PR description
Task: 5973879
part of task-5242369 community: https://github.com/odoo/odoo/pull/256079/
Original PR description
part of task-5242369 community: https://github.com/odoo/odoo/pull/256079/
Added the parameter sort_by_relevance to autocomplete. This parameter is used in the autocomplete function in community. for this community PR: odoo/odoo#240437 task-5366564
Original PR description
Added the parameter sort_by_relevance to autocomplete. This parameter is used in the autocomplete function in community. for this community PR: odoo/odoo#240437 task-5366564
task-6020137
Original PR description
task-6020137
No description available.
Resolved issues and error corrections
This update fixes a visual issue in the title form by adding a grey background to readonly fields. Previously, these fields lacked this background, making them harder to distinguish from editable fields. This change improves the overall clarity and usability of the title form for users.
Original PR description
Before this commit, fields in title forms were missing the grey background. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where refund creation from invoices with similar items would fail due to incorrect line matching. The new algorithm now prioritizes matching based on product, price, and quantity, ensuring accurate refund processing and preventing duplicate matches. This improves the reliability of refund creation for users.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#257158 Forward-Port-Of: odoo/odoo#252200
This update resolves an issue where the 'text-muted' styling in the mass mailing builder was inconsistently applied, depending on the background color. The fix ensures a consistent muted color is always used, improving the visual appearance and usability of mass mailing templates.
Original PR description
This commit fixes an issue with the `text-muted` class that gives a specific color to the text based on a background-color. Since the mass_mailing builder is a special case for background colors. The class now gives a specific color no matter what the background color is set when used inside the mass_mailing builder. task-5993139 Forward-Port-Of: odoo/odoo#252419
This update corrects a visual issue where the table row menu was misaligned in RTL (Right-to-Left) website layouts. The fix ensures the menu's position is accurately calculated by passing the correct 'direction' parameter during editor initialization. This improves the user experience for Arabic and other RTL language users.
Original PR description
Problem: In RTL websites, the table row menu is not placed correctly. Cause: The `inlineStartOffset` calculation in `table_menu` depends on the `direction` parameter, which was not passed during the…
Problem: In RTL websites, the table row menu is not placed correctly. Cause: The `inlineStartOffset` calculation in `table_menu` depends on the `direction` parameter, which was not passed during the editor initialization. Solution: Ensure the `direction` parameter is properly passed during editor initialization so the `inlineStartOffset` is computed correctly in RTL layouts. Before: <img width="1091" height="682" alt="image" src="https://github.com/user-attachments/assets/964903b2-d33b-48aa-86c2-632cc5adac9a" /> After: <img width="1093" height="658" alt="image" src="https://github.com/user-attachments/assets/846fd39c-1114-408d-a1f4-75b27218b9b0" /> Steps to reproduce: - Change website language to Arabic. - Add a text block and insert a table inside. - Hover over the first table row. - Observe the row menu is misplaced. opw-6049260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256045
This update fixes a problem that prevented users from sending follow-up reports by post when they lacked sufficient permissions to access company information. The fix grants elevated access (sudo) to the IAP account, ensuring reports can be processed correctly. This resolves a previous access error impacting report delivery.
Original PR description
Issue: Before this commit, when sending a follow up report by post, an access error is thrown if the user doesn't have enough access to read from res.company model Fix: Access the IAP account as sudo opw-6050041 Forward-Port-Of: odoo/odoo#255959 Forward-Port-Of: odoo/odoo#255431
This update clarifies the website editor's handling of map snippets, specifically addressing a confusing error that occurred when users created custom snippets. The fix ensures that custom snippets are only loaded if the original base snippet is available, preventing errors and improving the user experience. This resolves a potential point of confusion for website editors.
Original PR description
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4.…
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4. Enable developer mode and refresh the website editor 5. Add a new Google Map snippet to the page a. The Google Map snippet is the one where the icon shows a map with a pin on the **left side**. 6. In the wizard, enter your valid API key and click Save a. Alternatively, you can use Odoo inspector to write any string into the `google_maps_api_key` field of the `website` model to simulate the above 7. Disable developer mode and refresh the website editor 8. Click one of the categories in the editor side panel to open the snippets browser 9. Click into the 'Custom' snippets category 10. Observe the error Depending on whether or not you have a Google Maps API key configured on your website, either the `s_map` or `s_google_map` base snippet will be disabled/hidden. When a user has created custom snippets out of the disabled base snippet, you will recieve the error mentioned above when the snippet browser attempts to load in these custom snippets, as it will be unable to load the base snippet. To fix this, we check if an original snippet was found when loading in a custom snippet. If not, we will not load in the custom snippet to avoid confusion. This error does not occur in Developer Mode, as both base snippets are always enabled in this case. Aditionally, we also clarify which snippet is the Google Map snippet to avoid confusion for the user when creating custom snippets. opw-5933787 Forward-Port-Of: odoo/odoo#256847 Forward-Port-Of: odoo/odoo#250236
This update corrects an issue where line breaks added to quotation template section titles were being removed. The fix ensures that section titles display correctly as single lines, aligning with the intended design. Users should now create new sections instead of using line breaks within existing ones.
Original PR description
Steps to produce: --- - Install `Sales` module. - Go to `Sales > Configuration > Sales Orders > Quotation Templates`. - Create a new template and add a section. - In the section name, add text with…
Steps to produce: --- - Install `Sales` module. - Go to `Sales > Configuration > Sales Orders > Quotation Templates`. - Create a new template and add a section. - In the section name, add text with line breaks using `Shift + Enter`. - Go to sale orders > Create new SO > Set quotation template created above. Issue: --- - Line breaks entered in the quotation template section lines are stripped when the template is applied to a sale order. These intentional sections are meant to be single-line titles; users should create a new section instead of using line breaks within one. Root cause: --- - At [1], the `name` field is defined without the `section_and_note_text` widget. This widget is responsible for rendering section lines as a `CharField` instead of a `TextField`, as seen at [2]. Solution: --- - Add `widget="section_and_note_text"` to the `name` field. This ensures section lines consistently use `CharField`, preventing line breaks from being entered. [1]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/sale_management/views/sale_order_template_views.xml#L96 [2]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/account/static/src/components/section_and_note_fields_backend/section_and_note_fields_backend.js#L79-L86 opw-6034255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256058
This update resolves an issue where colored links would revert to the default color after using the website editor. The fix ensures that link colors remain consistent regardless of whether the editor is open or closed, improving the visual appearance of website content. This change improves the user experience and maintains brand consistency.
Original PR description
Problem: Colored links revert to the default link color after saving and closing the website editor. Cause: The rule forcing links to inherit color from their parent `<font>` element is defined in the `html_editor` module, whose stylesheet is unloaded when the editor is closed, so the rule no longer applies on the frontend. Solution: Add the rule to `website_common.scss` so it applies on the frontend regardless of whether the editor is loaded. Steps to reproduce: 1. Open the website editor. 2. Apply Color to selection. 3. Apply link to the subset of the selection. 4. Save and close the editor. 5. Observe the link reverts to its default color. task-5980854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256630 Forward-Port-Of: odoo/odoo#253301
This update fixes an issue where the projected margin list view incorrectly displayed the standard sales report instead of a custom view. The change ensures the correct, tailored list view is shown, providing more accurate and relevant margin information for users. This improves the clarity and usability of the margin reporting feature.
Original PR description
Specify the custom list view for the projected margin action window instead of showing the default `sale.report` list view in saas-19.2 --- task-6084014 Forward-Port-Of: odoo/odoo#256822
This update fixes an issue where product images didn't update correctly when hovering over attributes on the shop page. The fix removes a technical element that was causing the browser to prioritize a static image over the dynamically updated image source. This ensures customers always see the correct product variant image.
Original PR description
Steps to reproduce: - Go to the shop page. - Hover over any attribute on a product tile that displays attributes. Issue: - The variant image does not update on attribute hover. Cause: - The `srcset` attribute was introduced for website images in https://github.com/odoo/odoo/commit/36e680feca4884940e020119de6a13cd7f927516. - Only the `src` attribute of the image is updated on hover, while the `srcset` remains unchanged. - Since browsers prioritize `srcset` over `src`, the displayed image does not change. Fix: - Remove the `srcset` when hovering over an attribute to ensure the updated `src` is used. - Restore the original `srcset` when the hover ends. opw-6030289 Forward-Port-Of: odoo/odoo#254606
This update fixes a potential issue where the same work entry type code could be used in multiple countries, leading to data inconsistencies. The change ensures that each country has a unique work entry type code, improving data accuracy and reliability within the HR system. This resolves a previous bug related to error handling.
Original PR description
It was previously possible to create two work entry types with the same code in the same country. It was due to a missing `raise` before the `UserError`. The condition to raise the exception was not correct either. So it has been changed to prevent having two work entry type codes covering the same country. task-6037156 Forward-Port-Of: odoo/odoo#254811
This update fixes a technical issue that prevented RTL languages (like Arabic or Hebrew) from displaying correctly in Odoo forms. The fix ensures proper formatting and layout for RTL languages, improving the user experience for a wider range of customers. This change is a routine fix to enhance usability.
Original PR description
RTLCSS automatically adds '-1 *' when in RTL but only in calc, so we wrap the variable with 'calc'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that caused purchase order confirmations to fail when orders included both standard and subscription products. The fix ensures all date values are consistently converted to datetime objects, preventing type comparison errors and allowing successful order confirmation.
Original PR description
**Steps to reproduce:** * Install *sale_management*, *sale_subscription*, and *stock* modules. * Go to *Settings* and enable *Dropshipping*. * Create two products: * One *normal dropship* product. *…
**Steps to reproduce:**
* Install *sale_management*, *sale_subscription*, and *stock* modules.
* Go to *Settings* and enable *Dropshipping*.
* Create two products:
* One *normal dropship* product.
* One *dropship + subscription* product.
* Create a *Quotation*.
Add both products to the order.
* Confirm the quotation.
**Observed behavior:**
* A traceback occurs during confirmation:
File '/home/odoo/workspace/odoo19/odoo/addons/purchase_stock/models/stock_rule.py', line 159, in _run_buy
date_planned = po.date_planned or min(v['date_planned'] for v in po_line_values)
TypeError: can't compare datetime.datetime to datetime.date
**Cause:**
* In *_run_buy*, the system computes the earliest *date_planned* using:
https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/purchase_stock/models/stock_rule.py#L159
* Subscription products set *date_planned* as *datetime.date*,
https://github.com/odoo/enterprise/blob/a88c64a224805d95b60a20c502428897655dba53/sale_subscription_stock/models/sale_order_line.py#L153
`current_period_start = self.order_id.last_invoice_date or
self.order_id.start_date or fields.Date.today()`
* while normal products set *date_planned* as *datetime.datetime*.
https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/sale_stock/models/sale_order_line.py#L286
before min() It call `_prepare_purchase_order_line_from_procurement`,
the value is assigned directly from `values.get('date_planned')`, and conversion
with `fields.Datetime.to_datetime()` only happens conditionally:
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/purchase_stock/models/purchase_order_line.py#L347-L351
As a result, some values remain `date` while others are `datetime`,
* When both are present in *po_line_values*, Python cannot compare the
two types, causing the crash.
**Fix:**
So by moving the `fields.Datetime.to_datetime()` cast to the initial
assignment of `res['date_planned']`, so it is always a `datetime`
regardless of the source, and removing the now-redundant cast inside
the `if` block.
---
opw-6034079
---
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#255063This update resolves a technical issue preventing webhooks from functioning correctly. Recent changes to access controls inadvertently blocked webhook calls, resulting in a 403 Forbidden error. The fix ensures webhooks can now reliably process invoice data.
Original PR description
- Register your user (on a db that allows webhook). - On another registered account, send an invoice to the first one. => A webhook call has been made, resulting into a 403 Forbidden. Following some changes on access rights checks, the webhook don't work. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256607
This update fixes an issue preventing users from sorting invoices based on their deferred dates within the accounting module. The previous code design unintentionally excluded date fields from sorting, now the system correctly handles date-based sorting in grouped lists. This ensures accurate reporting and filtering of invoices.
Original PR description
Steps to reproduce 1. Open Accounting > Customers > Invoices and create an invoice with deferred dates. 2. Open the invoice and click the Deferred Entries smart button. 3. In the grouped list view,…
Steps to reproduce 1. Open Accounting > Customers > Invoices and create an invoice with deferred dates. 2. Open the invoice and click the Deferred Entries smart button. 3. In the grouped list view, click the Date column header to sort. 4. Nothing happens. Issue The [IMP] web: Grouped kanban/list in a single RPC (https://github.com/odoo-dev/odoo/commit/26c37c9c070107f8bd753cb8a6d8343384fdd7bf) refactor introduced a regression. _get_read_group_order() [1] iterated over the provided aggregates list to build the ORDER BY clause. Fields with an aggregator attribute that are not included in the aggregates list (e.g. date fields, which getAggregateSpecifications() excludes) were silently dropped from ORDER BY. [1] https://github.com/odoo/odoo/blob/26c37c9c070107f8bd753cb8a6d8343384fdd7bf/addons/web/models/models.py#L496-L514 Solution Add a fallback in _get_read_group_order() so that when fname is neither a groupby field nor present in the provided aggregates list, the method checks field.aggregator directly and appends `fname:aggregator direction` (e.g. `date:min ASC`) to the ORDER BY string. The ORM's _read_group_orderby() already accepts such specs in ORDER BY even without them being in SELECT. opw-6044059 Forward-Port-Of: odoo/odoo#256592
This update resolves a critical issue where the inventory valuation report crashed with large product catalogs (300k+). By optimizing how the report accesses product data, it now runs smoothly and efficiently, even with extensive product lists. This ensures the report is usable for all users.
Original PR description
Behavior before: Opening the inventory valuation report on databases with 300k+ products (storable) caused an out-of-memory (OOM) error, making the report completely unusable at this scale. Behavior…
Behavior before: Opening the inventory valuation report on databases with 300k+ products (storable) caused an out-of-memory (OOM) error, making the report completely unusable at this scale. Behavior after: The inventory valuation report loads successfully and efficiently for 300k+ products without any memory errors or RAM spikes. Root Cause: In `_get_accounts_by_product()`, querying all storable products creates a massive recordset. When iterating through this recordset, the call to `_get_product_accounts()` accesses various relational and property fields (like categories and accounts). Because standard ORM prefetching was active, accessing these relational fields on the first loop iteration triggered a massive batch-fetch for all 300k+ products in the recordset simultaneously. This cascading prefetch overloaded the environment cache and caused an immediate OOM crash. Fix: Wrapped the `_get_accounts_by_product()` call in `with_context(prefetch_fields=False)`. This disables the greedy batch-loading behavior across the entire recordset. The ORM now fetches the required relational accounting fields surgically, record-by-record inside the loop, maintaining a minimal memory footprint and preventing the crash. Benchmark: | Products Count | Memory Before | Memory After | Time Before | Time After | |------------------------|-------------------------|----------------------|------------------- |----------------| | 300k+ | Memory Error | 1.1. GB | 46.63 s | 1.9 m | | 200k | Memory Error | 566.4 MB | 1.2 m | 1 m | | 100k | 873.1 MB | 286.8 MB | 36.74 s | 32.15 s | | 50k | 442.1 MB | 145.6 MB | 18.96 s | 17.65 s | opw-5462037 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#253331
This update corrects a display issue in the PEPPOL configuration settings for branch companies. Previously, branches using their parent company's VAT for PEPPOL registration saw a default 'Sending and receiving' role displayed. This has been fixed to ensure branches can only manage sending, improving the system's usability and aligning with business requirements.
Original PR description
In v19.0 -> master, if a branch company used the VAT of the parent company to register for peppol, the peppol participation role would be shown in the configuration settings, with a default value being "Sending and receiving", And since branches in this case should be able to ONLY send, the setting shouldnt be visibile to the user. task-none Forward-Port-Of: odoo/odoo#256820
This update resolves a technical issue where the Bluetooth caliper driver was sending measurement data without a confirmation status. This caused the frontend to incorrectly display a fake disconnection warning. The fix ensures the frontend receives complete measurement data with a status flag, eliminating the warning and improving the user experience.
Original PR description
When a measurement was successfully read via Bluetooth, the driver broadcasted the `value` without the `status` flag. The frontend JavaScript received the `value` but rejected the payload because the `status` was not explicitly marked as successful, leading to a fake disconnection warning. opw-5473691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256860
This update fixes an issue preventing the successful import of orders with line-level charges (like allowances). The fix ensures quantity keys are correctly applied to both regular order lines and allowance charges, resolving an error that caused import failures. Added tests confirm the import process now works as expected.
Original PR description
When importing orders with line-level charges, the import would fail because the `quantity` key was not being renamed to correct quantity keys (`'product_uom_qty'` for sale order and `'product_qty'` for purchase order) for allowance charge lines. The issue occurred because the key renaming was only applied to the main lines_vals list after calling `_import_lines()`, but not to the `allowance_charges_line_vals` that were created separately. Also the key for taxes returned in `_get_line_vals_list` method in `purchase.order` model is `'taxes_id'` which is not aligned with the `purchase.order.line` model. This fix properly handles the quantity key renaming for both regular lines and allowance charge lines and updates `'taxes_id'` key value to `'tax_ids'`, preventing the AttributeError when accessing the quantity key during order line creation. Forward-Port-Of: odoo/odoo#256466 Forward-Port-Of: odoo/odoo#245411
This update fixes issues where the Click & Collect widget incorrectly displayed product availability, particularly for products without inventory tracking or those excluded by tags. The changes ensure accurate availability information is shown to customers, resolving a potential frustration and improving the shopping experience.
Original PR description
This PR addresses three edge cases in the Click & Collect and Delivery availability widget where incorrect availability states were being shown to the user. Before this PR: * If a product variant had…
This PR addresses three edge cases in the Click & Collect and Delivery availability widget where incorrect availability states were being shown to the user. Before this PR: * If a product variant had a tag excluding it from Click & Collect, the logic bypassed the entire stock preparation block. This resulted in the variant falsely hiding the standard Delivery option and showing C&C as unavailable. * Products that are not tracked in inventory (consumables/services) were not properly displaying the availability widget with all options open (bypassing stock checks). * If a product variant was excluded from standard delivery methods via tags, the delivery portion of the widget would still incorrectly render on the frontend. After this PR: * The C&C `excluded_tag_ids` check is moved further down so it only restricts the generation of `in_store_stock_data`. Standard `delivery_stock_data` is now evaluated independently. * *Untracked products now correctly bypass standard stock checks and display all available widget options as expected. * Standard delivery carriers are now explicitly filtered against the product's tags (`dm.excluded_tag_ids & product_tags`). If all available delivery methods are excluded, the delivery stock data is correctly omitted, hiding the section. opw-5990419
This update fixes a previous issue where tax names were displayed in English for Spanish users. Now, all tax names are correctly shown in Spanish, improving the user experience for Spanish-speaking customers and ensuring compliance with local regulations. This change was made as part of a standard maintenance update.
Original PR description
It was a previous dev in which the fw-port failed. Here is the old [PR](https://github.com/odoo/odoo/pull/238857) The tax names were displayed in English, and it's confusing for the Spanish users. Now, the taxes are displayed in spanish task-6041023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256706 Forward-Port-Of: odoo/odoo#255074
This update resolves an issue where the meeting panel appeared unreadable in light themes due to an unintended color inversion. The PR removed a conflicting style class, restoring the panel's original design and ensuring optimal visibility for users.
Original PR description
Before this PR, .o-simulateDarkTheme is applied to the panel in meeting mode. This class inverts the text color, making it white on white. This PR removes the class, which seems to have been applied by mistake. task-6054300 Before: <img width="776" height="1009" alt="image" src="https://github.com/user-attachments/assets/6d7ad6c3-6593-43ba-9101-c8960f3e649f" /> After: <img width="766" height="994" alt="image" src="https://github.com/user-attachments/assets/0cf6b3b6-388c-44bc-b697-760132c06ede" /> Forward-Port-Of: odoo/odoo#255284
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived. Forward-Port-Of: odoo/odoo#256112
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived. Forward-Port-Of: odoo/odoo#256112
This update fixes a technical issue where syncing cancelled events from Microsoft Calendar would sometimes cause an error. Now, when a cancelled event is synced, Odoo correctly handles it, preventing errors and ensuring accurate event synchronization. This improves the reliability of our calendar integration.
Original PR description
Before this commit, when syncing events from Microsoft, if there was a cancelled event that was not yet synchronized with Odoo, calling browse on event.odoo_id would raise an error as it would be None. opw-5917677 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256827
This update resolves an issue where Odoo displayed a misleading warning message to users when a password wasn't provided during file uploads. Now, the system correctly checks for a password during saving, eliminating the unnecessary warning and improving the user experience. This ensures consistent behavior and prevents confusion for users.
Original PR description
Before the change, when the user uploads a file, Odoo automatically shown a warning message saying that the content of the file or the password are incorrect. Now the system does not show the warning when a password is not set and checks if the password is set when saving task-6036219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256759 Forward-Port-Of: odoo/odoo#253834
## Issue When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number. ## Steps to reproduce This is one example among other use cases causing this issue. 1. Install *Sales* (`sale_management`) 2. In Settings > Technical > Sequences, select the `sale.order` sequence - Set the Prefix to something containing the current month (e.g. `S%(y)s/%(month)s/`) - Enable *Use subsequences per date_range* (`ir.sequence.use_d
Original PR description
## Issue When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number. ## Steps to reproduce This is one example among other use…
## Issue
When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number.
## Steps to reproduce
This is one example among other use cases causing this issue.
1. Install *Sales* (`sale_management`)
2. In Settings > Technical > Sequences, select the `sale.order` sequence
- Set the Prefix to something containing the current month (e.g. `S%(y)s/%(month)s/`)
- Enable *Use subsequences per date_range* (`ir.sequence.use_date_range`)
- Add a row for the current month, with *Next Number* set to 1
- Add a row for the next month, with *Next Number* set to 5
3. Create a Sales Order:
- Any Customer
- Any Product
- Set the *Quotation Date* to next month
- Confirm
4. **The resulting Sales Order uses the sequence from next month (= its name ends with 5), but replace the `%(month)s` placeholder by the current month.**
<img width="541" height="130" alt="image" src="https://github.com/user-attachments/assets/6ace81f9-1ce2-4401-a9ba-383673a20981" />
The original issue reported by ticket 5950028 showed a similar issue with dropshipped Purchase Orders, which would use the date of delivery for the sequence number, and the current month for the placeholder in the prefix/suffix.
## Cause
When interpolating the prefix/suffix of a sequence, the date used by default is `datetime.now(self.env.tz)`. If provided, the context keys `ir_sequence_date` and `ir_sequence_date_range` are used instead.
https://github.com/odoo/odoo/blob/877289cf4d9725e12b355f482308150fe170e816/odoo/addons/base/models/ir_sequence.py#L211-L216
In the `IrSequence._next` method, the correct `ir.sequence.date_range` is chosen, based on the sequence date provided (which is the *Quotation Date* in our steps to reproduce) and the `ir_sequence_date_range` is passed as a context key to be used in the `_interpolation_dict` function later.
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/odoo/addons/base/models/ir_sequence.py#L261-L270
**The `ir_sequence_date` is not passed as a context key, which will make `_interpolation_dict` use `datetime.now(...)` to interpolate the placeholders in the prefix/suffix.**
opw-5950028
Forward-Port-Of: odoo/odoo#256449
Forward-Port-Of: odoo/odoo#256320This update corrects a technical issue that prevented the system from properly receiving data from serial scales. The team refactored a key method, and a subsequent change inadvertently removed a necessary connection parameter. This fix ensures accurate data collection from serial scales, improving data reliability.
Original PR description
The `_get_raw_response` method was refactored to be static, but a fw port broke its use by missing to provide the serial connection object as parameter. Forward-Port-Of: odoo/odoo#256816
This update resolves a visual glitch that appeared when formatting tables within the To-Do module. Specifically, applying formatting like bold would create unexpected blank lines above the table. The fix prevents styling of system nodes, ensuring a consistent and correct table layout.
Original PR description
Steps to Reproduce - Go to To-Do - Add a table - Type content inside the table - Select all using Ctrl + A - Apply formatting (e.g., Bold) Description of the issue: An empty line appears above the table and the layout shifts unexpectedly after applying formatting. Cause: `data-selection-placeholder` nodes exist before and after the table. These nodes normally have zero height. When selecting all content, these placeholder nodes are also included in the selection. Applying formatting styles them as well, which changes their height from zero. As a result, they become visible and appear as newly added blank lines, even though no new line was actually inserted. Solution Exclude system nodes, such as selection placeholder elements, from formatting operations. This prevents them from being styled and avoids unintended layout shifts. task-5976361 Forward-Port-Of: odoo/odoo#256235 Forward-Port-Of: odoo/odoo#252416
This update corrects a flaw in how timesheet statistics were calculated, ensuring accurate reporting across multiple projects. The previous method would miss calculations when multiple projects were involved, leading to incomplete data. This fix ensures all projects are correctly accounted for in timesheet reports.
Original PR description
**Description:** The issue is raised in this pr(v19.2) : https://github.com/odoo/odoo/pull/236971 The compute method used a…
**Description:**
The issue is raised in this pr(v19.2) : https://github.com/odoo/odoo/pull/236971
The compute method used a [`return`](https://github.com/odoo/odoo/pull/236971/changes#diff-4e1a18a369f7dd4de264139227676dd818c06612681c88019f43d238bd8a1490R91) statement when a `if condition` was met. While this works correctly for a single record, it causes issues when multiple records are present.
**For example**, if `self` contains records like `project.project(3, 2, 4)`, and the condition **is satisfied** for the first `record (3)`, the method exits early. As a result, the remaining `records (2 and 4)` are **not** processed.
When the compute method is [triggered](https://github.com/odoo/odoo/blob/8c3043b436f8aae295f247341e3ac427fab05474/odoo/orm/fields.py#L1746) this incomplete computation leads to
missing values for some records and can result in errors.
**Solution:**
To resolve this issue, `return` has been replaced with `continue`.
This ensures that:
Only the current record is skipped when the condition is satisfied and the loop continues processing the remaining records.
**Traceback:**
```.py
Traceback (most recent call last):
File "/tmp/tmp2cuqrnuy/migrations/testing.py", line 483, in test_check
self.check(value)
File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line 228,
in check
self.assertFalse(diff, msg)
AssertionError: [('project.menu_projects', 391, 'Project > Projects', 593)] is
not
false : At least one menu or view working before upgrade is not working after
upgrade.
('project.menu_projects', 391, 'Project > Projects', 593):
Traceback (most recent call last):
File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
335, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
348, in mock_action
return self.mock_act_window(action)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
508, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py",
line 541, in mock_view_form
[data] = record.read(fields_list)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 2735, in read
return self._read_format(fnames=fields, load=load)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 2991, in
_read_format
vals[name] = convert(record[name], record, use_display_name)
~~~~~~^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 6007, in
__getitem__
return self._fields[key].__get__(self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/fields.py", line 1805, in
__get__
raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
ValueError: Compute method failed to assign
project.project(2, 4).stat_timesheet_value
```
opw-6046808
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256048This update resolves issues related to accessing records and simplifies how Odoo handles relationships between data. Specifically, it ensures previously accessible records are correctly fetched, even if permissions change, and streamlines the way lists of IDs are used in relational queries.
Original PR description
## handle relational x2m 'in' in domain Simplify the `condition_to_sql` implementation of x2many relational fields so that comparisons with a list of ids is translated into an already implemented `any` operator. (test_send_survey fails with access error) ## orm: fetch previously accessible record Given that we have a cache of read permissions, the record may be inaccessible from the query, however it was marked as accessible. In such a case, `Model.fetch` should be executed in sudo and not fail. (test_scheduled_message_model_without_post_right fails) ## mail: res_acces in mail.scheduled.message Reading and searching access is not aligned. Implement a similar logic to what is in the mail.activity module. (ok) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the user experience by adding a zoom feature to product images within the Product, Expenses, and Point of Sale modules. Previously, users couldn't easily examine detailed product information. This change provides a better visual inspection experience for products, particularly in the Point of Sale and Expense tracking workflows.
Original PR description
This PR enables the zoom feature for product images across the **Product**, **Expenses**, and **Point of Sale** modules. Currently, some product views display images without the zoom capability. This makes it difficult for users to inspect smaller details of a product. Enabling the `zoom` option on the `image_1920` widget provides a more consistent UI. ### **Changes** Added zoom to the following modules: **hr_expense** (product variant), **point_of_sale** (product view), and **product** (template and variant views). **Task ID: 6003499** Forward-Port-Of: odoo/odoo#255568
This update fixes issues where the table editor's menu wouldn't appear correctly when hovering over lists within table cells, and where the menu could overflow. It now ensures menus display properly and updates dynamically when the table cell changes, enhancing the user experience and stability of the table editor.
Original PR description
**Current behavior before PR:** - Table menu handlers could overflow into adjacent table areas when the targeted part of the table was only partially visible within the container. - When a table cell contained a list, hovering over the list element did not display the table UI menus, even though the mouse was inside the cell. **Desired behavior after PR is merged:** - Use a local overlay for the table menu to prevent overflow into adjacent cells. - Table UI menus are now correctly displayed when hovering over list elements inside a table cell. task-5353518 Forward-Port-Of: odoo/odoo#254802 Forward-Port-Of: odoo/odoo#240342
This update resolves an issue where journal codes were overlapping in certain languages, like Hebrew, leading to installation problems. The change increases the journal code length to 7 characters, preventing conflicts and ensuring consistent accounting functionality across all supported languages. This improves the stability and reliability of the accounting module.
Original PR description
When generating journals with some languages, such as Hebrew, codes overlap violating the constraint _code_company_uniq. This commit will prevent that from happening by increasing the 5 character constraint to 7. Also removed the "magic number" to be used dynamically. Reproduction steps: - Create a fresh database - Set company language to Hebrew - Attempt to install accounting Enterprise PR: odoo/enterprise#110710 Ticket [link](https://www.odoo.com/odoo/project.task/6001568) opw-6001568
This update resolves an issue where field widgets in settings panels were incorrectly stretching to 100% width, causing layout problems. The fix uses a CSS technique to ensure that module-specific styling (like settings or custom views) takes precedence, restoring the intended 50% width for elements like the helpdesk email alias row.
Original PR description
**Issue:** odoo/odoo#250051 consolidated multiple `width: 100%` rules into a single broad selector: .o_form_view .o_form_sheet .o_field_widget:not(…) { width: 100% } This broadened scope from…
**Issue:**
odoo/odoo#250051 consolidated multiple `width: 100%` rules into a single broad selector:
.o_form_view .o_form_sheet .o_field_widget:not(…) { width: 100% }
This broadened scope from `.o_group/.o_inner_group` to the entire `.o_form_sheet`, which was needed for the new `o_input_box` overlay system. However, the high specificity (0,4,0) now overrides any module-specific rule with lower specificity, such as setting.scss's `width: 50%` rule (0,3,0) for `<setting>` blocks.
This broke settings panels: field widgets stretched to 100% width instead of 50%, causing overflow in layouts like the helpdesk team email alias row.
**Fix:**
wrap the field widget portion of the selector in `:where()`.
The `:where()` CSS pseudo-class works identically to `:is()` in terms of what it matches, but always contributes zero specificity.
(ref: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity)
(ref: https://developer.mozilla.org/en-US/docs/Web/CSS/:where)
```
Before (A=0, B=4, C=0):
.o_form_view .o_form_sheet .o_field_widget:not(…)
↑(0,1,0) ↑(0,1,0) ↑(0,1,0) ↑(0,1,0)
After (A=0, B=2, C=0):
.o_form_view .o_form_sheet :where(.o_field_widget:not(…))
↑(0,1,0) ↑(0,1,0) ↑(0,0,0) ← :where zeroes this
```
The rule still matches every field widget in the form sheet, but now any component-specific override (settings, helpdesk, custom views) wins naturally without needing specificity hacks.
CSS specificity tiebreaker order:
```
A: inline styles > B: IDs > C: classes/attrs/pseudo-classes
Equal specificity → last rule in source order wins
```
task-6005002
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where POS discounts weren't being applied correctly when orders were modified. By updating the global discount automatically, the system now accurately reflects any changes to order discounts, ensuring accurate pricing and refunds for customers. This improves the reliability of the Point of Sale system.
Original PR description
This commit uses an effect to update the global discount when changing the order. Fix the refound in when global discount since it was handeling only on discoud line where there could be various (one discount line per tax). Task-5421479 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#252194 Forward-Port-Of: odoo/odoo#241605
This update streamlines the settings search by focusing only on key field information like labels and descriptions. Previously, the search was unreliable due to performance limitations, resulting in inconsistent results across different pages. This change ensures a more reliable and predictable search experience for users.
Original PR description
Before this commit, the settings search scanned the inner HTML and text of the current page, including radio widget labels, buttons, and other miscellaneous text. However, due to performance constraints, this deep scanning was not possible on subsequent pages. This led to inconsistent results depending on which page the user was on when they started the search. This commit simplifies the search behavior to ensure consistency across all pages by limiting the search scope to specific field metadata: labels, help text, title text (tooltips), and info text. task-6004912
This update ensures that stored field values in Odoo are consistent and don't rely on contextual information. Previously, these values could be unreliable due to caching issues, particularly with related 'x2m' fields. This change improves data accuracy and stability, especially after recent updates to the x2m field caching system.
Original PR description
Stored values cannot depend on the context because they have a single stored value. We have a few exceptions: - "lang" for translated fields - "company" for company-dependent fields task-2903826 Fix x2m related fields after the cache pollution fix odoo/odoo#254944: the related x2m fields need to be computed in sudo to fill the cache with all values. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refactors internal code references (t-ref) to align with the upcoming Owl 3 migration. The changes ensure compatibility with the new system semantics and address previously overlooked or recently added references within several Odoo Enterprise modules. This is a necessary step to ensure a smooth transition to the next version.
Original PR description
To prepare the owl 3 migration, we need to open the t-ref directive to the new semantics. This commit fixes a few t-ref that were forgotten or recently added in Odoo Enterprise.
This update resolves a validation error that occurred when generating offers due to a recent change requiring a 'version_id' field. The fix ensures that this 'version_id' is now correctly passed during the salary simulation process, allowing offer generation to proceed smoothly.
Original PR description
-**ISSUE**: Since the "version_id" field in hr.payslip.worked.days model became a required field, the validation error exists. -**FIX**: "version_id" is passed inside the salary simulation payslip. Forward-Port-Of: odoo/enterprise#112602
This update resolves an issue where adding recurring prices to subscription products with multiple companies resulted in an error. It also fixed a bug preventing recurring plans set with a company from appearing in the recurring prices list. The change ensures proper company handling within the subscription product setup.
Original PR description
## Issues When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears. Also, recurring plans with their…
## Issues When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears. Also, recurring plans with their *Company* field set do not appear in the list of recurring plans when adding a line in the *Recurring prices* tab. ## Steps to reproduce 1. Install *Subscription* (`sale_subscription`) 2. Create a second company 3. Create a subscription product and set a company in the *Company* field (`company_id`). 4. In the *Recurring prices* tab, add a line (any recurring plan, any price) 5. **An _Invalid Operation_ error appears: _"Uh-oh! You’ve got some company inconsistencies here"_** For the second issue, after the same 3 first steps: 1. Create a *Recurring Plan* RP with its *Company* field set to the current company 2. On the *Recurring prices* tab of the subscription product, try to add a line with the Recurring plan RP 3. **The Recurring plan RP is missing from the list of available plans.** ## Cause When adding a line to the *Recurring prices* tab, a new `product.pricelist.item` is created, with no `pricelist_id`. The `ProductPricelistItem._compute_company_id` from `sale_subscription` filters out the items that don't have a `pricelist_id`, which is the case for the line we create. Also, the (potentially new) plan has no `company_id` in most cases. https://github.com/odoo/enterprise/blob/ccab0c261040ed995d12dca891caae9596bbe1eb/sale_subscription/models/product_pricelist_item.py#L18-L26 By filtering the items with no `pricelist_id`, nothing is passed to the `super()._compute_company_id`, even though it would also handle cases where the item has a `product_tmpl_id`: https://github.com/odoo/odoo/blob/9c8112d794af1ba84ade8af124967495c2ff8995/addons/product/models/product_pricelist_item.py#L170-L173 opw-5981629 opw-6051978 Forward-Port-Of: odoo/enterprise#109403
This update ensures that XML export tests correctly validate tax reports for Italy (l10n_it). A recent change in testing procedures now requires the inclusion of a tax code, which this commit adds to the test setup. This resolves a validation failure and ensures accurate report generation.
Original PR description
Description of the issue this commit addresses: Previously, the testing of the xml exports was only done by generating the file and checking its content against a hardcoded one but a fix[^1] changed that so the tests use the real export flow during which an xsd validation is done. As the tests did not expect to go trough the validation, some mandatory values were not present and it now results in a failing validation (caught in except). [^1]: https://github.com/odoo/enterprise/pull/108548 Desired behavior after this commit is merged: The tests set the l10n_it_codice_fiscale field from which are populated the mandatory CodiceFiscaleDichiarante, CodiceFiscale and CFDichiarante for the xsd validation. opw-5707544 Forward-Port-Of: odoo/enterprise#112629
This update resolves an issue where confirming quantities of archived products through the barcode app would cause a crash. The fix ensures that archived products are included in search results, allowing users to accurately add and confirm quantities, maintaining consistent functionality.
Original PR description
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to…
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to Settings and enable Multi-Step Routes > Set Warehouse Routes. - Configure 2 steps for outgoing shipments. - Go to Inventory and create a new delivery with - **Source Location:** WH/Stock - **Product:** [E-COM10] Pedal Bin with demand 1 - Mark as Todo then Archive the Pedal Bin product. - Open that delivery in barcode app - Pencil icon > +1 > Confirm ## Observed behavior: TypeError: Cannot read properties of undefined (reading 'qty_available') ## Root cause: After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above. ## Solution: Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error. It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button followed by validation, ensuring consistency. [commit]: https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 [2]- https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45 opw-5980428 Forward-Port-Of: odoo/enterprise#112616 Forward-Port-Of: odoo/enterprise#109204
This update restores the user-friendly display of VoIP call durations, showing times like '9m 12s' instead of numeric values. A previous change attempted a different formatting approach but caused issues, leading to a revert. A new test tour has been added to ensure the duration format remains consistent across views.
Original PR description
Commit [1] recently updated VoIP duration format on all screens (views and the softphone UI) to be "human readable", going from something like 00:09:12 to 9m 12s. For the softphone UI, it meant using…
Commit [1] recently updated VoIP duration format on all screens (views and the softphone UI) to be "human readable", going from something like 00:09:12 to 9m 12s. For the softphone UI, it meant using the framework util. For the views, the framework field options using that framework util was not possible to use to have the desired format. Instead, the existing "duration_human_readable" field, computed from "duration", which existed already as it is needed in some python text, was used. Commit [2] broke the views format a few days later. That commit refactored the framework util and field options. Doing so, the softphone UI computation was adapted, correctly. However, the views was switched back to using the default "duration" field with the numeric option, probably because of an ignored conflict. This commit restores the use of "duration_human_readable", as the field util still does not allow to have the wanted format. Indeed, switching off the "numeric" option would show 2m 3s as 0h 2m 3s, which we do not want. We could solve that by changing our DB field to be in seconds instead of hours though, but that would be a bigger change to decide. Still, using "duration_human_readable" which is needed either way makes a lot of sense. This commit adds a tour that checks the format does not change in views whatever field is used. [1]: https://github.com/odoo/enterprise/commit/52e24578700fffde05d9d8f767258aea5f185e8d [2]: https://github.com/odoo/enterprise/commit/fa9329a08eb78c6a9cacfd31a9a1f4bc9e9b6030 Related to task-5951753
This update ensures that installment payment terms on customer invoices generated for Peru (l10n_pe_edi) are correctly ordered by their maturity date. Previously, invoices generated with multiple installments could have a mixed-up XML format due to the order in which payment terms were created. This fix guarantees accurate and compliant UBL documents for Peru.
Original PR description
**Steps to reproduce:** * Install `l10n_pe_edi`. * Set SUNAT as the signature provider. * Create a customer invoice. * Select a payment term with multiple installments (e.g. 50% (15 days) / 30% (10…
**Steps to reproduce:**
* Install `l10n_pe_edi`.
* Set SUNAT as the signature provider.
* Create a customer invoice.
* Select a payment term with multiple installments (e.g. 50% (15 days) / 30% (10 days) / 20% (5 days)).
* Confirm the invoice and generate the EDI standard UBL document.
**Observed behavior:**
* The XML `<cac:PaymentTerms>` instalment nodes (Cuota001, Cuota002, etc.) are ordered according to the database insertion order of the receivable lines.
* If the payment term lines are created in a non-chronological order, the installments in the XML mix up the `Cuota` ID, amount, and `PaymentDueDate`.
**Cause:**
* `_add_invoice_payment_terms_nodes` iterates over `invoice.line_ids` to generate the installments, but does not sort the receivable account lines by their `date_maturity`.
**Fix:**
* Explicitly call `.sorted('date_maturity')` on the receivable lines before generating the `invoice_date_due_vals_list`.
opw-6035589
Forward-Port-Of: odoo/enterprise#112698
Forward-Port-Of: odoo/enterprise#112162This pull request reverts a previous change that was causing issues with email notifications related to contract salaries within the Enterprise module. The change was rolled back to restore the original functionality and prevent disruptions to payroll processes. This ensures accurate and timely salary communications.
Original PR description
Revert https://github.com/odoo/enterprise/pull/111815 Forward-Port-Of: odoo/enterprise#112632
This update clarifies how the annual leave provision is calculated in the payroll system. Previously, it triggered prematurely and displayed confusing rates. Now, it’s applied only to employees after their first year and uses a clear monthly working days calculation, ensuring accurate reporting.
Original PR description
## Before: - Annual Leave Provision showed a confusing rate value. - It could be triggered too early around the first-year period. - “Excluded from Net” was checked. ## After: - Annual Leave Provision is applied only for active employees after one year. - The amount is based on monthly working days, while the displayed rate stays clear at 100%. - “Excluded from Net” is unchecked. Task-6033568 Forward-Port-Of: odoo/enterprise#111225
This update resolves an issue where sales orders with upsells lacking recurring products couldn't be previewed. The change allows this functionality, aligning with existing constraints within the system. This ensures a smoother sales process for users.
Original PR description
When you have an upsell that does not have recurring products, you cannot preview the SO, so we've allow it in this specific case as it is allowed by the constraint on the model Forward-Port-Of: odoo/enterprise#112453
A bug was preventing demo accounts from fully connecting within the Odoo Enterprise system. This fix temporarily resolves the issue by allowing users to set the business type to 'individual' as a workaround. This ensures users can now properly test the demo feature until a permanent solution is implemented.
Original PR description
Step to reproduce: - Click on Connect (demo) - The accounts stay Restricted (even after 5m) This is due to the requirement `company.verification.document` which is present as a pending_verification even when no document is given. Giving it a document such as `file_identity_document_success` which should "marks that document requirement as satisfied" also doesn't work. A work-around is to set the business type to individual since they dont have this requirement. This is a temporary fix, as we want to keep a flow similar to what would have been done in reality. But this is preventing users from testing the feature in 19.0 up to master. Forward-Port-Of: odoo/enterprise#112612
This update resolves an issue where products were incorrectly being deleted from the website generator when a product template only had one associated product. The fix ensures that product records are only removed when intended, maintaining data integrity and preventing potential data loss.
Original PR description
product.product records were being removed when they should not have been in the case that the product.template only has one product.product record. This commit fixes this issue by accounting for the case where there is only one product.product record. Forward-Port-Of: odoo/enterprise#112519
This update resolves a crash that occurred when printing DIAN support documents. The fix prevents a system error by ensuring that report sections are only generated when a valid DIAN attachment exists, improving the printing process for users. This ensures accurate and reliable printing of these important documents.
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#109912 Forward-Port-Of: odoo/enterprise#108645
This update resolves a technical issue related to how binary data is handled in the l10n_be_reports module, specifically impacting Belgian VAT reporting. The change ensures accurate processing of financial data by aligning with a recent update in Odoo's data handling system. This fix improves the reliability of VAT reports for our Belgian clients.
Original PR description
update the intervat code to fit with the new BinaryValue, see https://github.com/odoo/enterprise/pull/104714 no-task
This update resolves an issue where AI conversations within the Odoo Enterprise app were sometimes failing to connect properly with agents. The fix clears the AI conversation correspondent when it resolves to the current user, preventing unwanted self-chat behavior and ensuring agents receive correct communication. This improves the reliability of the AI assistant.
Original PR description
Override AI thread correspondent computation to keep the base behavior but clear the correspondent when it resolves to the current user in ai_composer/ai_chat. This avoids self-chat fallback side effects (like OOO banner) while preserving agent flows that rely on a real non-self correspondent. source of this crash: https://github.com/odoo/enterprise/pull/108217 Forward-Port-Of: odoo/enterprise#112622 Forward-Port-Of: odoo/enterprise#111736
This update resolves an issue that prevented users from creating contracts when a working schedule had zero hours assigned. The fix prevents a division-by-zero error during hourly wage calculation, ensuring contract creation can proceed smoothly. This improves the reliability of the payroll module for Australian companies.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#112450 Forward-Port-Of: odoo/enterprise#111629
This update fixes an issue where splitting shifts within a single day resulted in duplicated and incorrect timeframes. Previously, the system forced shifts into standard working hours, causing problems when splitting shifts on a daily basis. Now, shifts are split accurately at the requested time, ensuring correct scheduling.
Original PR description
Since odoo/enterprise#69963, splitting a shift in Gantt view snaps the resulting shifts to the standard working hours (e.g., 08:00 to 17:00). This behavior makes sense when splitting a multi-day shift across a day off, where we want to generate a full working day for the day off as well. However, when splitting a shift within a single day (day scale), this behavior is not wanted, otherwise creating two shifts as follows: 1. A shift from [Original Start] to 5pm 2. A shift from 8am to [Original End] Clearly, the shift is duplicated with the wrong timeframes and adding time outside the original shift's hours. This commits ensures that, when splitting a shift in hours (i.e., when using `day` view scale), the shift is appropriately split at the time requested. For instance: 1. A shift from [Original Start] to [Split Time] 2. A shift from [Split Time] to [Original End] task-5387243 Forward-Port-Of: odoo/enterprise#105991
This update resolves a technical issue related to the EU IoT scale driver. As part of the fix, the checksum associated with the scale certification process has been updated to ensure data integrity and compliance. This change is a routine maintenance task.
Original PR description
As we fixed the scale driver, we need to update the checksum. see odoo/odoo#256816 Forward-Port-Of: odoo/enterprise#112594
This update resolves a crash issue that occurred when starting pay runs through the warning dashboard. The change replaces a problematic context variable with a more reliable structure ID, ensuring pay runs can consistently begin. This improves the overall stability and usability of the payroll system.
Original PR description
Use structure_id instead of the removed schedule_pay context to avoid crashes when starting a pay run from the warning dashboard. task: 6067447
This update resolves an issue where the attendance step in the payrun flow wasn't correctly displaying on smaller screens. The change ensures the attendance step view adjusts properly when the screen size changes, improving the user experience and preventing errors during payrun creation.
Original PR description
. Fix Attendance step view on the payrun flow task-6085093
This update resolves an issue where scanning packaging barcodes didn't correctly associate with related lots, leading to incorrect inventory tracking. The fix ensures that packaging barcodes are properly linked to lots during scanning, improving the accuracy of stock management.
Original PR description
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with…
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Go to barcode > Operations > eg. internal transfer > New * Scan packaging barcode * Scan one of the lots -> Issue, the lot create a new line, and will not find the packaging ### Observation: When scanning a barcode, it will first try to find a match with existing lines, In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501 It will erase the line, to avoid to overfill a completed line: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460 and since, it decided to ignore that line, it will not find another lines, and will create a new one : https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535 Additional Issues ----------------- Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots. Issue 2 : When having sublines with different uoms, it will add the quantity without considering the differences in uoms ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Create a packaging 2 with barcode for product A * Go to barcode > Operations > eg. internal transfer > New * Scan packaging 1 barcode * Scan one of the lot 1 * Scan packaging 1 * Scan lot 2 -> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot. * Scan packaging 2 -> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms ### Observation: Issue one : When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460 and since, it found a line, it will just add it's self to the line Issue Two: When creating the group lines it will first calculate the sum of all the quantities: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254 And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461 opw-5189492 opw-5408372 Forward-Port-Of: odoo/enterprise#110847 Forward-Port-Of: odoo/enterprise#98701
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu p
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own…
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724 Forward-Port-Of: odoo/enterprise#111240 Forward-Port-Of: odoo/enterprise#109012
On mobile, when how_to_call_on_mobile is set to ask, dismissing the call method selection dialog still triggers an outgoing call. Task-[6060319](https://www.odoo.com/odoo/5778/tasks/6060319)
Original PR description
On mobile, when how_to_call_on_mobile is set to ask, dismissing the call method selection dialog still triggers an outgoing call. Task-[6060319](https://www.odoo.com/odoo/5778/tasks/6060319)
Why: In the Belgian localization, creating a new version of an employee with the fixed_term flag enabled triggers a search for anterior_versions within the last two years. During the creation of a new version, the contract_date_start field may temporarily be False or unset. Attempting to compare a stored version's start date against a null value (v.contract_date_start <= self.contract_date_start) results in a server-side traceback, blocking the versioning process entirely. What: - Added a s
Original PR description
Why: In the Belgian localization, creating a new version of an employee with the fixed_term flag enabled triggers a search for anterior_versions within the last two years. During the creation of a new version, the contract_date_start field may temporarily be False or unset. Attempting to compare a stored version's start date against a null value (v.contract_date_start <= self.contract_date_start) results in a server-side traceback, blocking the versioning process entirely. What: - Added a safety check to the fixed_term conditional logic. - The filtering of anterior_versions is now only executed if both fixed_term is True AND contract_date_start is populated. task-6060255
- Steps to reproduce: install payroll and attendance, then in employee go on Anita Oliver's form and click on the warning "View Pay Runs". The payrun page sould open and traceback appear. - Reason: the action triggered by the warning does not specify a view id, wich defaults to hr.payrun.attendance.kanban.card (if payroll and attendance installed) or hr.payrun.blank.kanban.card (if payroll only). - Solution: explicitely specify id of the right payrun view (hr.payslip.run.kanban) - Test added
Original PR description
- Steps to reproduce: install payroll and attendance, then in employee go on Anita Oliver's form and click on the warning "View Pay Runs". The payrun page sould open and traceback appear. - Reason: the action triggered by the warning does not specify a view id, wich defaults to hr.payrun.attendance.kanban.card (if payroll and attendance installed) or hr.payrun.blank.kanban.card (if payroll only). - Solution: explicitely specify id of the right payrun view (hr.payslip.run.kanban) - Test added in hr_payroll_attendance Task: 6036545
**Steps to Reproduce:** 1. Open the Attendance app (Make sure hr_payroll module is installed). 2. Immediately create a custom filter which does not produce results (Eg: IP Address = 1) 3. Observe the OwlError: Component is destroyed in the Traceback. **Bug Cause:** When AttendanceGanttController is wrapped by PayRunMixin, the Layout component is replaced by PayRunLayout. PayRunMixin's onRendered hook unconditionally triggered updatePayRun() on every render, which incremented state.re
Original PR description
**Steps to Reproduce:** 1. Open the Attendance app (Make sure hr_payroll module is installed). 2. Immediately create a custom filter which does not produce results (Eg: IP Address = 1) 3. Observe the OwlError: Component is destroyed in the Traceback. **Bug Cause:** When AttendanceGanttController is wrapped by PayRunMixin, the Layout component is replaced by PayRunLayout. PayRunMixin's onRendered hook unconditionally triggered updatePayRun() on every render, which incremented state.revId and forced the Record component (t-key="state.revId") to be destroyed and recreated. This caused a re-render cascade that destroyed AttendanceActionHelper mid-onWillStart, while its async calls (hasGroup, orm.call) were still in flight. **Solution:** In PayRunMixin, guard updatePayRun() so it only fires when payRunId actually changes, instead of on every render. This prevents unnecessary re-render cascades that were destroying AttendanceActionHelper. **Task: 5972786**
This commit uses an effect to update the global discount when changing the order. Fix the refound in when global discount since it was handeling only on discoud line where there could be various (one discount line per tax). Task-5421479 Forward-Port-Of: odoo/enterprise#109647 Forward-Port-Of: odoo/enterprise#109481
Original PR description
This commit uses an effect to update the global discount when changing the order. Fix the refound in when global discount since it was handeling only on discoud line where there could be various (one discount line per tax). Task-5421479 Forward-Port-Of: odoo/enterprise#109647 Forward-Port-Of: odoo/enterprise#109481
When doing a fresh install of accounting with your company language set to Hebrew, you will receive an error violating a constraint on the account_journal table due to the code column being Varchar(5) and the Hebrew translations of "INV" and "BILL" having the same first 5 characters. This commit will allow users to install Accounting when their language is set to Hebrew or switch to the l10n_il with no journals in their database and their language set to Hebrew. Reproduction steps: - Uni
Original PR description
When doing a fresh install of accounting with your company language set to Hebrew, you will receive an error violating a constraint on the account_journal table due to the code column being Varchar(5) and the Hebrew translations of "INV" and "BILL" having the same first 5 characters. This commit will allow users to install Accounting when their language is set to Hebrew or switch to the l10n_il with no journals in their database and their language set to Hebrew. Reproduction steps: - Uninstall Accounting + Invoice - Set company language to Hebrew - Install accounting (which will install Invoice) Community PR: odoo/odoo#253737 Ticket [link](https://www.odoo.com/odoo/project.task/6001568) opw-6001568
Features or functions removed from Odoo
This update removes restrictions on which PEPPOL numbers can be used for registration. Previously, only numbers from the PEPPOL list were accepted. Now, businesses can register with a wider range of PEPPOL numbers, increasing flexibility and potential reach for international transactions.
Original PR description
Before this commit, only numbers on the peppol list were able to be registered. Now is possible to add numbers from other countries. Task-6033336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254373
Code cleanup and technical improvements
This update ensures Odoo's cron jobs maintain transactional consistency by adding a rollback function. Previously, using these functions outside of cron jobs could disrupt data integrity. This change enhances the reliability of automated processes within Odoo.
Original PR description
For the symmetry of the API, adding `_rollback_progress` to `_commit_progress`. This also allows us to check which commits or rollbacks are used in models, because using them in models outside of cron jobs breaks the transactional behaviour of Odoo. https://github.com/odoo/enterprise/pull/112717 https://github.com/odoo/documentation/pull/17206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances Odoo's email functionality by improving the efficiency of batch processing and adding comprehensive tests. Specifically, the changes address recent code modifications and incorporate new features like voice trace support, ensuring reliable email delivery and performance. The work also includes cleanup and documentation improvements within the email modules.
This update optimizes how Odoo handles the rollback of cron jobs, specifically related to progress tracking. The changes improve the efficiency of these background processes, reducing potential delays and ensuring smoother operation of key business features like order processing and subscription management. This is a routine maintenance update focused on internal performance.
Original PR description
https://github.com/odoo/odoo/pull/257066
Miscellaneous changes
The goal of this PR is to move the code from the bridge modules introduced in the CSRD/VSME reporting feature that was deployed in stable versions (see https://github.com/odoo/enterprise/pull/96759). So that the codebase will be cleaner and easier to maintain. Modules change: esg_csrd -> esg esg_csrd_hr -> esg_hr esg_csrd_hr_fleet -> esg_hr_fleet esg_csrd_ai -> ai_esg Where we will move the fields, views, menu items, data, files, etc. Nothing should change functionally. We also ad
Original PR description
The goal of this PR is to move the code from the bridge modules introduced in the CSRD/VSME reporting feature that was deployed in stable versions (see https://github.com/odoo/enterprise/pull/96759). So that the codebase will be cleaner and easier to maintain. Modules change: esg_csrd -> esg esg_csrd_hr -> esg_hr esg_csrd_hr_fleet -> esg_hr_fleet esg_csrd_ai -> ai_esg Where we will move the fields, views, menu items, data, files, etc. Nothing should change functionally. We also add some tests related to the data injected in the VSME/CSRD PDF report. task-5882219