Monday, May 5, 2025
22 changes · 18.0
Resolved issues and error corrections
This fix corrects Spanish localization tax data so automated checks no longer fail due to an incorrect tax classification. It helps keep Spanish accounting configurations reliable, including cases affected by the Canary Islands chart of accounts split.
Original PR description
…l10n_es_type Probably forgotten to update the agriculture changes when splitting the csv file for the Canary Islands CoA. Runbot error 161596 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
Italian electronic invoices in foreign currencies now keep unit prices consistent with line totals in the generated XML. This prevents mismatches that could cause validation issues or confusion when sending documents to the Italian SDI system.
Original PR description
### Steps to reproduce: - Install "l10n_it" and switch to an Italian company - Change the currency exchange rate so USD and EUR are not equal - Create a vendor bill or invoice in USD, with at least one product and a price higher than 0 - Confirm, send and inspect the XML generated for the SDI - The value of PrezzoTotale is different than PrezzoUnitario*Quantita ### Cause: "prezzo_unitario" is rounded during the currency conversion. ([see](https://github.com/odoo/odoo/blob/9a48804ed07779692da2952476d3906d1abfa302/addons/l10n_it_edi/models/account_move.py#L330)) But "prezzo_totale" is never rounded, it is taken directly from the tax details ### Solution: When converting "prezzo_unitario" avoid the rounding by adding `round=False`. opw-4720375
This fixes an issue where clearing cached Point of Sale order lines could leave some lines behind. The cleanup now removes all affected lines reliably, reducing the chance of checkout or order processing errors.
Original PR description
Before this commit, clearing lines in the sanitize data cache used a forward iteration, which caused some lines to be skipped due to index shifting when deleting items. This could result in only half of the lines being removed and potentially lead to errors. After this commit, order lines are deleted using a backward iteration, ensuring that all lines are properly removed without skipping any. opw-4770945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where customer review comments and message text could become hard to read when a website shop used a dark theme. The change keeps review text visible against the light review bubbles, improving the shopping experience for visitors and editors.
Original PR description
<b>Steps to reproduce:</b> 1. Website > shop > Open any product > Open Editor(Edit) 2. Customize → Navigate to Customer → Click on Rating. 3. Theme → Navigate to Colors → Navigate to Light & Dark >…
<b>Steps to reproduce:</b> 1. Website > shop > Open any product > Open Editor(Edit) 2. Customize → Navigate to Customer → Click on Rating. 3. Theme → Navigate to Colors → Navigate to Light & Dark > Choose Dark theme. <b>Issue:</b> Website Shop, when using a dark background, the text in write a message box and comment bubbles in reviews sections becomes white making it invisible. <b>Cause:</b> In light mode, the text appears black, making it easy to read. However, when switching to dark mode, the text changes to white, which makes it difficult to read against the light bubble background. <b>Solution:</b> This commit adds class text-black to the comment and description container to improve the visibility. <b>opw : 4724764</b> <b>BUG:</b>    <b>FIX:</b>   
Tasks created from sales orders will again include the relevant sales line description in their title. This makes generated tasks easier to identify and restores expected behavior from earlier versions.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on confirm; 2. add product to a SO; 3. add description to the line; 4. confirm the order; 5. go to the task. Issue…
Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on confirm; 2. add product to a SO; 3. add description to the line; 4. confirm the order; 5. go to the task. Issue ----- The task only has the SO and service product name as title. This is different from earlier versions, where it would include the first line of the line's description. Cause ----- When creating a task from an order line, it uses the first line of the line name as part of the task name, and adds the rest to the description. Starting from 18.0, the product & description columns are merged in order & invoice views. A side-effect of this, is that the product name will always be present as the first line of the product, and any added description will start from the second line. Consequently, it's no longer possible to add a description to the line that would get used as task name. Solution -------- Use the first two lines of the sale line name to form a task title. opw-4634149 opw-4637902
This fixes an issue where Point of Sale could use the wrong numbering format for dates and times when a database uses a non-Latin numbering system. It helps ensure receipts, orders, and synchronized device data show date and time values consistently for affected locales.
Original PR description
When a database isn't in ltn format, the datetime numbering system is not set to the correct value. This commit fixes the issue by ensuring that the datetime numbering system is set to the correct value.
Fixed an issue where sale orders with delivered combo products could still appear ready to invoice after the invoice was confirmed. This keeps invoice status accurate for products billed on delivery and helps prevent duplicate or confusing invoicing actions.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a combo product with only items that are invoiced on delivery; 2. add it to a sale order; 3. validate the delivery; 4. create & confirm an invoice. Issue ----- The sale order is still invoicable. Cause ----- The `qty_to_invoice` field for the combo item line isn't being updated when its linked lines were delivered. Solution -------- Add `linked_line_ids.qty_delivered` to the `api.depends` of the compute method. opw-4633972
Fixes an accounting issue where analytic distribution details could be cleared from tax lines when journal entries were saved and tax lines were synchronized. This helps keep reporting allocations accurate and prevents users from having to re-enter analytic information.
Original PR description
Analytic distribution is not tracked when synchronising the tax line Steps: - Have an income account X with a sale tax set - Create a journal entry with one line, having account X and debit xxx$ - Save the form, two lines should have been created, auto balancing line and tax line - Set an analytic distribution on these two lines and save the form -> The analytic distribution is unset from the tax line Before this commit, we were keeping values of `amount_currency` and `balance`, now we keep also `analytic_distribution` in the tracked fields opw-4662784
This change adjusts an internal automated test so it checks that only the valid customer payment is created, rather than relying on a less relevant status value. It helps keep SEPA direct debit quality checks stable without changing customer-facing behavior.
Original PR description
Here we don't really care about the state, we replaced it by just checking that there is only one payment and to the "agrolait" partner since it has a valid mandate. build_error-163134
This update adjusts an internal automated test for SEPA Direct Debit so it checks the important payment details rather than a status that can vary after demo data changes. It helps keep the test suite reliable without changing customer-facing behavior.
Original PR description
There's been quite a lot of refactoring of demo-data and stuff so now the setup may have been changed in the background Here we don't really care about the state, so we can replace it by just checking that there is 2 payments and to the "agrolait" partner and "china_export" partner build_error-163133
Mexican payroll now calculates payslips for hourly employees using the hourly wage and actual worked hours, including unpaid leave adjustments. This prevents incorrect monthly wage values from being applied to hourly contracts and improves payroll accuracy for Mexican companies.
Original PR description
Steps to reproduce: - Install payroll, payroll Mexican localisation - Switch to the Mexican company - Choose an employee from the Mexican company - Change the contract to be hourly waged instead of…
Steps to reproduce: - Install payroll, payroll Mexican localisation - Switch to the Mexican company - Choose an employee from the Mexican company - Change the contract to be hourly waged instead of monthly - Set a value for the wage/hour - Create some work entries for that employee - Generate a payslip for the employee in the duration you are testing - Edit the work entries you have to have some unpaid leaves - Generate another payslip for the employee Current Behavior: Payslip is generated without taking into consideration the number of hours actually worked and the unpaid leaves taken by the employee. It also generates the payslip with the value of the wage/month regardless of the value of the wage/hour you added. Issue: In df8f53b0cad4738537f18890e628c286dedaa141, Mexican localisation was implemented but with computing the amount of the `payslip_worked_days` using the `contract.wage` which is the fixed amount of wage/month. https://github.com/odoo/enterprise/blob/25caeeab01abc0b47f6bd6b02658c3bbbe0aba96/l10n_mx_hr_payroll_localisation/models/hr_payslip_worked_days.py#L19-L20 opw-4604675
Trial Balance end balances now calculate correctly when reports are grouped by analytic accounts or horizontal groups, preventing totals from being overstated. Romanian Trial Balance reports also no longer crash in the same analytic grouping scenario, improving reliability for accounting users.
Original PR description
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic…
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic distribution - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Activate "Analytic Group By" in the settings of the report - Add the account used in the analytic distribution in "Analytic" group option **Issue 1:** In the "End Balance" column, all the amounts are summed in the total column instead of being grouped by analytic accounts. It results on a total amount being twice what it should be as the total column of each period is also included in the sum. There is a similar issue with horizontal groups. **Cause 1:** The "End Balance" column is not computed via the SQL as all the data required to compute it are already retrieved. However, the case where there are groups by analytic is not handled. It results on the computation taking the value of a analytic group and also the value of the total group, which doubles the computed amount. **Solution 1:** As it is not possible to identify easily each different group in each period to sum the corresponding values together, the computation of the "End Balance" will be done in the SQL if the groupby analytic is done or if a horizontal group is set. **Issue 2:** - Install l10n_ro_reports - Switch to a Romanian company (RO Company) - Follow the same steps than issue 1 - Select "Trial Balance 4/5 col (RO)" as Report => A traceback is raised: "TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'" opw-4648009
Documentation and clarification updates
This pull request adds contributor license agreement records for individual contributors and includes a small compatibility fix for internal lint testing. It helps keep contribution records complete while maintaining automated checks on supported Python versions.
Original PR description
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
Miscellaneous changes
**Problem:** When adding a product that has the landed cost setting activated to a Vendor Bill, the landed cost checkbox was not checked, thus the product was not registered with a landed cost in the Vendor Bill. Adding the product straight from the vendor bill worked fine. **Steps to reproduce:** - Make a product with a landed cost. - Make a new vendor bill and go to the catalog from the Invoice Lines tab. - Search for your product and add it to the Vendor Bill. - Return to the Vendo
Original PR description
**Problem:** When adding a product that has the landed cost setting activated to a Vendor Bill, the landed cost checkbox was not checked, thus the product was not registered with a landed cost in the…
**Problem:** When adding a product that has the landed cost setting activated to a Vendor Bill, the landed cost checkbox was not checked, thus the product was not registered with a landed cost in the Vendor Bill. Adding the product straight from the vendor bill worked fine. **Steps to reproduce:** - Make a product with a landed cost. - Make a new vendor bill and go to the catalog from the Invoice Lines tab. - Search for your product and add it to the Vendor Bill. - Return to the Vendor Bill and see that the landed cost is not checked. **Cause of the issue:** The field is_landed_costs_line is set in an onchange function, thus when adding a product from the catalog the said function is not triggered and the is_landed_costs_line is not applied. https://github.com/odoo/odoo/blob/01058b94d860ab508bc2c013af5fe887e08247d9/addons/stock_landed_costs/models/account_move.py#L61-L66 **Fix:** An override of the create function was added to add the correct landed cost even when the onchange function is not called. With the onchange function and the create function, this ensures that the is_landed_costs_line will be set correctly regardless of where it is created from. opw-4521391 Forward-Port-Of: odoo/odoo#201622
We predict the account to use in an invoice/purchase entries based on product configuration and frequent account used for partner but we do not verify if those accounts are allowed on the specified journal. This can be problematic if the entry is generated from a external file (ex: using Peppol), Odoo should retrieve an account allowed in the journal. Steps to reproduce: 1. Have two purchase journal A and B on the same company 2. Set an expense account that is allowed on one of those journa
Original PR description
We predict the account to use in an invoice/purchase entries based on product configuration and frequent account used for partner but we do not verify if those accounts are allowed on the specified journal. This can be problematic if the entry is generated from a external file (ex: using Peppol), Odoo should retrieve an account allowed in the journal. Steps to reproduce: 1. Have two purchase journal A and B on the same company 2. Set an expense account that is allowed on one of those journal (A) and not the other (B) 3. Create multiple bills with this account on the journal A for partner X 4. Upload a XML bill of partner X in journal B -> The expense account is used based on the bills in journal A -> Error because journal B is not allowed for this account opw-4607733 Forward-Port-Of: odoo/odoo#206104 Forward-Port-Of: odoo/odoo#203664
…dd it in the tax details 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#207100 Forward-Port-Of: odoo/odoo#206052
Original PR description
…dd it in the tax details 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#207100 Forward-Port-Of: odoo/odoo#206052
**Problem:** The problem happens when a service is linked to a task but it's not billed on timesheet. If a quotation is created with this service (which creates the task linked to it) and a timesheet is added to the task, this will trigger a recompute of `purchase_price` (the cost column) of the sale order line in the quotation. If the client had written another cost on the sale order line of the quotation than the original one (coming from the `standard_price` of the product) this will
Original PR description
**Problem:** The problem happens when a service is linked to a task but it's not billed on timesheet. If a quotation is created with this service (which creates the task linked to it) and a timesheet…
**Problem:** The problem happens when a service is linked to a task but it's not billed on timesheet. If a quotation is created with this service (which creates the task linked to it) and a timesheet is added to the task, this will trigger a recompute of `purchase_price` (the cost column) of the sale order line in the quotation. If the client had written another cost on the sale order line of the quotation than the original one (coming from the `standard_price` of the product) this will erase it and set the value back to the standard price of the product. Because the service is not billed on timesheet we don't want a modification of timesheet to affect the cost set on the quotation. **Steps to reproduce:** - In settings, activate the "margins" setting in Sales - Open Sales/products and create a new product - Set the product type as "Service" - Set the "create on order" field as Task - Set the "project" field to an existing project - Set a strictly positive value in the cost field - Set a name and save - Create a new quotation and add the product you just created - Confirm the quotation - In the order lines page, add the cost column - Change the value of the cost column - Click on the "Tasks" smart button - Add a new timesheet in the timesheet page and save - Come back to the sale order via the smart button **Current behavior:** The value of the cost column was reset the the cost of the product **Expected behavior:** Mofifying the timesheets shouldn't impact the cost of a service which is not invoiced on timesheets **Cause of the issue:** Because the sale_timesheet_margin module is installed the _compute_purchase_price method is overriden and depends on analytic_line_ids.amount https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L8 when this method is called in our flow, because sol.product_id.purchase_price is not null our sale order line will not get filtered out https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L11 and it will reach the original _compute_purchase_price method were the value of purchase_price will be reset to the value of self.product_id.standard_price https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_margin/models/sale_order_line.py#L30 **Fix:** We want to filter out the sale.order.lines for which the computation of purchase_price has been triggered via the analytic_line_ids.amount dependency and for which we don't want the computation to happen (when the service_policy is not "timesheet"). We need to do this without filtering out the sales.order.lines for which the computation of purchase_price has been triggered by a dependency from the original compute_purchase_price method https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_margin/models/sale_order_line.py#L20-L21 or another orverride of this method (for now there are two of those : one in sale_expense_margin https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_expense_margin/models/sale_order_line.py#L10-L11 and one in sale_stock_margin https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_stock_margin/models/sale_order_line.py#L10-L11 ) is_expense is defined in the sale module is_service is defined in the sale_service module service_policy is defined in the sale_project module all those field are available when sale_timesheet_margin is installed opw-4627037 Forward-Port-Of: odoo/odoo#205415
Description of the issue/feature this PR addresses: Wrong address/zip/city in Swiss QR bill template. Current behavior before PR: The template for Swiss QR bills uses the company address, zip code and city. Desired behavior after PR is merged: The template for Swiss QR bills uses the address/zip/city of the creditor's bank account, if available. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207640
Original PR description
Description of the issue/feature this PR addresses: Wrong address/zip/city in Swiss QR bill template. Current behavior before PR: The template for Swiss QR bills uses the company address, zip code and city. Desired behavior after PR is merged: The template for Swiss QR bills uses the address/zip/city of the creditor's bank account, if available. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207640
The SpreadsheetName component is designed to grow indefinitely with the length of its text content. However, this means that it'll end up breaking the page layout. This revisions revisits the component structurea and embedding to prevent it from growing larger than the visible viewport of the client. Task: 4760366 Forward-Port-Of: odoo/enterprise#84410
Original PR description
The SpreadsheetName component is designed to grow indefinitely with the length of its text content. However, this means that it'll end up breaking the page layout. This revisions revisits the component structurea and embedding to prevent it from growing larger than the visible viewport of the client. Task: 4760366 Forward-Port-Of: odoo/enterprise#84410
Version: - saas-17.4 Steps to reproduce: - Create request signature activity for sign request. - Try to send document for sign from activity. Issue: - It will give a traceback to user. Cause: - It will try to create a record for 'sign.request' model and in reference_doc field it was showing wrong value as we are not allowing to create reference_doc for 'sign.request' model. Solution: - Since reference_doc is not supported for 'sign.request', this fix adds a condition to explici
Original PR description
Version: - saas-17.4 Steps to reproduce: - Create request signature activity for sign request. - Try to send document for sign from activity. Issue: - It will give a traceback to user. Cause: - It will try to create a record for 'sign.request' model and in reference_doc field it was showing wrong value as we are not allowing to create reference_doc for 'sign.request' model. Solution: - Since reference_doc is not supported for 'sign.request', this fix adds a condition to explicitly skip setting it for that model task-4416253 Forward-Port-Of: odoo/enterprise#75611
Forward-Port-Of: odoo/enterprise#84045 Forward-Port-Of: odoo/enterprise#84014
Original PR description
Forward-Port-Of: odoo/enterprise#84045 Forward-Port-Of: odoo/enterprise#84014
Before This **PR**: If a company attempted to generate a GST token using a GST number already assigned to another company with a valid token, the system returned an ambiguous error: {'message': 'API access is not available or user expiry duration is less than or equal to auth token expiry duration', 'error_cd': 'AUTH4037'}. This caused confusion for users, as the message did not clearly indicate the issue. After This **PR**: A new function has been introduced to check whether another compa
Original PR description
Before This **PR**:
If a company attempted to generate a GST token using a GST number already assigned to another company with a valid token, the system returned an ambiguous error: {'message': 'API access is not available or user expiry duration is less than or equal to auth token expiry duration', 'error_cd': 'AUTH4037'}. This caused confusion for users, as the message did not clearly indicate the issue.
After This **PR**:
A new function has been introduced to check whether another company has the same GST number and a valid token before sending the request. If such a case is detected, the system now displays a warning, recommending the use of a Tax Unit.
**task**-4636041
Forward-Port-Of: odoo/enterprise#84528
Forward-Port-Of: odoo/enterprise#81218