Wednesday, March 26, 2025
23 changes · saas-17.4
Enhancements to existing features
This update adds demo data for Mexican payroll localization, making it easier to test payroll scenarios with realistic setup information. It also aligns the demo company details with electronic invoicing demo data for more consistent testing.
Original PR description
This commit targets to add the necessary demo data for testing Mexican payroll localization target: saas-17.4 -> master task-4486643 Linked PR: [odoo/enterprise#80451](https://github.com/odoo/enterprise/pull/80451) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical VAT numbers. - Module summary, descriptions and ot
Original PR description
### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical VAT numbers. - Module summary, descriptions and other texts are updated to generalize - Companies without an accounting firm can access the Codabox configuration settings task - 4460499
Resolved issues and error corrections
This fixes an issue where pinned live chat conversations could appear under the wrong sidebar category after reloading the page. Users will see chats grouped correctly, making the inbox and live chat sidebar easier to navigate.
Original PR description
Before this PR, live chats were sometimes displayed under the wrong category. Steps to reproduce: - Ensure you have one live chat pinned in the sidebar. - Go to the inbox, fold the live chat category. - Reload the page. - Open the live chat category. - The chat is displayed under the wrong category. Since [1], the t-key used in the side bar template is the index of the category which is not reliable. Change it to the id field which is also unique but more reliable. [1]: https://github.com/odoo/odoo/pull/203150 
Miscellaneous changes
**Steps to reproduce:** 1. Create a company with IQD as its currency 1. Create a product with average costing and real_time accounting 2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD per IQD) 3. Create a purchase order for the product like: a. currency: USD b. price unit: 12.6 c. qty: 6 d. discount: 33.33% 4. Confirm the order 5. Receive the product 6. Create the bill 7. Open the journal items tree view The credit/debit amounts of the journal entrie
Original PR description
**Steps to reproduce:** 1. Create a company with IQD as its currency 1. Create a product with average costing and real_time accounting 2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD…
**Steps to reproduce:**
1. Create a company with IQD as its currency
1. Create a product with average costing and real_time accounting
2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD per IQD)
3. Create a purchase order for the product like:
a. currency: USD
b. price unit: 12.6
c. qty: 6
d. discount: 33.33%
4. Confirm the order
5. Receive the product
6. Create the bill
7. Open the journal items tree view
The credit/debit amounts of the journal entries for the reception and the invoice don't match. The `amount_currency` is the same, but there are additional exchange differences items.
The reception journal item balance is taken from the `stock.valuation.layer`.
In the example, `unit_cost` is in the company currency IQD:
https://github.com/odoo/odoo/blob/191d44c91a4578445d8cb59d3172042022cb5a9a/addons/stock_account/models/product.py#L177
The invoice's balance is computed with `amount_currency`, which is converted to USD with the exchange rate and rounded:
https://github.com/odoo/odoo/blob/4e724323d811dec76c186b5cfff6e4b0135b2128/addons/account/models/account_move_line.py#L1570
The difference between the roundings (depending on the conversion rate) may generate exchange differences that shouldn't be there.
**Fix:**
Try to prepare the AML balance while creating it from a purchase
line- we have the unrounded `price_unit_discounted` that may be
used to find an accurate balance.
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4103167)
opw-4103167
Forward-Port-Of: odoo/odoo#190043The Barcode app now avoids errors when the import feature is not installed separately. This helps users install and open the app without asset-loading failures caused by a missing optional component.
Original PR description
Installing stock_barcode without base_import installed results in errors in the assets when loading `ImportBlockUI`. This occurs because `stock_barcode` requires a component from `base_import` but does not explicitly declare it as a dependency. opw-4613302
Steps to reproduce Bug 1: 1. Create an accrual plan. 2. Check the box `Based on worked time`. 3. Create a milestone. The configuration of the milestone is arbitrary. For example accrue 10 days yearly. 4. Create an allocation. 5. Set allocation start date 1 year before. 6. Select accrual allocation. 7. Choose the accrual plan defined above. 8. Set multiple employees on the allocation 9. the number of allocated days will be 0. Steps to reproduce Bug 2: 1. Create a
Original PR description
Steps to reproduce Bug 1: 1. Create an accrual plan. 2. Check the box `Based on worked time`. 3. Create a milestone. The configuration of the milestone is arbitrary. For example accrue 10 days…
Steps to reproduce Bug 1: 1. Create an accrual plan. 2. Check the box `Based on worked time`. 3. Create a milestone. The configuration of the milestone is arbitrary. For example accrue 10 days yearly. 4. Create an allocation. 5. Set allocation start date 1 year before. 6. Select accrual allocation. 7. Choose the accrual plan defined above. 8. Set multiple employees on the allocation 9. the number of allocated days will be 0. Steps to reproduce Bug 2: 1. Create an accrual plan and milestone identical to the above but don't check the box `Based on worked time`. 2. Create an allocation. 3. Set allocation start date 1 year before. 4. Select accrual allocation. 5. Choose the accrual plan defined above 6. Set a single employee on the allocation 7. the number of allocated days will be 10. 8. Set 2 employees on the allocation instead of 1. 9. the number of allocated days will still be 10. Required Behavior: 1. If the accrual plan isn't `based on worked time`, then the number of allocated days should be computed normally on the allocation with multiple employees. 2. If the accrual plan `is based on worked time`, then the number of allocated days is different for each employee and it should be set to 0 on the allocation with multiple employees. task-4481698 Forward-Port-Of: odoo/odoo#193791
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the `export_data` public method on the models. However: - The domain is only available in the controller. `export_data` does not receive the domain in its params. Putting the logger in `export_data` would therefore lead to the inability to log the domain. Or we would need to do one logger in the con
Original PR description
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the…
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the `export_data` public method on the models. However: - The domain is only available in the controller. `export_data` does not receive the domain in its params. Putting the logger in `export_data` would therefore lead to the inability to log the domain. Or we would need to do one logger in the controller just for the domain, and a second logger in `export_data`. - During an export using a group by (and without import compatibility) `export_data` is called recursively, in `insert_leaf`. Hence, if the logger would be put in `export_data`, there would be one log per group, therefore bloating the logs. Hence, for stable versions, the decision taken is to put the log in the controller rather than in a lower level method. It's better than nothing. A rework of the API of `export_data` is planned in master to solve the above concerns. Forward-Port-Of: odoo/odoo#202568
### Description: When opening the replenishment view, the locations are checked to find if some products need to be refilled. If one product needs to be refilled, it will check if an orderpoint already exists, otherwise, it will create it. The issue is that the checks are currently done on all the orderpoints, even the ones not related to the product. The performances are worsened by the compute on `qty_to_order` triggered on all the orderpoints. ### Fix: To fix that, we can add a leaf
Original PR description
### Description: When opening the replenishment view, the locations are checked to find if some products need to be refilled. If one product needs to be refilled, it will check if an orderpoint already exists, otherwise, it will create it. The issue is that the checks are currently done on all the orderpoints, even the ones not related to the product. The performances are worsened by the compute on `qty_to_order` triggered on all the orderpoints. ### Fix: To fix that, we can add a leaf to the domain so that we only retrieve the orderpoints related to the products that need to be refilled. This will reduce the number of records on which we call the `qty_to_order` compute. ### Benchmark (in 18): | # of orderpoint | Before | After | | --------------- | ------ | ----- | | 44145 | 6:52 | 6s | | 22145 | 3:38 | 6s | ### Reference: opw-4618887 Forward-Port-Of: odoo/odoo#203276
FIX FOR MASTER −1 ------------------------------------------------------- After version 15 they display types stopped doing anything. Make them change the visual style again. task-4554655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203214 Forward-Port-Of: odoo/odoo#201186
Original PR description
FIX FOR MASTER −1 ------------------------------------------------------- After version 15 they display types stopped doing anything. Make them change the visual style again. task-4554655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203214 Forward-Port-Of: odoo/odoo#201186
Issue ----- For a German company, when confirming an invoice for an order the delivery date (of the invoice) gets set to the invoice date, even when one was manually provided beforehand. Steps to reproduce ----- - Install Sales, Inventory, Purchase and German localization - Switch to a German company - Create a product - Create a Sale Order for the product & confirm it - Validate the linked Delivery - Go back to the SO & create a (draft) Invoice - Set a delivery date & confirm the
Original PR description
Issue ----- For a German company, when confirming an invoice for an order the delivery date (of the invoice) gets set to the invoice date, even when one was manually provided beforehand. Steps to…
Issue ----- For a German company, when confirming an invoice for an order the delivery date (of the invoice) gets set to the invoice date, even when one was manually provided beforehand. Steps to reproduce ----- - Install Sales, Inventory, Purchase and German localization - Switch to a German company - Create a product - Create a Sale Order for the product & confirm it - Validate the linked Delivery - Go back to the SO & create a (draft) Invoice - Set a delivery date & confirm the Invoice -> The delivery date changed to the invoice date Cause ----- When posting, we set the invoice date if no value was provided. This triggers compute_delivery_date because it is overridden in the German localization to depend on the invoice_date field. The override is present because delivery_date is a legal requirement for the German localization. However, forcing a value for invoice_date is also handled in the _post override of the localization. We can thus change the compute into an onchange method (to keep suggesting a value to the user). This creates a problem of there being no value for delivery_date if invoice_date is also False. This is because _post sets delivery_date = invoice_date before calling the logic that forces a value for invoice_date. We should thus provide a fallback value. ----- Ticket: opw-4599301 Forward-Port-Of: odoo/odoo#201731
Description of the issue/feature this PR addresses: A bug occurred when the system attempted to automatically add a rounding line to an invoice in a multi-company environment. The company-dependent field was being updated without properly considering the invoice’s company context. Current behavior before PR: An error was raised when trying to create the rounding line because the system looked up the accounts for Company 1 instead of the invoice’s assigned company. Desired behavior after
Original PR description
Description of the issue/feature this PR addresses: A bug occurred when the system attempted to automatically add a rounding line to an invoice in a multi-company environment. The company-dependent field was being updated without properly considering the invoice’s company context. Current behavior before PR: An error was raised when trying to create the rounding line because the system looked up the accounts for Company 1 instead of the invoice’s assigned company. Desired behavior after PR is merged: No error was raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196479
**Current behavior before PR:** When applying a text color to text that already has a gradient color, the gradient color would be removed from selected text, causing gradient color the style to be interrupted. **Desired behavior after PR is merged:** Text color can now be applied without removing or affecting the existing gradient color. task: 4196424 Forward-Port-Of: odoo/odoo#200336 Forward-Port-Of: odoo/odoo#184035
Original PR description
**Current behavior before PR:** When applying a text color to text that already has a gradient color, the gradient color would be removed from selected text, causing gradient color the style to be interrupted. **Desired behavior after PR is merged:** Text color can now be applied without removing or affecting the existing gradient color. task: 4196424 Forward-Port-Of: odoo/odoo#200336 Forward-Port-Of: odoo/odoo#184035
LATAM task 1299 / Adhoc Task 47453 --- ### Description of the issue/feature this PR addresses: Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on B2C. This only affects Factura B and related documents. Now, we will show an extra tax detail section with the title "Fiscal Transparency Regime for the Final Consumer (Law 27.743)" and show the details of the taxes grouped by type: VAT Taxes and Other National Internal Indirect Taxes. For m
Original PR description
LATAM task 1299 / Adhoc Task 47453 --- ### Description of the issue/feature this PR addresses: Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on…
LATAM task 1299 / Adhoc Task 47453 --- ### Description of the issue/feature this PR addresses: Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on B2C. This only affects Factura B and related documents. Now, we will show an extra tax detail section with the title "Fiscal Transparency Regime for the Final Consumer (Law 27.743)" and show the details of the taxes grouped by type: VAT Taxes and Other National Internal Indirect Taxes. For more info about the RG, go to https://servicioscf.afip.gob.ar/publico/sitio/contenido/novedad/ver.aspx?id=4448 ### Current behavior before PR: Old version of legal PDF report; we are not showing vat taxes, and summarying internal and national taxes on the tax totals  ### Desired behavior after PR is merged: We add a special table at the end of the report (ask required in the RG) with the detail of the taxes group by type: vat taxes, and other internal and national taxes  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203175 Forward-Port-Of: odoo/odoo#201257
Have an action with multiple views (eg form,kanban,list) When the action spawns on its first view, the feature worked well: there were no breadcrumbs. Click on the view switcher to another view type. Before this commit, the breadcrumbs appeared for that step on. After this commit, the breadcrumbs do not appear for the whole action. task-4583126 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I
Original PR description
Have an action with multiple views (eg form,kanban,list) When the action spawns on its first view, the feature worked well: there were no breadcrumbs. Click on the view switcher to another view type. Before this commit, the breadcrumbs appeared for that step on. After this commit, the breadcrumbs do not appear for the whole action. task-4583126 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#202712
Ensures only Peppol-type proxies are retrieved for updating participant status. Steps to reproduce: - Install Peppol and IT EDI - Register Peppol and IT EDI users - Go to Scheduled Actions and run “PEPPOL: update participant status” - Error: “Error while updating Peppol participant status: The URL requested returned an error. The URL it tried to contact was False/api/peppol/1/participant_status” opw-4624633 Forward-Port-Of: odoo/odoo#203212
Original PR description
Ensures only Peppol-type proxies are retrieved for updating participant status. Steps to reproduce: - Install Peppol and IT EDI - Register Peppol and IT EDI users - Go to Scheduled Actions and run “PEPPOL: update participant status” - Error: “Error while updating Peppol participant status: The URL requested returned an error. The URL it tried to contact was False/api/peppol/1/participant_status” opw-4624633 Forward-Port-Of: odoo/odoo#203212
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#203117
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 Forward-Port-Of: odoo/odoo#203117
A new tag is necessary to calculate deductibles expenses associated to 190 AEAT report. It isn't a percent tax, it's a new tag to can set it in move lines and calculate this box from 190 AEAT report. 190 AEAT report (190 AEAT) isn't now included in Odoo, but it could be added in the future. Meanwhile the tax can be used in oca module `l10n_es_aeat_mod_190' or you can do a filter for this tax and fill in the report manually. https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_reg
Original PR description
A new tag is necessary to calculate deductibles expenses associated to 190 AEAT report. It isn't a percent tax, it's a new tag to can set it in move lines and calculate this box from 190 AEAT report. 190 AEAT report (190 AEAT) isn't now included in Odoo, but it could be added in the future. Meanwhile the tax can be used in oca module `l10n_es_aeat_mod_190' or you can do a filter for this tax and fill in the report manually. https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_100_199/archivos_24/DISENOS_LOGICOS_190-2024.pdf https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/GI10/Instrucciones/instr_mod190_es_es.pdf @moduon MT-8853 @rafaelbn @etobella @pedrobaeza @jco-odoo @chklop --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200338 Forward-Port-Of: odoo/odoo#198546
eLearning uses server date when processing dashboard values, which causes a mismatch from the perspective of the user. This commit changes the source of "today" to use the user's timezone on the dashboard and actions, while keeping compute functions on the server date as these values should not change based on the timezone of the observer. opw-4411615 Forward-Port-Of: odoo/enterprise#80490
Original PR description
eLearning uses server date when processing dashboard values, which causes a mismatch from the perspective of the user. This commit changes the source of "today" to use the user's timezone on the dashboard and actions, while keeping compute functions on the server date as these values should not change based on the timezone of the observer. opw-4411615 Forward-Port-Of: odoo/enterprise#80490
The Expense Account column was missing from the Asset Models list view. task-4402982 Forward-Port-Of: odoo/enterprise#80256 Forward-Port-Of: odoo/enterprise#78432
Original PR description
The Expense Account column was missing from the Asset Models list view. task-4402982 Forward-Port-Of: odoo/enterprise#80256 Forward-Port-Of: odoo/enterprise#78432
Accessing the tax report from a branch company raised a user error due to attempting to fetch tax group XML IDs using the company’s CID. While this could be resolved by using `self.env["account.chart.template"].ref`, the report isn’t intended to be shown for branch companies. Instead, a constraint was added to prevent access in such cases. opw-4569580 Forward-Port-Of: odoo/enterprise#82101
Original PR description
Accessing the tax report from a branch company raised a user error due to attempting to fetch tax group XML IDs using the company’s CID. While this could be resolved by using `self.env["account.chart.template"].ref`, the report isn’t intended to be shown for branch companies. Instead, a constraint was added to prevent access in such cases. opw-4569580 Forward-Port-Of: odoo/enterprise#82101
[This commit] updated the XBRL version of the Dutch tax reports from the 2024 version (NT18) to the 2025 version (NT19). However, users still need to be able to submit reports for 2024 using the previous scheme. In order to allow this, we keep both the 2024 and 2025 version of the XBRL template and choose the right one depending on the year of the report. In subsequent years, we can then remove the oldest version and add the newest version. The report IDs are suffixes with the year. [op
Original PR description
[This commit] updated the XBRL version of the Dutch tax reports from the 2024 version (NT18) to the 2025 version (NT19). However, users still need to be able to submit reports for 2024 using the previous scheme. In order to allow this, we keep both the 2024 and 2025 version of the XBRL template and choose the right one depending on the year of the report. In subsequent years, we can then remove the oldest version and add the newest version. The report IDs are suffixes with the year. [opw-4600111](https://www.odoo.com/odoo/project.task/4600111) [opw-4664515](https://www.odoo.com/odoo/project.task/4664515) [This commit]: https://github.com/odoo/enterprise/commit/f1710461f37f3560486a1410f9b9ff420b052b7b Forward-Port-Of: odoo/enterprise#82026
This commit modifies Elvera and Roque demo data for hr mexican localization target: 17.0 -> master task-4486643 Linked PR: [odoo/odoo#199888](https://github.com/odoo/odoo/pull/199888) Forward-Port-Of: odoo/enterprise#78048
Original PR description
This commit modifies Elvera and Roque demo data for hr mexican localization target: 17.0 -> master task-4486643 Linked PR: [odoo/odoo#199888](https://github.com/odoo/odoo/pull/199888) Forward-Port-Of: odoo/enterprise#78048
The list of approvers is computed based on the selected category for the approval request. Before the fix, the list would keep previous approvers when changing the category. This could lead to issues where users could add themselves as approvers on unauthorized categories. Steps to reproduce: - Create an approval request category (c1) with yourself as approver. - Create another approval request category (c2) with someone else as approver. - Create a request with category c1 and change to c
Original PR description
The list of approvers is computed based on the selected category for the approval request. Before the fix, the list would keep previous approvers when changing the category. This could lead to issues where users could add themselves as approvers on unauthorized categories. Steps to reproduce: - Create an approval request category (c1) with yourself as approver. - Create another approval request category (c2) with someone else as approver. - Create a request with category c1 and change to category c2. - You are now an approver of the approval request. This commit fixes the issue by reseting the list of approvers to only take the ones configured on the category. task-4637083 Forward-Port-Of: odoo/enterprise#82051 Forward-Port-Of: odoo/enterprise#81129