Daily updates from Odoo
Navigate
Branch
Wednesday, May 6, 2026
309 changes
29 changes
Enhancements to existing features
This update splits a key accounting account to better align with French tax regulations (ANC PCG 2026). Specifically, it separates social security charges from salaries within the Profit and Loss report, ensuring accurate financial reporting for French businesses. The original account remains but is marked as deprecated.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784 Forward-Port-Of: odoo/odoo#260262 Forward-Port-Of: odoo/odoo#255038
Resolved issues and error corrections
This update resolves an issue where the 'short description' field on the website slides wasn't being populated correctly when the description was blank. The fix ensures that the field is populated appropriately, maintaining consistent presentation of slide information. This improves the overall quality and accuracy of the website's slide content.
Original PR description
In the PR #246357 the code for populate_description_short was adapted wrongly. When the `vals.get('description_short', False) is False`, the description_short field won't be populated correctly.
This commit fixes the issue.
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-prThis update adjusts the placement of editing tools (pencils) within Odoo reports. The change moves the pencil icon to the right of editable values, improving usability and making it easier for users to modify report data. All report values have been aligned for consistency.
Original PR description
The UI for editable values in reports was recently revamped. Currently, the pencil icon for editing the values is awkwardly positioned between the text and the value of a line in a report. This change moves the pencil to the right of any editable values. All report values have been shifted so that they are still right-aligned, regardless of whether they are editable or not. task-6086452
This update enhances Odoo's ability to maintain partner information offline. By optimizing how multi-ID data is handled, the system now avoids unnecessary calls to the server, allowing partner forms to remain available even when offline. This improves the user experience and data accessibility.
Original PR description
Change the multi ID Json (additional_identifiers) to avoid the rpc call on each country_code change and rely on a computed field to keep the partner form available offline. task-none
This update corrects a recent change in how Odoo handles geoIP location data. Previously, the system incorrectly favored the city database as a fallback, which is now reverted to prioritize the country database for optimal accuracy. This ensures more reliable location information is used for our users.
Original PR description
There are two geoip database: a small and fast-to-query country database, and a big but slower-to-query city database. As the City record inherits from the Country record, we can access the country…
There are two geoip database: a small and fast-to-query country database, and a big but slower-to-query city database. As the City record inherits from the Country record, we can access the country informations from the City record. In our case it means that when the ip was geolocalized against the city db, we can reuse the city record for the country informations, we don't need to query the country db. It also means that in case the country database does not exist, we can query the city database for the equivalent country information: it is slower but returns the information. In commit 06b0e0017651 we tried to simplify the code a bit, and decided to return the city database as fallback to the country database when the latter was not found/corrupt. This is wrong because if the city and country *records* are indeed compatible, the city and country *databases* are not. This commit reverts the changes that were included in the `[MOV]` commit. Reference-to: 06b0e0017651 ([MOV] core: http.router.root.geoip -> http.geoip) Forward-Port-Of: odoo/odoo#259412
This update fixes a calculation error in the l10n_ar_withholding module that resulted in an incorrect payment amount. The fix ensures accurate withholding tax calculations for payments, preventing discrepancies between the expected and actual amounts. This improves financial reporting accuracy.
Original PR description
**Steps to reproduce:** * Install `l10n_ar_withholding` module. * Create a vendor bill and click on 'Register Payment' to open the payment wizard. (i.e. amount 25000, tax 21%) * Select 'Own Checks'…
**Steps to reproduce:** * Install `l10n_ar_withholding` module. * Create a vendor bill and click on 'Register Payment' to open the payment wizard. (i.e. amount 25000, tax 21%) * Select 'Own Checks' within the payment method. * Clear Withholding lines and add line with tax `IIBB WTH CABA`. * In the Checks tab, input the check number, date, and amount (30000) natively. * The computation of the withholding lines is triggered. **Observed behavior:** * The total gross amount registered computes to exactly $30,247.93 instead of mathematically converging to the true original invoice debt of $30,250.00. **Cause:** * The `l10n_ar_withholding` module uses an iterative mathematical solver to progressively bump `wizard.amount` upward to effortlessly offset and scale the equivalent proportionate withholding taxes accurately. * However, inside Odoo's iterative memory loop (`for i in range(201)`), the ORM caches computed values across passes for NewId performance. As `wizard.amount` increments upwards, the dynamically dependent `l10n_ar_withholding_ids.base_amount` and `amount` fields fail to automatically invalidate their internal cache. * The loop relies on these statically cached values (e.g., $247.93) to verify if equilibrium has been reached, wrongfully satisfying the balancing exit condition and halting the loop prematurely. **Fix:** * Recompute the `base_amount`, `amount` using `add_to_compute` on the `l10n_ar_withholding_ids` automatically inside the iterative loop in `account_payment_register.py`. * This signals the ORM to cleanly dump the stale cache dependencies, natively forcing mathematically correct recalculations of the proportionate untaxed withholdings at every incremental `wizard.amount` step. The solver now strictly converges optimally to exactly block the correct value in 1-2 rapid passes without hanging on legacy computation artifacts. opw-5934489 Forward-Port-Of: odoo/odoo#254635
This update prevents Odoo from crashing when viewing order details without a linked employee. Previously, enabling 'Log in with Employees' could cause issues. Now, the system correctly displays the user who processed the order, ensuring a smoother experience.
Original PR description
**Before this commit** When trying to open an order's details, we would crash when that order does not have an employee associated with it. This can happen when the "Log in with Employees" setting is…
**Before this commit** When trying to open an order's details, we would crash when that order does not have an employee associated with it. This can happen when the "Log in with Employees" setting is enabled after at least one order has already been processed. **After this commit** If there isn't an `employee_id` associated with an order, don't try to overwrite the "Served By" field. By default, this should allow the name of the user who processed the order to be displayed. This can be seen in the original `getOrderFields()` method on the `OrderDetailsDialog` component. https://github.com/odoo/odoo/blob/e1c81c326e370b0a7b5bc8018b151e251ebce544/addons/point_of_sale/static/src/app/screens/ticket_screen/order_details_dialog/order_details_dialog.js#L81 This commit is mostly a backport of the slight refactor in 19.3, with the added benefit of still showing the names of the users who processed orders before `pos_hr` was installed on the database. https://github.com/odoo/odoo/blob/be57b42442db8c6be219d36f8c3e07e8baf45e31/addons/pos_hr/static/src/app/screens/order_details_dialog.js#L10-L15 opw-6169880 Forward-Port-Of: odoo/odoo#261622
This update ensures that invoices only include validated timesheets, preventing over-invoicing when sales orders have both validated and unvalidated timesheets associated with them. Previously, the system incorrectly included unvalidated timesheets in invoices, leading to inaccurate billing. This fix corrects a bug related to timesheet validation policies.
Original PR description
**Steps to reproduce** - Settings: Timesheets > Invoicing policy = only validated TS. - Have a service product with an invoicing policy based on timesheets. - Create a sales order using this product.…
**Steps to reproduce** - Settings: Timesheets > Invoicing policy = only validated TS. - Have a service product with an invoicing policy based on timesheets. - Create a sales order using this product. - From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them. - Invoice the SO, using a timesheets period that includes both TS. - Notice that the quantity of the invoice line includes the non-validated timesheet. **Cause** The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1 **Change** Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain. opw-6116670 Forward-Port-Of: odoo/odoo#262350 Forward-Port-Of: odoo/odoo#259224
This update fixes a problem where the payroll system incorrectly flagged users as unauthorized document owners in multi-company environments. The fix replaces a dependent field with a stored employee flag, ensuring accurate validation during background tasks regardless of the company context. This prevents errors related to generating payroll PDFs.
Original PR description
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for…
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for this employee. 4) Run the 'Payroll: Generate pdfs' cron. Error - ValidationError: The following user(s) cannot own root documents/folders: portal_employee: Payslip - portal_employee Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company). When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner. Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies. opw-6143042 Co-authored by Tina Lin (liti) Forward-Port-Of: odoo/enterprise#115570
This update resolves an issue where users weren't able to save settings when GST registration was unregistered. The fix ensures the system correctly checks the GST registration status, preventing a 'Missing Required Fields' error and allowing users to configure the necessary settings.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001 Forward-Port-Of: odoo/enterprise#116174 Forward-Port-Of: odoo/enterprise#114423
This update optimizes the HTML editor's performance by reducing unnecessary style recalculations during update processes. Previously, the system repeatedly checked element styles, leading to slower updates. This change improves the responsiveness and speed of the HTML editor, particularly when making frequent changes.
Original PR description
Description of the issue this PR addresses: Before this PR, updateHooks retrieved the computed style for each visible element and accessed marginTop and marginBottom inside the loop. Accessing properties of CSSStyleDeclaration may trigger style resolution, causing repeated 'Recalculate Style' work during hook updates. This PR extracts marginTop and marginBottom after getComputedStyle outside the loop, which reduces style reads during hook updates and avoids unnecessary style recalculations. task-6063534 closes odoo/odoo#252385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259341
This update fixes a potential issue where holiday creation could fail unexpectedly. By ensuring error handling is correctly applied during the core holiday creation process, the system is now more reliable and robust. This improves the overall user experience when managing employee holidays.
Original PR description
this commit, in this PR:https://github.com/odoo/odoo/pull/242299 the create method was refactored to wrap only the _create_all_new_leave call in a try/except block, ensuring that ValidationError is caught at the correct. Task-6179171 Forward-Port-Of: odoo/odoo#262609 Forward-Port-Of: odoo/odoo#262175
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to determining eligible occupations for holiday attestation. The change ensures accurate hour calculations for employees, resolving a potential discrepancy in holiday entitlements. This update improves payroll accuracy and compliance.
Original PR description
. use _get_hours_per_week() method instead of calling the field on the version task-6185339 Forward-Port-Of: odoo/enterprise#115990
A test related to rental stock management was failing due to duplicate configuration settings within the demo data. This fix ensures the test runs correctly by preventing the creation of redundant 'out of stock' ribbons, maintaining data integrity.
Original PR description
Currently, running test `test_out_of_stock_ribbon_is_not_applicable_for_rentals` with demo data enabled leads to a validation error: `Only one ribbon with the "assign when out of stock" option is allowed.` This happens because, with demo data loaded, an "out of stock" ribbon is already created via XML data. The test then attempts to create another ribbon with the same configuration, triggering the constraint and causing the failure. Related PR: https://github.com/odoo/enterprise/pull/112660 runbot-[242457](https://runbot.odoo.com/odoo/error/242457) --- Forward-Port-Of: odoo/enterprise#116162
This update fixes an issue where the product amount in the quotation preview was incorrectly showing tax excluding prices. The fix ensures that when 'Tax Included' is selected in settings, the preview and PDF reports accurately display the total price, including taxes. This improves the accuracy of sales quotes for our customers.
Original PR description
**Steps to produce:** - Install `sale_management` without demo data. - In settings > Under Taxes > Set `Tax Prices` as `Tax Included`. - Create a product with a sales price of 10. - Create a…
**Steps to produce:** - Install `sale_management` without demo data. - In settings > Under Taxes > Set `Tax Prices` as `Tax Included`. - Create a product with a sales price of 10. - Create a quotation with this product. - Confirm the line amount shows 10 (tax included). - Click on preview. **Observation:** - In the preview, the product line amount is shown as tax excluded. **Root cause:** - At [1], when in the company setting `tax included` is selected, the system displays `price_total` instead of `price_subtotal`. - This logic is not applied in the portal preview and PDF report. **Solution:** - Apply the same logic in portal preview and PDF reports: display `price_total` when taxes are included, otherwise `price_subtotal`. [1]https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/sale/views/sale_order_views.xml#L656-L663 Before: --- <img width="1031" height="384" alt="image" src="https://github.com/user-attachments/assets/743abbec-9225-4f77-894b-193052ee8e42" /> After: --- <img width="1052" height="391" alt="image" src="https://github.com/user-attachments/assets/61d2b331-e197-4ca0-a71d-e307d9bf80fe" /> opw-6089473 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261892 Forward-Port-Of: odoo/odoo#258551
A technical error preventing cash payments on POS terminals using Razorpay was resolved. The fix ensures the system correctly handles payment selections, preventing a 'null value' error that interrupted the transaction process. This improves the reliability of cash payments within the Odoo POS system.
Original PR description
Steps: - Open a POS configuration with the Razorpay payment method set to all payment modes. - Process an order and initiate a Razorpay transaction. - Select a cash payment option on the terminal. Issue: - A traceback occurs with the error: `Cannot read properties of null (reading 'replace')`. Cause: - The code attempts to call the replace method on a null value. Fix: - Ensure the replace method is called only when the value is a valid string. Task-6190355 Forward-Port-Of: odoo/odoo#261922
This update corrects a technical error that was preventing livechat channels with AI agents from appearing correctly to users. The fix ensures the system accurately counts agents linked to each livechat channel, resolving a visual issue. This improves the user experience for livechat functionality.
Original PR description
The number of agents linked to a livechat channel was always 0 because of a mistake in the code. This prevented livechat channels with AI agents from appearing to users. This commit fixes the problem. task-5409200 Forward-Port-Of: odoo/enterprise#114404 Forward-Port-Of: odoo/enterprise#111574
This update optimizes the way the spreadsheet component interacts with field selections, reducing unnecessary processing. Previously, a repeated process caused performance slowdowns. This change improves the overall responsiveness and efficiency of the spreadsheet feature.
Original PR description
Currently, the component `ModelFieldSelector` will call the field service on `willUpdateProps` regardless of its current state. Since the introduction of the persistent cache, there is a slight overhead when calling the fieldService (notably caused by the call to deepCopy) and this call can now become costy when called repeatedly, which occurs in the spreadsheet component for instance. Task-6185388 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#262497
This update resolves an issue where adding a lot to a detailed operation on a stock move would reset the quantity and erase the lot. The fix ensures that component moves are correctly picked when a lot is added, preventing data loss and ensuring accurate production tracking. This improves the reliability of subcontracted production workflows.
Original PR description
### Steps to reproduce: - Create and confirm an MO for 1 unit of product without bom - Set the producing quantity to 1 - Add a new component line for a product tracked by SN - Click on details…
### Steps to reproduce: - Create and confirm an MO for 1 unit of product without bom - Set the producing quantity to 1 - Add a new component line for a product tracked by SN - Click on details operation and add a lot > Save - Produce all #### > The quantity is of the component move is reset to 0 and the lot erased ### Cause of the issue: Setting the producing quantity to 1 will set the state of the of the MO to `to_close`. After which, adding a new move will add it in the appropriate `picked` state so that the move is considered when validating the MO: https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/mrp/models/stock_move.py#L269-L270 However, clicking on the detailed operation and selecting a lot will create a new `move_line` without set `picked`. As such the related picked compute method of the stock move will be launched: https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move_line.py#L123-L127 resetting the picked state of the move to False as a new move line was added (triggering a dependency of its compute method): https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move_line.py#L126 https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move.py#L280-L286 Additional change: The test `TestSubcontractingBasic.test_flow_tracked_1` underlined that the `auto_pick_move_lines` context key added to `action_show_details` had to be cleaned in subcontracting flows before synchronizing the subcontracted productions: https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/mrp_subcontracting/models/stock_move_line.py#L34-L38 Otherwised, if a receipt for tracked subcontracted product is picked and additional move lines are added via the detailed operations, the subcontracted backorders created to fulfill the additional demand will will pick each of their move leading to subcontracted MO's that will avoid assignment: https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/stock/models/stock_move.py#L1914-L1916 and be cancelled at the picking validation: https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/mrp/models/mrp_production.py#L1924 https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/stock/models/stock_move.py#L2107-L2109 This can be checked by launching the test without the `clean_context`. We also improve the `TestSubcontractingBasic.test_flow_tracked_1` test as it is not possible to edit moves to be picked prior to confirmation and since move lines can not manually be created in picked state. ### Fix: Note that we rely on a context key to adapt the compute method of the picked field of the `stock.move.line` instead of adding a `default_picked` context in the `action_show_details` because the new move lines added to the list view of the `move` form are generated via the UI by opening a list of `stock.quant` which cleans the `default_context` key prior to generation of the `new` move line. In particular, the exact UI flow can not be tested by relying on the `Form` class of stock moves since the new move lines will then be created by via the `O2MForm` class: https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L642-L658 and an onchange of the stock move line will be triggered to determine its value relying on the `default_picked` context key to create the new move line in picked state: https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L332-L339 https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L579 https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/addons/web/models/models.py#L2005-L2008 By contrast performing the flow from the interface will highlight that the `default_picked` context key does not solve the issue. opw-5991985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258935
This update resolves an issue where users lacking access to employee data would encounter an error when trying to view attendance records. The change corrects a technical detail related to accessing employee information, ensuring all users can access the Attendances feature. This improves usability for all employees.
Original PR description
Steps to reproduce: ---------------------------------------- - Connect with a user having no rights on Employee - Try to open Attendances - Access error Cause: ---------------------------------------- Since 218b91cad3e50b27a84624145c89ed6bb23f18c5 we read the field `is_flexible` on employee which is a field only accessible to `hr.group_hr_user` ([src](https://github.com/odoo/odoo/blob/70ade77937bfc171a3352e70c5c78bfd87ceb4d1/addons/hr/models/hr_version.py#L154)). opw-6179252 Forward-Port-Of: odoo/enterprise#116052
A minor typo in the French Profit & Loss report (P&L) has been fixed. Specifically, the term 'exceptionnel' was incorrectly using masculine form when it should be feminine to accurately reflect charges. This ensures correct reporting for French-speaking users.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges. Forward-Port-Of: odoo/enterprise#116198
A bug in the testing process was causing tests to fail when demo data was loaded. This was due to a duplicate IoT Box record existing in both the test setup and the demo data. This fix resolves the conflict, ensuring tests run correctly and reliably.
Original PR description
We define an IoT Box record in tests with name "Shop". Another IoT Box with this name is defined in the demo data of the module. As a result, when tests are started with demo data loaded, we tend to click on the first IoT Box record with whis name, which correspond to the one from demo data. Some tests are then failing as they can't find device record defined in the test setup. related: odoo/enterprise#96760 Forward-Port-Of: odoo/enterprise#116234
This update clarifies French accounting reports by splitting a key account to accurately separate social security charges from salaries. This change ensures compliance with French accounting standards (ANC PCG 2026) and improves the accuracy of financial reporting. The old account remains for legacy systems but is marked as deprecated.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784 Forward-Port-Of: odoo/enterprise#114412 Forward-Port-Of: odoo/enterprise#111420
This update resolves an issue where text highlights in the website editor were incorrectly displayed in front of the text on Firefox. The fix reorders how SVG highlight elements are added to the HTML, ensuring they render behind the text as intended. This improves the visual consistency of the website editor across different browsers.
Original PR description
# How to reproduce - Go to the website editor - Select some text that wraps - Add text highlight to that text # The problem On firefox, for every line of text that wraps, the highlight is displayed in front of the text instead of behind. # Why The highlights are made of SVG's that are added to the html element of the selected text. To be sure that theses SVG's are displayed behind the text, they have position: absolute and z-index: -1. Sadly, z-index and absolute positionning in an inline context (like in a span) is a browser specific behavior and in the case of firefox, seems to sometimes be ignored. Since the SVG's are appended in the html element after the text, they are rendered after. This fix aims to insert the SVG's in the html element before the text to make sure the rendering order is correct opw-5976647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254196
This update ensures continued functionality with Sendcloud by incorporating their legacy API version 2 key. Sendcloud has transitioned to a new API version, and this change allows existing users to maintain seamless delivery processing. Future work will focus on upgrading to the latest Sendcloud API version 3.
Original PR description
Sendcloud pass their api v2 to maintenance and only provide new api V3 key to the new customers. In order to make a smooth transition for the user we add the partner key, so they know that the customer are coming from odoo and they use the v2 api. Future work will be done to upgrade our module and support the v3. API key. Forward-Port-Of: odoo/enterprise#115999 Forward-Port-Of: odoo/enterprise#114441
This update fixes an issue where users could select customers from different companies within the Helpdesk module. The fix involved adding a restriction to the customer selection dropdown, ensuring users only see customers within their assigned company. This improves data accuracy and prevents errors when creating new support tickets.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#116157 Forward-Port-Of: odoo/enterprise#111909
This update resolves a technical error preventing the import of emissions data, specifically related to journal entries. The fix restricts imports to manual emissions, ensuring data integrity and preventing database issues. This improves the reliability of our ESG reporting capabilities.
Original PR description
The import button is present in the Emitted Emissions menu, but it produces the following error: "cannot insert into view 'esg_carbon_emission_report' DETAIL: Views containing UNION, INTERSECT, or EXCEPT are not automatically updatable." => To fix this, we will only allow the insertion of manual emissions (model: other.emission) via import, not emissions related to journal entries. task-6168587 Forward-Port-Of: odoo/enterprise#116092 Forward-Port-Of: odoo/enterprise#115306
This update fixes an issue where the emission factor date range wasn't displayed accurately. The missing 'always_range' option was the root cause, now resolved to ensure correct date validation and display. This improves the reliability of ESG reporting data.
Original PR description
Before this commit, the validity period was not correctly displayed because the always_range option was missing no related task Forward-Port-Of: odoo/enterprise#115832 Forward-Port-Of: odoo/enterprise#114784
This update fixes an issue where a horizontal scrollbar obscured the bottom border of the code view when content overflowed. The change repositioned the scrollbar to ensure the border remains visible, improving the overall visual consistency and user experience of the code editor. This ensures a cleaner and more professional look for code snippets.
Original PR description
Problem: When the code view contains content that overflows horizontally, the horizontal scrollbar hides the bottom border of the code view. Solution: Move the scrollbar inside the code view so the bottom border remains visible. Before: <img width="716" height="76" alt="image" src="https://github.com/user-attachments/assets/05b16d8e-4014-488f-84d6-f4e4c0dcae23" /> After: <img width="707" height="108" alt="image" src="https://github.com/user-attachments/assets/7151e3e0-254c-4e7c-bcda-bea2d7ab2cea" /> Steps to reproduce: - Add content in the code view that overflows horizontally. - Observe that the scrollbar hides the bottom border. task-6124267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261554
24 changes
Enhancements to existing features
This update splits a key accounting account to better align with French tax regulations (ANC PCG 2026). Specifically, it separates social security charges from salaries within the Profit and Loss report, ensuring accurate financial reporting. The original account remains but is marked as deprecated.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784 Forward-Port-Of: odoo/odoo#260262 Forward-Port-Of: odoo/odoo#255038
Resolved issues and error corrections
This update resolves an issue where the payroll system incorrectly flagged users as unauthorized document owners in multi-company environments. The fix replaces a problematic field lookup with a stored employee flag, ensuring accurate document ownership validation during background processes like payroll generation. This prevents errors and ensures proper system functionality across all companies.
Original PR description
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for…
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for this employee. 4) Run the 'Payroll: Generate pdfs' cron. Error - ValidationError: The following user(s) cannot own root documents/folders: portal_employee: Payslip - portal_employee Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company). When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner. Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies. opw-6143042 Co-authored by Tina Lin (liti) Forward-Port-Of: odoo/enterprise#115570
This update optimizes the HTML editor's performance by minimizing unnecessary style recalculations during updates. Previously, the system repeatedly checked element styles, leading to slower performance. This change extracts style measurements outside the update loop, resulting in a faster and more responsive user experience.
Original PR description
Description of the issue this PR addresses: Before this PR, updateHooks retrieved the computed style for each visible element and accessed marginTop and marginBottom inside the loop. Accessing properties of CSSStyleDeclaration may trigger style resolution, causing repeated 'Recalculate Style' work during hook updates. This PR extracts marginTop and marginBottom after getComputedStyle outside the loop, which reduces style reads during hook updates and avoids unnecessary style recalculations. task-6063534 closes odoo/odoo#252385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259341
This update resolves a critical error in the l10n_ar_edi module related to a missing dependency on the currency_rate_live module. The fix ensures the module functions correctly after an upgrade, preventing a system error. This ensures proper functionality for Arabic-based financial reporting.
Original PR description
Backport of https://github.com/odoo/enterprise/commit/ddec80d136063a24e4ddd4062d4d3591c861455d The module [adds](https://github.com/odoo/enterprise/blob/saas-19.2/l10n_ar_edi/models/res_company.py#L66-L69) selection values to field `res_company.currency_provider`, a field [defined](https://github.com/odoo/enterprise/blob/a0038c1aeaf9c0304afdfc220bcb7c0a309fac34/currency_rate_live/models/res_config_settings.py#L194-L200) in module `currency_rate_live`, but althouth it is auto-install, it's not a direct dependency, which can trigger errors. To reproduce: - Install `l10n_ar_edi` in 19 - Uninstall `currency_rate_live` - Upgrade to a saas~19.2 It will break with ``` AssertionError: Field res.company.currency_provider without selection ``` I had made the fix in master to avoid changing dependencies in stable, but the dependency is implicitly already there.
This update fixes an issue where the VAT label on invoices displayed in PDF format was incorrectly set to the user's preferred language instead of the company's language. Now, invoices will always display the VAT label in the correct language based on the company's settings, ensuring accurate and consistent invoicing for international clients. This resolves a discrepancy in language display for VAT labels.
Original PR description
When having for example a polish company but setting the language as an user to another one for example chinese, vat label on the top of the invoice pdf would be written in your user preference language so in this case chinese where it should be written in companies language so here in polish opw-6067250
A test related to rental stock management was failing due to demo data. The fix prevents the creation of duplicate 'out of stock' ribbons, which were being triggered by the test's attempt to create a second ribbon with the same configuration. This ensures the test runs successfully and accurately reflects the system's behavior.
Original PR description
Currently, running test `test_out_of_stock_ribbon_is_not_applicable_for_rentals` with demo data enabled leads to a validation error: `Only one ribbon with the "assign when out of stock" option is allowed.` This happens because, with demo data loaded, an "out of stock" ribbon is already created via XML data. The test then attempts to create another ribbon with the same configuration, triggering the constraint and causing the failure. Related PR: https://github.com/odoo/enterprise/pull/112660 runbot-[242457](https://runbot.odoo.com/odoo/error/242457) --- Forward-Port-Of: odoo/enterprise#116162
This update corrects a problem in how payslips are calculated for the Hong Kong payroll module. The calculation relied on a default year, causing issues when tests were run in different environments. This ensures accurate payslip generation for all scenarios, particularly for January 2026 payslips.
Original PR description
ir56b._compute_period depends on year_of_employer_return, which is derived from submission_date (defaults to today). If tests are run in a different year (mocked time or different environment), the period won't cover the January 2026 payslip. Forward-Port-Of: odoo/enterprise#116172
This update resolves an issue where users would lose focus when searching in the company switcher dropdown. The fix ensures the search input remains focused, providing a smoother and more reliable experience for selecting companies. It prevents interruptions during typing and improves usability.
Original PR description
If a user leaves their mouse resting over a company in the dropdown and starts typing in the search bar, the search bar loses focus, interrupting their typing and removes focus from the search input. Update the `onSearch` method to: - Remove focus from the highlighted dropdown item. - Put focus immediately back into the search input. - Briefly disable mouse events on the menu (for 100ms). This prevents the system from registering a fake mouse hover while the list updates. Forward-Port-Of: odoo/odoo#259369
This update fixes an issue where a horizontal scrollbar obscured the bottom border of the code view when content overflowed. By repositioning the scrollbar, the code view now maintains its intended visual appearance, ensuring a consistent and professional user experience. This change improves the overall readability and usability of the code editor.
Original PR description
Problem: When the code view contains content that overflows horizontally, the horizontal scrollbar hides the bottom border of the code view. Solution: Move the scrollbar inside the code view so the bottom border remains visible. Before: <img width="716" height="76" alt="image" src="https://github.com/user-attachments/assets/05b16d8e-4014-488f-84d6-f4e4c0dcae23" /> After: <img width="707" height="108" alt="image" src="https://github.com/user-attachments/assets/7151e3e0-254c-4e7c-bcda-bea2d7ab2cea" /> Steps to reproduce: - Add content in the code view that overflows horizontally. - Observe that the scrollbar hides the bottom border. task-6124267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261554
A technical error preventing cash payments on POS terminals using Razorpay was resolved. The fix ensures the system correctly handles payment selections, preventing a 'null value' error that interrupted the transaction process. This improves the reliability of cash payments within the Odoo POS system.
Original PR description
Steps: - Open a POS configuration with the Razorpay payment method set to all payment modes. - Process an order and initiate a Razorpay transaction. - Select a cash payment option on the terminal. Issue: - A traceback occurs with the error: `Cannot read properties of null (reading 'replace')`. Cause: - The code attempts to call the replace method on a null value. Fix: - Ensure the replace method is called only when the value is a valid string. Task-6190355 Forward-Port-Of: odoo/odoo#261922
This update optimizes the way the spreadsheet component interacts with field selections, reducing unnecessary processing. Previously, a repeated process caused performance slowdowns. This change improves the responsiveness and efficiency of spreadsheet views, leading to a smoother user experience.
Original PR description
Currently, the component `ModelFieldSelector` will call the field service on `willUpdateProps` regardless of its current state. Since the introduction of the persistent cache, there is a slight overhead when calling the fieldService (notably caused by the call to deepCopy) and this call can now become costy when called repeatedly, which occurs in the spreadsheet component for instance. Task-6185388 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#262497
A minor correction was made to the French financial reports (pnl) to ensure accurate reporting. Specifically, a typo was fixed where 'exceptionnel' was incorrectly using masculine language when it should be feminine, aligning with French accounting standards. This ensures consistent and compliant reporting for our French clients.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges. Forward-Port-Of: odoo/enterprise#116198
This update resolves a technical problem that prevented the `l10n_tr_nilvera_edispatch` module from installing correctly when certain automatic installations were skipped. By updating the module's dependencies to include `stock_account`, the system now ensures this critical module is properly set up, avoiding installation errors.
Original PR description
Issue: currently, the module `l10n_tr_nilvera_edispatch` depends on `l10n_tr_nilvera_einvoice` and `stock`. and in `l10n_tr_nilvera_einvoice` , it eventually gets `account` in its dependencies [from dependency chain]. So `stock` and `account` both are installed, and ideally `stock_account` is also installed since it is set to `auto_install: True`. but if we try to install edispatch module with `--skip-auto-install` the module installation fails, because we skip auto install modules and `stock_account` is not installed, due to this, `country_code` field defined in `stock_account` module and used in `l10n_tr_nilvera_edispatch` module is not found which causes error. Solution: This PR fixes this issue by updating dependency from `stock` to `stock_account` to make sure it is installed in all conditions. Related runbot error: https://runbot.odoo.com/odoo/runbot.build.error/238909 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where error messages from the Aspone API were not being displayed correctly. The change ensures that error messages are now presented to the user, improving the reliability and usability of the French reporting module. This prevents potential data discrepancies and provides clearer feedback to users.
Original PR description
Since the v2 rest api of aspone was implemented, error messages were no more well handled and a traceback was raised while getting one. This commit displays the write errr to the user task-5955980
A bug in the testing process was causing tests to fail when demo data was loaded. This was due to a duplicate IoT Box record created both in the tests and within the demo data. This fix resolves the conflict, ensuring tests run correctly and reliably.
Original PR description
We define an IoT Box record in tests with name "Shop". Another IoT Box with this name is defined in the demo data of the module. As a result, when tests are started with demo data loaded, we tend to click on the first IoT Box record with whis name, which correspond to the one from demo data. Some tests are then failing as they can't find device record defined in the test setup. related: odoo/enterprise#96760 Forward-Port-Of: odoo/enterprise#116234
This update fixes an issue where stock synchronization with Amazon was failing due to incorrect fulfillment channel data. The team switched to a new API field that accurately reflects available quantities across fulfillment channels, defaulting to FBM when necessary to ensure continued synchronization. A related update also improves how user-specific configurations are handled.
Original PR description
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not…
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359 Forward-Port-Of: odoo/enterprise#115899 Forward-Port-Of: odoo/enterprise#114473
This update clarifies French accounting reports by splitting a key account (649) into two new accounts (6491 and 6492). This change accurately separates social security charges from salaries, aligning with French accounting standards. The original account remains for legacy systems but is marked as deprecated.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784 Forward-Port-Of: odoo/enterprise#114412 Forward-Port-Of: odoo/enterprise#111420
This update corrects a technical error in how Odoo's Discuss feature sorts partners based on email addresses. The fix ensures that partners with matching email prefixes are correctly prioritized, leading to more accurate search results and improved user experience. This resolves a previously undetected issue.
Original PR description
In Discuss, the function used to sort partners prioritizes those whose email addresses start with the search terms. However, due to an error in the programming of the corresponding condition, this check could never be true. This commit adjusts the condition so that it behaves as expected. Forward-Port-Of: odoo/odoo#262583
This update resolves a visual bug where text highlights in the website editor were appearing in front of the text on Firefox. The fix adjusts how SVG highlights are added to the HTML to ensure they are rendered correctly behind the text, improving the user experience.
Original PR description
# How to reproduce - Go to the website editor - Select some text that wraps - Add text highlight to that text # The problem On firefox, for every line of text that wraps, the highlight is displayed in front of the text instead of behind. # Why The highlights are made of SVG's that are added to the html element of the selected text. To be sure that theses SVG's are displayed behind the text, they have position: absolute and z-index: -1. Sadly, z-index and absolute positionning in an inline context (like in a span) is a browser specific behavior and in the case of firefox, seems to sometimes be ignored. Since the SVG's are appended in the html element after the text, they are rendered after. This fix aims to insert the SVG's in the html element before the text to make sure the rendering order is correct opw-5976647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254196
This update fixes an issue where users could inadvertently select customers from different companies within the Helpdesk module. The fix involved adding a restriction to the customer selection process, ensuring users only see customers within their assigned company. This improves data accuracy and prevents potential errors in ticket management.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#116157 Forward-Port-Of: odoo/enterprise#111909
This update fixes an issue where the emission factor date range wasn't accurately shown. The missing 'always_range' option was corrected, ensuring that users now see the correct validity periods for emission factors. This improves data accuracy and reliability within the ESG reporting features.
Original PR description
Before this commit, the validity period was not correctly displayed because the always_range option was missing no related task Forward-Port-Of: odoo/enterprise#115832 Forward-Port-Of: odoo/enterprise#114784
This update resolves a bug that prevented correct balance calculations during multi-currency bank reconciliation edits. Specifically, changing the currency of a bank statement move line and then making further edits would reset the balance to zero. This fix ensures accurate balance tracking for financial reporting.
Original PR description
Fixed an issue where when editing a move line for the bank reconciliation and setting the currency to a currency other than the company's currency if we edit the move line again we will find that the balance is equal to 0. task-6037835 Forward-Port-Of: odoo/enterprise#114898
This update resolves an issue preventing the successful installation of the `sale_stock` and `purchase_stock` modules when existing sale or purchase orders included non-stock items like downpayments. The fix filters out these problematic lines during the installation process, preventing a critical error and ensuring smooth module installation.
Original PR description
## Summary When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:…
## Summary
When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:
ValueError: Expected singleton: uom.uom()
## Root Cause
The `post_init_hook` (`_create_pickings_for_open_sale_orders` / `_create_pickings_for_open_purchase_orders`) filters order lines to create pickings:
```python
empty_lines = open_sale_orders.order_line.filtered(
lambda l: l.product_uom_id.is_zero(l.qty_delivered)
)
```
This accesses product_uom_id without checking if it exists. Lines with:
- display_type set (sections, notes)
- is_downpayment = True (downpayments)
...don't have a product_id or product_uom_id, causing the error.
Fix
Add filters to skip non-stock lines before accessing product_uom_id:
```
empty_lines = open_sale_orders.order_line.filtered(
lambda l: not l.display_type and not l.is_downpayment and l.product_uom_id.is_zero(l.qty_delivered)
)
```
Steps to Reproduce
1. Create a fresh database (without sale_stock/purchase_stock)
2. Create a sale order with a downpayment line or section/note
3. Install sale_stock module
4. Error: ValueError: Expected singleton: uom.uom()
Reproduction Reference
- purchase_stock issue: https://drive.google.com/file/d/1aKw-ago-pMds_-x_y9f8nJZyZsLqGJ67/view?usp=sharing
- sale_stock issue: https://drive.google.com/file/d/1I9fY8UZZZ3ULcairl3YGZTi_KttsYLNR/view?usp=sharing
opw-6179073
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262439This update resolves a rounding error issue that occurred when importing purchase orders processed through OCR. The fix restores the original rounding precision, aligning with the intended functionality for EDI imports rather than the OCR process. This ensures accurate financial data import.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387) Forward-Port-Of: odoo/enterprise#116141 Forward-Port-Of: odoo/enterprise#116021
23 changes
New functionality added to Odoo
This update prepares Odoo for a new Belgian tax regulation. Starting May 1st, businesses will need to use a dedicated 'Tax Provision Account' (411800) instead of their existing accounts for VAT periodic returns. This change ensures compliance with updated Belgian accounting standards.
Original PR description
Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new account 'Tax Provision Account' 411800 Enterprise PR: odoo/enterprise#111599 Task [link](https://www.odoo.com/odoo/project.task/6044017) task-6044017 Forward-Port-Of: odoo/odoo#262715 Forward-Port-Of: odoo/odoo#255272
This update prepares Odoo for the new Belgian VAT reporting requirements, effective May 1st. It adds a dedicated 'Tax Provision Account' (411800) to ensure accurate reporting of VAT provisions, aligning with current regulations. This change simplifies VAT reporting for Belgian businesses using Odoo.
Original PR description
Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new account 'Tax Provision Account' 411800 Community PR: odoo/odoo#255272 Task [link](https://www.odoo.com/odoo/project.task/6044017) task-6044017 Forward-Port-Of: odoo/enterprise#116182 Forward-Port-Of: odoo/enterprise#111599
Resolved issues and error corrections
This update optimizes how the HTML editor recalculates styles during updates, leading to a smoother and faster user experience. By reducing unnecessary style calculations, the system now responds more quickly to changes, improving overall performance. This change addresses a technical issue that was causing delays in the HTML editor's responsiveness.
Original PR description
Description of the issue this PR addresses: Before this PR, updateHooks retrieved the computed style for each visible element and accessed marginTop and marginBottom inside the loop. Accessing properties of CSSStyleDeclaration may trigger style resolution, causing repeated 'Recalculate Style' work during hook updates. This PR extracts marginTop and marginBottom after getComputedStyle outside the loop, which reduces style reads during hook updates and avoids unnecessary style recalculations. task-6063534 closes odoo/odoo#252385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259341
This update fixes a bug where unallocated earnings weren't appearing in the general ledger CSV export. The change adds a 'Currency' column to the export and updates the report generation process to ensure all earnings are included, providing a more complete financial overview. This improves the accuracy of financial reporting.
Original PR description
1) The unallocated earning lines were missing from the general ledger csv export, as they are added in post-processing. The fix is to call `_get_lines` instead of the report custom engine directly. 2) Also adding the "Currency" column to the csv export. Forward-Port-Of: odoo/enterprise#115987
A test related to rental stock management was failing due to a duplicate configuration within the demo data. This update ensures the test runs correctly by preventing the creation of redundant 'out of stock' ribbons. This resolves a technical issue that could have impacted test results.
Original PR description
Currently, running test `test_out_of_stock_ribbon_is_not_applicable_for_rentals` with demo data enabled leads to a validation error: `Only one ribbon with the "assign when out of stock" option is allowed.` This happens because, with demo data loaded, an "out of stock" ribbon is already created via XML data. The test then attempts to create another ribbon with the same configuration, triggering the constraint and causing the failure. Related PR: https://github.com/odoo/enterprise/pull/112660 runbot-[242457](https://runbot.odoo.com/odoo/error/242457) --- Forward-Port-Of: odoo/enterprise#116162
This update resolves an issue where users would lose focus while searching for companies in the dropdown menu. The fix ensures the search input remains focused, providing a smoother and more reliable experience when typing. This prevents interruptions and improves usability.
Original PR description
If a user leaves their mouse resting over a company in the dropdown and starts typing in the search bar, the search bar loses focus, interrupting their typing and removes focus from the search input. Update the `onSearch` method to: - Remove focus from the highlighted dropdown item. - Put focus immediately back into the search input. - Briefly disable mouse events on the menu (for 100ms). This prevents the system from registering a fake mouse hover while the list updates. Forward-Port-Of: odoo/odoo#259369
This update corrects a bug where attachments weren't uploading correctly when navigating between records in the chatter. The fix ensures attachments are properly associated with the intended record, preventing data inconsistencies and improving the reliability of attaching files.
Original PR description
Currently, when uploading a bunch of attachments or a big one to the chatter, if you click on the pager (e.g. next) before the upload is complete, the attachments that have not yet been uploaded are uploaded to the next record. Due to the persistence of the Chatter component during record navigation and the fact that the `FileUploader` logic is tied to `state.thread`, an async callback that finishes after a record switch will attempt to update the currently active thread rather than the one that initiated the upload. With this change we tie uploader lifecycle to a specific record and ensure the completion callback only affects that record. task-5119290 Forward-Port-Of: odoo/odoo#262714 Forward-Port-Of: odoo/odoo#261552
This update fixes an issue where a horizontal scrollbar obscured the bottom border of the code view when content overflowed. The change repositioned the scrollbar to ensure the border remains visible, improving the overall visual consistency and user experience of the code editor.
Original PR description
Problem: When the code view contains content that overflows horizontally, the horizontal scrollbar hides the bottom border of the code view. Solution: Move the scrollbar inside the code view so the bottom border remains visible. Before: <img width="716" height="76" alt="image" src="https://github.com/user-attachments/assets/05b16d8e-4014-488f-84d6-f4e4c0dcae23" /> After: <img width="707" height="108" alt="image" src="https://github.com/user-attachments/assets/7151e3e0-254c-4e7c-bcda-bea2d7ab2cea" /> Steps to reproduce: - Add content in the code view that overflows horizontally. - Observe that the scrollbar hides the bottom border. task-6124267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261554
A technical error preventing cash payments on POS terminals using Razorpay was resolved. The fix ensures the system correctly handles payment selections, preventing a crash and improving the reliability of the POS payment process. This update ensures smooth transactions for our retail partners.
Original PR description
Steps: - Open a POS configuration with the Razorpay payment method set to all payment modes. - Process an order and initiate a Razorpay transaction. - Select a cash payment option on the terminal. Issue: - A traceback occurs with the error: `Cannot read properties of null (reading 'replace')`. Cause: - The code attempts to call the replace method on a null value. Fix: - Ensure the replace method is called only when the value is a valid string. Task-6190355 Forward-Port-Of: odoo/odoo#261922
This update optimizes the way the spreadsheet component interacts with field selections, reducing unnecessary processing steps. Previously, the system was repeatedly calling a costly function, leading to performance slowdowns. This change ensures a smoother and faster experience when using the spreadsheet feature.
Original PR description
Currently, the component `ModelFieldSelector` will call the field service on `willUpdateProps` regardless of its current state. Since the introduction of the persistent cache, there is a slight overhead when calling the fieldService (notably caused by the call to deepCopy) and this call can now become costy when called repeatedly, which occurs in the spreadsheet component for instance. Task-6185388 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#262497
A minor typographical error in the French Profit & Loss report (P&L) has been fixed. Specifically, the term 'exceptionnel' was incorrectly using masculine form when it should be feminine to accurately reflect charges. This ensures correct reporting for French accounting standards.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges. Forward-Port-Of: odoo/enterprise#116198
This update resolves a duplication issue in the Profit and Loss report for French accounting (l10n_fr_reports). The fix removes a mistakenly included account, ensuring accurate financial reporting. This improves the reliability of financial data for French-speaking customers.
Original PR description
This commit is an addon to this commit[[1]] where we tried to avoid duplicate accounts in the Profit And Loss report. The problem is that we don't exclude the separated account 6492 from the original one (649). This commit adds the removal of this account in the report formula. task-6053784 Here is the coverage: [Profit and loss account (FR) - Accounts Coverage Report (2).xlsx](https://github.com/user-attachments/files/27011824/Profit.and.loss.account.FR.-.Accounts.Coverage.Report.2.xlsx) The correct separation: <img width="837" height="485" alt="image" src="https://github.com/user-attachments/assets/ebe98976-f689-4389-866a-c9a0c8b50534" /> [1]: https://github.com/odoo/enterprise/commit/4587c49c4b220305652150d2f21a95fb7cfa188d Forward-Port-Of: odoo/enterprise#115060 Forward-Port-Of: odoo/enterprise#114858
This update resolves an issue where Amazon's fulfillment channel data caused stock synchronization problems. The system now uses a more reliable field from the Listings API to determine channel availability, defaulting to FBM when necessary. This ensures accurate stock updates and avoids disruptions in Amazon sales.
Original PR description
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not…
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359 Forward-Port-Of: odoo/enterprise#115899 Forward-Port-Of: odoo/enterprise#114473
This update corrects a technical issue in the Discuss module that prevented proper sorting of partners based on email prefixes. The fix ensures that partners with matching email addresses are prioritized correctly, improving the functionality of the Discuss feature. This resolves a bug impacting partner organization.
Original PR description
In Discuss, the function used to sort partners prioritizes those whose email addresses start with the search terms. However, due to an error in the programming of the corresponding condition, this check could never be true. This commit adjusts the condition so that it behaves as expected. Forward-Port-Of: odoo/odoo#262583
This update resolves a visual bug where text highlights in the website editor were incorrectly displayed in front of the text on Firefox. The fix adjusts how SVG highlights are added to the HTML, ensuring they render behind the text as intended. This improves the overall user experience for website editing.
Original PR description
# How to reproduce - Go to the website editor - Select some text that wraps - Add text highlight to that text # The problem On firefox, for every line of text that wraps, the highlight is displayed in front of the text instead of behind. # Why The highlights are made of SVG's that are added to the html element of the selected text. To be sure that theses SVG's are displayed behind the text, they have position: absolute and z-index: -1. Sadly, z-index and absolute positionning in an inline context (like in a span) is a browser specific behavior and in the case of firefox, seems to sometimes be ignored. Since the SVG's are appended in the html element after the text, they are rendered after. This fix aims to insert the SVG's in the html element before the text to make sure the rendering order is correct opw-5976647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254196
This update resolves an issue where the last column of accounting reports was partially cut off when scrolling. The fix adds bottom padding to the reports, ensuring all data is fully visible and accessible. This improves the clarity and usability of financial reports.
Original PR description
Before this commit, there was no bottom padding in the accounting reports, which caused the last column’s values to appear partially cut off when scrolling to the bottom. This issue started occurring after the PR: https://github.com/odoo/enterprise/pull/99198 opw-6130981 **Before fix (runbot)** <img width="1920" height="1005" alt="image" src="https://github.com/user-attachments/assets/808bbb2b-3b4e-4b5c-a872-b8bd7bf589ba" /> **After fix:** <img width="1917" height="1006" alt="image" src="https://github.com/user-attachments/assets/55f04e1f-0469-46e1-af69-f5055a7232d9" /> Forward-Port-Of: odoo/enterprise#116168
This update fixes an issue where users could accidentally select customers from different companies within the Helpdesk module. The fix involved adding a restriction to the customer selection process, ensuring users only see customers within their assigned company. This improves data accuracy and prevents misdirected support requests.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#116157 Forward-Port-Of: odoo/enterprise#111909
This update fixes an issue where the emission factor date range wasn't showing correctly. The missing 'always_range' option was the root cause, preventing accurate display of valid dates. This ensures users see the correct period for emission factor calculations.
Original PR description
Before this commit, the validity period was not correctly displayed because the always_range option was missing no related task Forward-Port-Of: odoo/enterprise#115832 Forward-Port-Of: odoo/enterprise#114784
This update resolves a bug that prevented accurate balance calculations during multi-currency bank reconciliation edits. Specifically, changing the currency of a bank statement move line and then re-editing it would reset the balance to zero. This ensures correct balance tracking for financial reporting.
Original PR description
Fixed an issue where when editing a move line for the bank reconciliation and setting the currency to a currency other than the company's currency if we edit the move line again we will find that the balance is equal to 0. task-6037835 Forward-Port-Of: odoo/enterprise#114898
This update resolves an issue where referenced refunds in Viva.com were incorrectly reversing payments. The problem stemmed from a previous update removing a necessary session ID. This fix restores the session ID, allowing refunds to function as intended and ensuring accurate payment reversals. A new test tour has also been added to verify the full refund process.
Original PR description
Referenced refunds in Viva.com require the session ID of the original payment to be sent, resulting in that payment being reversed. Unfortunately this functionality was broken when a forward-port PR (odoo/odoo#236004) mistakenly removed the `parentSessionId` field from the request. This commit restores the `parentSessionId` field, fixing the issue. It also adds a tour to test the full payment and referenced refund flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262788 Forward-Port-Of: odoo/odoo#262475
This change corrects a visual issue in the online shopping cart where a product offering free shipping (a reward) incorrectly displayed a border. The fix removes this border, improving the user experience and ensuring the cart looks clean and professional. This was a minor cosmetic issue addressed to maintain a consistent and polished presentation.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Enable `Discounts, Loyalty & Gift Cards` from settings. - Go to `Website > eCommerce > Loyalty > Discount & Loyalty`. - Create a new program…
Steps to produce: --- - Install `website_sale` module. - Enable `Discounts, Loyalty & Gift Cards` from settings. - Go to `Website > eCommerce > Loyalty > Discount & Loyalty`. - Create a new program and edit the reward to set the reward type to `Free Shipping`. - Create a new product, set its price to 1000, and publish it. - Open the product on the website and add it to the cart > open the cart. Issue: --- - The quantity field for the unsellable product (Free Shipping reward) displays a border in the cart. Root cause: --- - The form-control class is applied to the quantity field at [1]. - This class includes a default border style defined in Bootstrap at [2]. Solution: --- - Apply the Bootstrap utility class `border-0` to remove the border from the quantity field for unsellable products. [1]https://github.com/odoo/odoo/blob/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab/addons/website_sale/views/templates.xml#L2901 [2]https://github.com/odoo/odoo/blob/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab/addons/web/static/lib/bootstrap/scss/forms/_form-control.scss#L5-L31 Before: --- <img width="822" height="135" alt="image" src="https://github.com/user-attachments/assets/d66c0445-5fd4-45c5-ae81-b4270cab6378" /> After: --- <img width="827" height="132" alt="image" src="https://github.com/user-attachments/assets/9cc2bd65-c542-4d1f-89de-2212fa968c8e" /> opw-6153161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261275
This update corrects a technical issue that caused a traceback when users removed the Unit of Measure (UOM) from a sales order line. The fix prevents unnecessary calculations related to discounts, ensuring the system functions smoothly when a UOM is not initially set. This improves overall sales order processing reliability.
Original PR description
Issue: --- Due to this issue, there is a TB when you try to remove uom. Steps to reproduce: 1- Create a SO and add a line. 2- On SOL, remove uom. You get a traceback. This is because of `ensure_one` here: https://github.com/odoo/odoo/blob/saas-18.4/addons/product/models/product_pricelist_item.py#L588 We can prevent the discount compute on the line which is causing the `compute_price`, when uom is not set. opw-6144426 Forward-Port-Of: odoo/odoo#262266
This update corrects a rounding error that occurred when importing purchase orders processed through OCR. The fix restores the standard rounding precision, which was originally designed for EDI, rather than the OCR process. This ensures accurate invoice calculations and prevents discrepancies.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387) Forward-Port-Of: odoo/enterprise#116141 Forward-Port-Of: odoo/enterprise#116021
4 changes
Resolved issues and error corrections
This update ensures that Quality Checks and Mass Produce options remain visible on the Shop Floor, regardless of whether production is automatically closed. Previously, disabling auto-close production hid these critical features, preventing users from completing quality checks and generating serial numbers. This change improves workflow efficiency and data accuracy.
Original PR description
### *Why this commit*: --- Ensures Quality Checks and Mass Produce options remain available on the Shop Floor regardless of the "Auto-close Production" setting. ### *Steps to Reproduce* --- 1. Define…
### *Why this commit*: --- Ensures Quality Checks and Mass Produce options remain available on the Shop Floor regardless of the "Auto-close Production" setting. ### *Steps to Reproduce* --- 1. Define a product tracked by Serial Numbers with a Manufacturing BoM. 2. Create a Quality Control Point for the product on the Manufacturing operation. 3. In Inventory Configuration, disable "Auto-close Production" on the Manufacturing operation type. 4. Create a Manufacturing Order (MO) and open it in the Shop Floor view. 5. If the MO has no operations, try to use Mass Produce. ### *Before this PR* --- When auto_close_production was set to False, the Shop Floor card footer incorrectly hid both the Quality Checks and Mass Produce buttons. This blocked users from registering Serial Numbers and completing mandatory quality check steps. Additionally, for products without BoM operations, clicking Mass Produce triggered quality check validation instead leading to errors, preventing the generation of serial numbers. ### *After this PR* --- The visibility logic for Shop Floor actions is now decoupled from the closing permission. The workflow follows this corrected sequence: Mass Produce: Stays visible to allow serial registration and backorder creation even if the MO cannot be closed from the Shop Floor. Quality Checks: Remain accessible to ensure all mandatory tests are passed before production progresses. Close Production: Only appears if "Auto-close Production" is enabled on the operation type. OPW: 5473839 Forward-Port-Of: odoo/enterprise#103926
A minor correction was made to the French financial reports (pnl) to ensure accurate reporting. Specifically, a typo was fixed where 'exceptionnel' was incorrectly using masculine language when referring to charges. This ensures compliance with French accounting standards.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges. Forward-Port-Of: odoo/enterprise#116198
This update resolves a duplication issue in the Profit and Loss report for French accounting (l10n_fr_reports). The fix removes a mistakenly included account, ensuring accurate financial reporting. This improves the reliability of key financial data for French-speaking customers.
Original PR description
This commit is an addon to this commit[[1]] where we tried to avoid duplicate accounts in the Profit And Loss report. The problem is that we don't exclude the separated account 6492 from the original one (649). This commit adds the removal of this account in the report formula. task-6053784 Here is the coverage: [Profit and loss account (FR) - Accounts Coverage Report (2).xlsx](https://github.com/user-attachments/files/27011824/Profit.and.loss.account.FR.-.Accounts.Coverage.Report.2.xlsx) The correct separation: <img width="837" height="485" alt="image" src="https://github.com/user-attachments/assets/ebe98976-f689-4389-866a-c9a0c8b50534" /> [1]: https://github.com/odoo/enterprise/commit/4587c49c4b220305652150d2f21a95fb7cfa188d Forward-Port-Of: odoo/enterprise#115060 Forward-Port-Of: odoo/enterprise#114858
This update resolves a bug that prevented accurate bank reconciliation balances when changing currencies for a transaction. Specifically, editing a bank statement line after switching currencies would reset the balance to zero. This ensures correct balance calculations during bank reconciliation processes.
Original PR description
Fixed an issue where when editing a move line for the bank reconciliation and setting the currency to a currency other than the company's currency if we edit the move line again we will find that the balance is equal to 0. task-6037835 Forward-Port-Of: odoo/enterprise#114898
8 changes
New functionality added to Odoo
This update prepares Odoo for a change in Belgian tax regulations. Starting May 1st, businesses will need to use a new 'Tax Provision Account' (411800) for VAT periodic returns, replacing the previous account. This ensures compliance with updated Belgian accounting standards.
Original PR description
[IMP] l10n_be_reports: Add new VAT provision account Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new 'Tax Provision Account' 411800 task-6044017
This update prepares Odoo for a change in Belgian VAT regulations. Starting May 1st, businesses will need to use a new 'Tax Provision Account' (411800) instead of the previous account for periodic VAT returns. This ensures compliance with updated reporting requirements.
Original PR description
[IMP] l10n_be_reports: Add new VAT provision account Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new 'Tax Provision Account' 411800 task-6044017
Resolved issues and error corrections
This update resolves a bug that prevented the balance from being displayed correctly when reconciling foreign currency invoices. Specifically, a problem with how the system handled multiple currency selections was corrected, ensuring accurate balance calculations and visibility across different reconciliation scenarios. This improves the user experience when working with multi-currency transactions.
Original PR description
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction…
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected ### Cause: In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it There is no reason to block the sum of lines with the same currency When there is no selectedLines, the function returns early and doesn't unhide the balance ### Steps to reproduce: - Install `account_accountant` with demo data - Enable a foreign currency like EUR - Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€) - Go to the Dashboard, and select Bank - Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$) - Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency` - Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$) - Switch to the Kanban View and Reconcile the line Multi-currencies - Select your 2 invoices one by one Before the fix, after selecting the second invoice, the balance is displayed as `/` For the additional case: - Unselect all lines - Select a line in another currency (e.g., USD), then unselect it The balance remains hidden opw-6063366
This update fixes an issue where the HTML editor's undo function sometimes restored the selection to the wrong position. The fix ensures the selection is properly 'staged' before deletion, guaranteeing accurate restoration during undo operations. This improves the user experience and prevents data inconsistencies.
Original PR description
Problem: In some cases, undo restores the selection to an incorrect position. Cause: The selection state was not staged before the deletion started, leading to an inconsistent selection being restored during undo. Solution: Stage the selection before performing the deletion to ensure it can be restored to the correct position. Steps to reproduce: - Go to To-Do → Create New. - Type something on the first line and press Enter. - Type something on the second line and apply styling to it. - Use the Up arrow key to move to the first line. - Remove a character. - Press Undo (Ctrl + Z). - Observe that the selection and toolbar appear on the second line. task-6142055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260630
This update resolves a technical error that prevented users from selecting cash payments on POS terminals when using Razorpay. The fix ensures the system correctly handles payment selections, improving the reliability of the POS payment process. This change enhances the overall user experience for cash transactions.
Original PR description
Steps: - Open a POS configuration with the Razorpay payment method set to all payment modes. - Process an order and initiate a Razorpay transaction. - Select a cash payment option on the terminal. Issue: - A traceback occurs with the error: `Cannot read properties of null (reading 'replace')`. Cause: - The code attempts to call the replace method on a null value. Fix: - Ensure the replace method is called only when the value is a valid string. Task-6190355 Forward-Port-Of: odoo/odoo#261922
This update fixes a minor error in the French version of the Profit and Loss report. The term "exceptionnel" was incorrectly using masculine form when it should be feminine to accurately reflect charges. This ensures correct reporting and compliance with French accounting standards.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges. Forward-Port-Of: odoo/enterprise#116198
This update resolves a duplication issue in the French Profit and Loss report by removing a mistakenly included account. The fix ensures accurate financial reporting for French businesses using Odoo Enterprise. This improves the reliability of financial data and aligns with accounting standards.
Original PR description
This commit is an addon to this commit[[1]] where we tried to avoid duplicate accounts in the Profit And Loss report. The problem is that we don't exclude the separated account 6492 from the original one (649). This commit adds the removal of this account in the report formula. task-6053784 Here is the coverage: [Profit and loss account (FR) - Accounts Coverage Report (2).xlsx](https://github.com/user-attachments/files/27011824/Profit.and.loss.account.FR.-.Accounts.Coverage.Report.2.xlsx) The correct separation: <img width="837" height="485" alt="image" src="https://github.com/user-attachments/assets/ebe98976-f689-4389-866a-c9a0c8b50534" /> [1]: https://github.com/odoo/enterprise/commit/4587c49c4b220305652150d2f21a95fb7cfa188d Forward-Port-Of: odoo/enterprise#115060 Forward-Port-Of: odoo/enterprise#114858
This update ensures that forced full packaging reservations are correctly applied, even when large quantities of a product are available. Previously, the system was incorrectly calculating reservations based on packaging multiples, leading to inaccurate stock levels. This fix now accurately reflects the intended behavior of reserving only full packaging units.
Original PR description
Issue ----- Forced full packaging reservation setting is ignored when there is a big quant in stock. Steps to reproduce ----- - Enable packagings - Create a product category "Super Category" -…
Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.
Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
- Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
- Product Category: Super Category
- 50 units on hand
- Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA
> Reservation is made for 15 units
Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing
https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925
This leads to the reservation quantity being min(15, 48) = 15
https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927
-----
Ticket:
opw-5974333
Forward-Port-Of: odoo/odoo#262312
Forward-Port-Of: odoo/odoo#2573421 change
Resolved issues and error corrections
This update resolves a bug that prevented users from modifying warehouse routes in the Romanian (RO) accounting version of Odoo. The issue stemmed from incorrect data handling during route updates, causing a system error. This fix ensures that warehouse routes can now be safely adjusted without disruption.
Original PR description
### Issue: When changing the routes of a Romanian warehouse, an error is raised, blocking any modification of multi-step routes ### Cause: The code attempts to access `in_type_id` from `warehouse_data` However, when updating routes, `warehouse_data` is empty in the method `_create_or_update_sequences_and_picking_types` This leads to a crash because the code assumes that `warehouse_data` always contains `in_type_id` and `out_type_id` Additionally, even if the data were present, it would result in creating duplicate `stock.picking.type` records ### Steps to reproduce: - Install `l10n_ro_saft_stock` with demo data and switch to `RO Company` - Enable `Multi-steps Routes` in Settings - Try to modify Incoming or Outgoing Shipments on a warehouse - When saving, the following error is raised: "Oh snap! in_type_id" odoo-pr: https://github.com/odoo/odoo/pull/257293 opw-5925087 Forward-Port-Of: odoo/enterprise#114166
4 changes
Enhancements to existing features
This update enhances the appearance of PDF Manager actions by removing an unnecessary styling class. Previously, action names had an awkward capitalization style. This change ensures a cleaner and more professional user experience when working with PDF documents within the Enterprise module.
Original PR description
Previously, pdf_manager actions used class "text-uppercase". Action names looked awkward. In this commit, we remove the class and properly display action names. task-6159317
Resolved issues and error corrections
This update resolves an issue where the payroll system incorrectly flagged users as unauthorized document owners in multi-company environments. The fix replaces a dependent field with a stored employee flag, ensuring accurate validation regardless of the company context. This prevents errors during payroll processing.
Original PR description
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for…
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for this employee. 4) Run the 'Payroll: Generate pdfs' cron. Error - ValidationError: The following user(s) cannot own root documents/folders: portal_employee: Payslip - portal_employee Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company). When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner. Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies. opw-6143042 Co-authored by Tina Lin (liti) Forward-Port-Of: odoo/enterprise#115570
This update resolves an issue in the Belgian payroll module where holiday attestation occupations were being calculated incorrectly. The fix replaces a direct field access with a more reliable method, ensuring accurate holiday entitlement calculations for employees. This improves payroll accuracy and compliance.
Original PR description
. use _get_hours_per_week() method instead of calling the field on the version task-6185339 Forward-Port-Of: odoo/enterprise#115990
This update simplifies the sales credit limit process by removing a confusing toggle in the contact form. The credit limit is now automatically applied through global settings, ensuring consistent enforcement regardless of the toggle's state. This streamlines the user experience and avoids unnecessary manual adjustments.
Original PR description
Steps to reproduce: 1- Install Accounting and Contacts 2- Enable "Sales Credit Limit" in the settings and set a default limit 3- Open any contact form and go to the accounting tab 4- You will find…
Steps to reproduce: 1- Install Accounting and Contacts 2- Enable "Sales Credit Limit" in the settings and set a default limit 3- Open any contact form and go to the accounting tab 4- You will find "Partner Limit" field with a toggle next to it 5- Enable the toggle, save and refresh Issue: The toggle shows as disabled again Why this happens: The Partner Limit field depends on the `use_partner_credit_limit` attribute to display/hide the credit limit. The expression evaluated to true if the partner's credit limit is not equal to the default credit limit. Hence, running the compute method with the default limit always resulted in a disabled toggle and the credit limit was hidden, indicating the limit check was disabled. Fix: The Sales Credit Limit is automatically applied to all partners via the global accounting settings, despite not showing as "enabled" in the contact form. The `Partner Limit` toggle is a redundant manual override that does not affect the actual enforcement of the limit when the global setting is enabled, so should be removed opw-6113301
3 changes
Resolved issues and error corrections
This update resolves a minor visual issue with account reports where the bottom of the report wasn't properly spaced when the report content exceeded the page width. This ensures consistent and professional-looking reports for users.
Original PR description
Since this commit https://github.com/odoo/enterprise/commit/690eff4af4af6ec1cc634c8c55dcc2f349a9b723, the styling at the bottom of the reports is slightly broken, as there is no space below the final line (when the report takes more than the full page) task-https://www.odoo.com/odoo/project/967/tasks/6191828
This update fixes an issue where selecting multiple lines in the bank reconciliation process didn't function correctly. The change ensures that the dropdown accurately displays the intersection of relevant record models, resolving a bug that occurred when only one or multiple lines were selected. This improves the user experience and functionality of this core feature.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/fa8fedc4e2501a273e7f8f3f7f4462b2b58907b9 We introduce a way for user to select multiple lines and perform an action out of it. In the dropdown, there should be an intersection of all reco model of the selected lines but it wasn't working properly in two cases: - When only one selected lines, remainingRecoModels was empty and the filter was filtering everything, added a early return for that - When multiple lines, we compare the first list of reco model with all the others but we compare object which is not working in js. Now we will compare the id. no task id
This update fixes a minor error in the French financial reports (l10n_fr_reports) module. Specifically, a typo was corrected in the section name for 'exceptionnel' to ensure proper feminine agreement when referring to charges. This ensures accurate reporting in accordance with French accounting standards.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges. Forward-Port-Of: odoo/enterprise#116198
4 changes
Resolved issues and error corrections
A test related to order settlement was failing due to an unreliable data field. This update replaces the failing field with a more robust calculation based on order quantity and picking status, ensuring the test now passes and the point-of-sale functionality remains stable.
Original PR description
Issue: ===== - The test was using the `qty_done` field on `stock.move.line`, which is not always available. Fix: ==== - Replace `qty_done` with a computation based on `quantity` and `picked` for the assertion. Task-6183114 Error-243452 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem that prevented UBL invoices from importing correctly in Odoo 18. Previously, the system didn't always ensure the unit of measure (UoM) used for an invoice line matched the product's default UoM, leading to import errors. This fix guarantees UoM compatibility, ensuring smooth and accurate UBL invoice imports.
Original PR description
When importing an account.move from an UBL file, we try to match the unitCode with a default UoM from the database: https://github.com/odoo/odoo/blob/c6f0ca15da7ded91062d0c395c9fabfdb1136531/addons/account_edi_ubl_cii/models/account_edi_ubl.py#L2913 In version 18, the UoM selected for a account.move.line needs to be from the same category as the product's default UoM. This is currently not verified to select the line's UoM, it will raise a UserError and interrupt the process. opw-6173558 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that prevented users from merging mailing lists, resulting in an error message. The fix ensures that the system correctly identifies record IDs during the merge process, preventing the 'Record does not exist' error. This improves the reliability of the mailing list management feature.
Original PR description
Currently, error occurs when user tries to merge a mailing list. Steps to replicate: - Install `mass_mailing`. - Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view. - Select…
Currently, error occurs when user tries to merge a mailing list.
Steps to replicate:
- Install `mass_mailing`.
- Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view.
- Select a single record, and from cog menu Click merge.
Warning:
```
odoo.http: Record does not exist or has been deleted.
(Record: mailing.list(6,), User: 2)
```
Cause:
- When the user clicks Merge, the `mailing.list.merge` form opens and `default_get()` is executed to populate defaults.
- At this point, `src_list_ids` is added to res in a structured format like `[(6, 0, ids)]` [1].
- Later, `res.get('src_list_ids')` is reused and assigned to `src_list_ids` [2].
- Taking `src_list_ids[0]` [3] returns `(6, 0, ids)`, and its first element `6` is incorrectly treated as a record ID and assigned to `dest_list_id`.
- This leads to an attempt to access a record with ID 6, which does not exist, causing the error.
Solution:
- Instead of reading `src_list_ids` back from `res` after it has been set, we initialize and reuse local variables (src_list_ids, active_ids) at the beginning of the method.
- This avoids relying on transformed values in `res` and ensures that `dest_list_id` is computed using a consistent and valid list record IDs.
[1]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L20-L22
[2]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L24
[3]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L26
sentry-7447326420
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262466This update fixes an issue where incorrect tax exemption data was being generated for UBL invoices, preventing compliance with Peppol standards. The change ensures accurate tax exemption information is included, resolving a potential validation error and improving the system's ability to process international invoices.
Original PR description
A tax exemption reason code that does not pass the peppol validation was added in the xml generation in this task-id-5905176 task-id-none Forward-Port-Of: odoo/odoo#262810