Daily updates from Odoo
Navigate
Branch
Thursday, November 13, 2025
227 changes
11 changes
Enhancements to existing features
This change prevents the system’s public user account from being deleted. It ensures the login page remains available and avoids a server error that could block access to the database.
Original PR description
Steps to Reproduce:
1. Create a database without installing the Website module.
2. Navigate to archived users and delete the "Public User."
3. Attempt to log in to the database from another browser or incognito
mode.
4. An internal server error occurs because the public user does not
exist, making the login page inaccessible.
Issue:
Previously, it was possible to delete the public user, leading to an
internal server error due to its absence, which prevented public access
to the login page.
Solution:
- Implemented a restriction to prevent the deletion of the public user,
similar to portal and default users.
- Added a test case to validate this functionality and ensure the
public user cannot be deleted.
task-4423568
Forward-Port-Of: odoo/odoo#233328
Forward-Port-Of: odoo/odoo#196918Account tags used for Belgium’s 281.50 reporting now include the country on the tag itself. This makes the tags easier to group and helps reuse them in other reporting cases when needed.
Original PR description
Account tags for 281.50 are specific to Belgium. With this PR, the country is added to those tags, allowing easier group by and enabling their use in other cases as well. task-5236632 Forward-Port-Of: odoo/enterprise#98759
Resolved issues and error corrections
This update fixes an issue where certain payment amounts could be written incorrectly in BACS batch files because of rounding errors. As a result, exported payment files now show the correct penny amount, helping avoid payment discrepancies.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413 Forward-Port-Of: odoo/enterprise#99180
This change removes an unnecessary test flag from the self-order mobile online payment tour. It prevents a local debug-mode issue, so developers can run and test the flow without unexpected problems.
Original PR description
In this commit: - Removed the `test: true` flag from the `test_kiosk_cart_restore_and_cancel` tour. - The flag is not required for tours and can cause issues when running in debug mode. - This issue only occurs in local environments when debug mode is enabled. - After this fix, no issue is generated in debug mode. Forward-Port-Of: odoo/odoo#234101
The system now correctly ignores the Pi 5's built-in serial port when listing serial devices. This prevents an internal port from appearing as an available connection, which avoids confusion and reduces the risk of selecting the wrong device.
Original PR description
The serial interface previously included a filter to not include the built-in serial port on the Pi 5, however this filter is now broken in Raspberry Pi OS Trixie. To ensure the filter works in all versions, we now explicitly look for the device `/dev/ttyAMA10` and ignore it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235074
This change fixes a rare issue in Knowledge where moving an article and then opening another one could occasionally show the wrong content in the editor. It makes article selection more reliable, so users can continue editing the correct page without interruptions.
Original PR description
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously…
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor. The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article. Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)). This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile. runbot error~182073 Forward-Port-Of: odoo/enterprise#99174
This change corrects how inventory value is recorded when a subcontracted product is delivered directly from a supplier to the customer. It prevents leftover stock value from being kept on the receipt record, which could otherwise distort product costing, especially for FIFO products.
Original PR description
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a…
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a remaining_value. (This also happens with 'standard price' and 'avco' but it's mostly problematic for fifo products. This being said the fix solves all 3 cases) Some context: When we confirm a SO and validate the delivery of a dropshipped (not sbc) product, two svls are created, - one with a negative quantity and value. - one with positive quantity and value. Both have a zero remaining value and remaining quantity. The outgoing svl does not trigger run_fifo or decrease the remaining_qty and remaining_value on any svl. In other words the fifo logic is not applied. If it was the case, the dropship delivery would impact the fifo valuation and other layers which we don't want as the product never really entered the stock. In the use case of this PR, a subcontracted dropshipped fifo product being delivered, the outgoing svl(s) are linked to the dropship and have the correct values. But the incoming svl is linked to the subcontract order and has a remaining value and remaining quantity which will impact the fifo logic when it shouldn't. **Steps to reproduce:** - enable the subcontracting setting and the dropshipping setting. - create a storable product, with a fifo category and positive cost. - create a subonctracted bom with a consumable component. - in the purchase tab of the product set a vendor which is the same as the subcontractor of the bom. - in the inventory tab select only the dropship route - create and confirm a SO for this product. - on the PO enter a positive unit price and confirm - validate the dropship delivery - click on the valuation smart button **Current behavior:** the stock valuation layer linked to the subcontract picking (the one with a positive quantity) has a positive remaining quantity and remaining value. **Expected behavior:** As the product is dropship remaining quantity and remaining value should be 0 **Cause of the issue:** When action_done is called on the picking: 1) In the super method, action_done is called on the move. There, _create_dropshipped_svl is called. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 Inside _get_dropshipped_svl_vals only the value for the (first) outgoing svl is returned because the location_id (subcontrating location) is valued. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L226 2) In the mrp_subcontracting override, button_mark_done is called on the mrp.production associated with the picking. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting/models/stock_picking.py#L90 Therefore action_done is called on the finished products move the mrp.production. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp/models/mrp_production.py#L1731 The move is a 'in' move so this lead to the creation of an in svl. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 The problem is that there is no mechanism to prevent the in svl from having a remaining_value and remaining_qty **fix** The mrp_subcontracting_dropshipping override of _action_done (on stock picking) is where, when needed, the other ougoing layer is created specifically in this subcontracting dropshipping use case. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L27-L32 Because the conditions are the same, imo, it's a good place to set the value of remaingin_value and remaining_qty of the incoming svl to 0. opw-5184644 Forward-Port-Of: odoo/odoo#234573 Forward-Port-Of: odoo/odoo#233041
This update fixes and simplifies the translated labels used for Italian electronic document types. It helps ensure the right document type names appear more clearly and consistently for users creating e-invoices and related documents.
Original PR description
Simplified and fixed labels and labels translations. Ref: https://help.fattureincloud.it/help/articolo/544-crea-autofattura-elettronica Ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiGeneraliDocumento/TipoDocumento Forward-Port-Of: odoo/odoo#235374 Forward-Port-Of: odoo/odoo#233943
Opening Studio from a calendar view now works even when the calendar uses a field that has access rules or grouping configured. This fixes a crash that previously blocked users from editing such calendars in Studio.
Original PR description
Have a calendar view that has a field A. the field A has a group on it, defined either in python or in the XML. Before this commit, opening studio in the calendar view crashed, because calendar did not support yet those fields that are marked with studio_no_fetch in their attributes. After this commit, there is no crash Forward-Port-Of: odoo/enterprise#99254 Forward-Port-Of: odoo/enterprise#98903
When users selected several lines in the bank reconciliation list and created a statement, the starting balance could be calculated incorrectly. This update restores the correct data needed for that calculation, so the statement starts with the right balance.
Original PR description
When selecting multiple lines and doing a statement in the list view. The balance start was wrong because the computation relies on the active_ids that wasn't correctly filled. The reason is that during the refactoring: https://github.com/odoo/enterprise/commit/2335c953723dce66af8811fdfbfd5b811d42b109 We actually remove a custom widget allowing to pass the active_ids. task-5245426 Forward-Port-Of: odoo/enterprise#99013
This change prevents payroll errors when a flexible working schedule is used in a salary offer. It makes the working-time fields visible so they can be set correctly, avoiding a calculation error that could block payroll processing.
Original PR description
…or flexible working schedules ``` odoo.exceptions.UserError: Código Python erróneo definido para: - Empleado: Donovan Raziel Castillo - Versión: False - Recibo de nómina: Payslip Simulation - Regla…
…or flexible working schedules ``` odoo.exceptions.UserError: Código Python erróneo definido para: - Empleado: Donovan Raziel Castillo - Versión: False - Recibo de nómina: Payslip Simulation - Regla salarial: Holidays On Time to Substruct (HOLIDAY_TO_SUB) - Error: float division by zero ``` Steps to reproduce: 1. Create a new database in saas-18.4 and install: resource, l10n_mx, l10n_mx_hr_payroll, hr_payroll, hr_contract_salary_payroll 2. Go to the Recruitment app → create a Salary Offer. 3. Assign a name, an applicant, and a contract template. 4. In the contract template: - Name: Department - Contract Type: Permanent, employee_mexico - Working Hours: create a new schedule 5. Set Schedule Type = Flexible 6. Fill Hours per Week (`full_time_required_hours`) (e.g., 48) → Notice that Hours per Week and Work Time Rate are not visible. In saas-18.4, when a working schedule is configured as Flexible, the computation of `work_time_rate` results in 0.0 because the field `hours_per_week` remains unset (it is only visible when Flexible Hours is [False](https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/views/resource_calendar_views.xml#L85-L92)). As a result, during migration, when the computation occurs in `hr_contract_salary_offer`, A division by zero error is raised during the salary rule Python computation. Root cause: When the calendar is flexible, and Hours per Week (`full_time_required_hours`) are defined, the computation of `work_time_rate` returns 0.0. As a result, when the salary rule computation (`_compute_rule`) performs a division using this zero value, a ZeroDivisionError occurs. Technical point of view: The error occurs because the Work Time Rate is not being calculated correctly. In both versions [18.4 ](https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/models/resource_calendar.py#L143-L151)and [19.0](https://github.com/odoo/odoo/blob/19.0/addons/resource/models/resource_calendar.py#L250-L258), the compute logic is the same — it depends on the fields `hours_per_week` and `full_time_required_hours`. However, in this case, the computation behaves incorrectly. If the customer provides a value for Equivalent Working Hours, the code enters the `if` [condition](https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/models/resource_calendar.py#L146) to calculate the Work Time Rate. Since the field `hours_per_week` is only visible and its [computation] (https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/models/resource_calendar.py#L136-L141) happens when Flexible Hours is [False](https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/views/resource_calendar_views.xml#L85), its value remains 0, which leads to a Work Time Rate of 0.0 always. On the other hand, in the `else` [condition](https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/models/resource_calendar.py#L148), the Work Time Rate is directly set to 100. This means that when Flexible Hours = True and Equivalent Working Hours is not filled in, the calculation always results in 100. Solution: To fix this issue, we should make both Work Time Rate and Hours per Week visible in the form view for the customer. This fix aligns the behavior with the version 19.0 [In 19.0 the both `hours_per_week` and `work_time_rate` visible for the user from this [IMP](https://github.com/odoo/odoo/commit/5cb102546ea4370b4fe5e4a4f37cccdc90c263fd) fix.] by making both `hours_per_week` and `work_time_rate` visible in the working schedule form view. This allows users to correctly configure these fields when using flexible calendars and prevents incorrect or zero-based calculations. In summary: The issue only occurs when Flexible Hours = True — in that case, the Work Time Rate calculation always results in 0.0. Showing both fields to the user ensures proper configuration and avoids incorrect computation. UPG:- 3269714 OPW:- 5124639 Errro-Pad :- https://pad.odoo.com/p/issue_5124639_labo 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
9 changes
Enhancements to existing features
The Belgian account tags for form 281.50 now carry the country set to Belgium. This makes them easier to organize and allows the same tags to be reused more cleanly in other contexts.
Original PR description
Account tags for 281.50 are specific to Belgium. With this PR, the country is added to those tags, allowing easier group by and enabling their use in other cases as well. task-5236632 Forward-Port-Of: odoo/enterprise#98759
Resolved issues and error corrections
This change fixes an issue where certain payment amounts could be written incorrectly in BACS batch files because of floating-point rounding. It ensures the exported amount matches the actual payment value, preventing underpayment by one penny in affected cases.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413 Forward-Port-Of: odoo/enterprise#99180
This update refreshes the spreadsheet component to its latest version and includes several bug fixes. It improves reliability when editing charts and filters, handles unusual sheet names better, and prevents some interface issues from appearing during normal use.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f31a75208 [REL] 18.3.26 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f31a75208 [REL] 18.3.26 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/3bfeb2c7f [FIX] composer: set editionMode to inactive when composer is unmounted [Task: 5149215](https://www.odoo.com/odoo/2328/tasks/5149215) https://github.com/odoo/o-spreadsheet/commit/1e94c7c0c [FIX] filter menu: truncate long filter values [Task: 5219611](https://www.odoo.com/odoo/2328/tasks/5219611) https://github.com/odoo/o-spreadsheet/commit/12b77d011 [FIX] range: invalid sheet name with special character [Task: 5125762](https://www.odoo.com/odoo/2328/tasks/5125762) https://github.com/odoo/o-spreadsheet/commit/0682b866f [FIX] charts: crash when converting empty chart to scorecard/gauge [Task: 5181741](https://www.odoo.com/odoo/2328/tasks/5181741) https://github.com/odoo/o-spreadsheet/commit/9017d0700 [FIX] helpers: setXcToFixedReferenceType support all xc [Task: 5165969](https://www.odoo.com/odoo/2328/tasks/5165969) https://github.com/odoo/o-spreadsheet/commit/49f1e4223 [FIX] Package: update owl to 2.8.1 [](https://www.odoo.com/odoo/2328/tasks/) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This fix restores the expected taxes on invoices for Saudi Arabia customers. It prevents default fiscal settings from unintentionally removing tax lines, so products with VAT now show the correct tax again.
Original PR description
Steps to reproduce: - With a SA company setup - Create an invoice - Set a Saudi Arabia partner - Add a product with 15% tax defined on it Issue: No tax shows up on the invoice line Analysis: This occurs because the default fiscal positions are all empty and empty fiscal positions remove all taxes. opw-5166882
Odoo now reliably hides the Raspberry Pi 5’s built-in serial port from the device list, even on newer Raspberry Pi OS versions. This prevents an internal port from appearing as if it were an available external device, which avoids confusion and misconfiguration.
Original PR description
The serial interface previously included a filter to not include the built-in serial port on the Pi 5, however this filter is now broken in Raspberry Pi OS Trixie. To ensure the filter works in all versions, we now explicitly look for the device `/dev/ttyAMA10` and ignore it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235074
This update fixes the Italian electronic document type names and their translations. It helps users see the correct labels when creating invoices and related documents, reducing confusion and improving consistency with the official format.
Original PR description
Simplified and fixed labels and labels translations. Ref: https://help.fattureincloud.it/help/articolo/544-crea-autofattura-elettronica Ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiGeneraliDocumento/TipoDocumento Forward-Port-Of: odoo/odoo#235374 Forward-Port-Of: odoo/odoo#233943
This update prevents a timing issue in Knowledge that could sometimes show the wrong article after reorganizing items and then opening another one. As a result, users should now reliably see the article they clicked and continue editing without interruption.
Original PR description
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously…
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor. The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article. Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)). This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile. runbot error~182073 Forward-Port-Of: odoo/enterprise#99174
This update corrects how inventory value is recorded when a subcontracted product is delivered directly from the supplier. It prevents the received stock layer from keeping a leftover value and quantity, which could otherwise distort product costing, especially for FIFO products.
Original PR description
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a…
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a remaining_value. (This also happens with 'standard price' and 'avco' but it's mostly problematic for fifo products. This being said the fix solves all 3 cases) Some context: When we confirm a SO and validate the delivery of a dropshipped (not sbc) product, two svls are created, - one with a negative quantity and value. - one with positive quantity and value. Both have a zero remaining value and remaining quantity. The outgoing svl does not trigger run_fifo or decrease the remaining_qty and remaining_value on any svl. In other words the fifo logic is not applied. If it was the case, the dropship delivery would impact the fifo valuation and other layers which we don't want as the product never really entered the stock. In the use case of this PR, a subcontracted dropshipped fifo product being delivered, the outgoing svl(s) are linked to the dropship and have the correct values. But the incoming svl is linked to the subcontract order and has a remaining value and remaining quantity which will impact the fifo logic when it shouldn't. **Steps to reproduce:** - enable the subcontracting setting and the dropshipping setting. - create a storable product, with a fifo category and positive cost. - create a subonctracted bom with a consumable component. - in the purchase tab of the product set a vendor which is the same as the subcontractor of the bom. - in the inventory tab select only the dropship route - create and confirm a SO for this product. - on the PO enter a positive unit price and confirm - validate the dropship delivery - click on the valuation smart button **Current behavior:** the stock valuation layer linked to the subcontract picking (the one with a positive quantity) has a positive remaining quantity and remaining value. **Expected behavior:** As the product is dropship remaining quantity and remaining value should be 0 **Cause of the issue:** When action_done is called on the picking: 1) In the super method, action_done is called on the move. There, _create_dropshipped_svl is called. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 Inside _get_dropshipped_svl_vals only the value for the (first) outgoing svl is returned because the location_id (subcontrating location) is valued. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L226 2) In the mrp_subcontracting override, button_mark_done is called on the mrp.production associated with the picking. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting/models/stock_picking.py#L90 Therefore action_done is called on the finished products move the mrp.production. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp/models/mrp_production.py#L1731 The move is a 'in' move so this lead to the creation of an in svl. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 The problem is that there is no mechanism to prevent the in svl from having a remaining_value and remaining_qty **fix** The mrp_subcontracting_dropshipping override of _action_done (on stock picking) is where, when needed, the other ougoing layer is created specifically in this subcontracting dropshipping use case. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L27-L32 Because the conditions are the same, imo, it's a good place to set the value of remaingin_value and remaining_qty of the incoming svl to 0. opw-5184644 Forward-Port-Of: odoo/odoo#234573 Forward-Port-Of: odoo/odoo#233041
Opening Studio on a calendar view now works correctly even when the calendar includes a field with access restrictions. Previously, this could cause the page to crash; now the editor safely handles those fields, improving reliability for users configuring calendars.
Original PR description
Have a calendar view that has a field A. the field A has a group on it, defined either in python or in the XML. Before this commit, opening studio in the calendar view crashed, because calendar did not support yet those fields that are marked with studio_no_fetch in their attributes. After this commit, there is no crash Forward-Port-Of: odoo/enterprise#99254 Forward-Port-Of: odoo/enterprise#98903
6 changes
Enhancements to existing features
The Belgian account tags for code 281.50 now include the country as part of their setup. This makes them easier to organize and also allows them to be reused in other situations where country-based grouping matters.
Original PR description
Account tags for 281.50 are specific to Belgium. With this PR, the country is added to those tags, allowing easier group by and enabling their use in other cases as well. task-5236632 Forward-Port-Of: odoo/enterprise#98759
Resolved issues and error corrections
This change corrects a rounding issue in BACS batch exports so payment amounts are written accurately in pence. It prevents small floating-point errors from causing exported payment files to show the wrong value, such as 64529 instead of 64530.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413 Forward-Port-Of: odoo/enterprise#99180
The fleet tax report check was using enterprise-only data that is not available in the community edition, which caused community builds to fail. The test and related query were moved to the enterprise module so the correct behavior remains in enterprise while community remains stable.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462 Forward-Port-Of: odoo/enterprise#98650
This fix ensures the POS shows the right error message when the Belgian blackbox or IoT box is disconnected. It also informs staff that the order was not sent to the preparation display, avoiding confusion and preventing orders from appearing to succeed when they did not.
Original PR description
Steps to reproduce: 1. Configure POS with Belgian blackbox and preparation display 2. Clock in as normal and start an order 3. At this point, disconnect the Blackbox or the IoT box 4. Try to order…
Steps to reproduce: 1. Configure POS with Belgian blackbox and preparation display 2. Clock in as normal and start an order 3. At this point, disconnect the Blackbox or the IoT box 4. Try to order some more items Expected behaviour: - An error message is received, informing the user of the blackbox error AND telling them the order has not been sent to the preparation display. Actual behaviour: - In the case the IoT is connected but the blackbox is not - The POS is stuck with a loading spinner forever - A prepration order is printed but not sent to the prepration display - In the case the IoT box is disconnected - An IoT box network error dialog shows, but it does not mention the blackbox or preparation display - A prepration order is printed but not sent to the prepration display The cause of this is that we were previously ignoring the result of the blackbox action. The fix is just to save the result and handle it appropriately. task-5253038 Forward-Port-Of: odoo/enterprise#99193
This change fixes an occasional issue in Knowledge where moving articles and then opening another one could show the wrong page in the editor. It makes article reloading more reliable, so the selected article is displayed correctly and the main tour no longer fails randomly.
Original PR description
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously…
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor. The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article. Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)). This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile. runbot error~182073 Forward-Port-Of: odoo/enterprise#99174
Opening Studio in a calendar view now works correctly even when one of the calendar fields is restricted by a group rule. This fixes a crash that could happen when editing the view, improving reliability for users customizing their calendars.
Original PR description
Have a calendar view that has a field A. the field A has a group on it, defined either in python or in the XML. Before this commit, opening studio in the calendar view crashed, because calendar did not support yet those fields that are marked with studio_no_fetch in their attributes. After this commit, there is no crash Forward-Port-Of: odoo/enterprise#99254 Forward-Port-Of: odoo/enterprise#98903
36 changes
Enhancements to existing features
Belgian point-of-sale blackbox messages are now queued so the register can continue more quickly when an immediate response is not required. This improves reliability and reduces delays for workflows such as pro forma sales while preserving communication with the fiscal device.
Original PR description
In this commit, we introduce a queuing mechanism for blackbox messages to make all interactions with the blackbox faster and more reliable. This is particularly useful for messages that do not require the response from the blackbox to continue the workflow such as pro forma sales messages. Forward-Port-Of: odoo/enterprise#98040 Forward-Port-Of: odoo/enterprise#90747
Tax return generation is now more efficient by grouping repeated checks and updates, reducing delays when saving fiscal year settings or refreshing returns. The change also prevents manually created draft returns from being removed incorrectly, helping preserve user-entered accounting work.
Original PR description
- batched _compute_company_ids on returns - batched return to unlink in _generate_or_refresh_all_returns - removed redondant call to _generate_or_refresh_all_returns in…
- batched _compute_company_ids on returns - batched return to unlink in _generate_or_refresh_all_returns - removed redondant call to _generate_or_refresh_all_returns in action_save_onboarding_fiscal_year since we want to call it only when a value is changed and that's already handled in the write on the company. - batched _is_available_for on reports - make only one write on the company (and one call to _generate_or_refresh_all_returns) when writing or create the fiscal year wizard. - dont delete return created manually with a date before the date of the account_opening_date and not yet posted. Detected from runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231463 A small workaround is needed on the company when writing the changes from the fiscal year wizard. This is because related fields are writen one by one, which then trigger multiple times _generate_or_refresh_all_returns. To prevent this, we are batching all the write on the company from the fiscal year wizard in one write. The opening_date need to be handled separatly since it's not a related field but still need to be writen on the company, if removed from the vals during the create it's then not possible to save the wizard anymore. Also fixed a bug where the returns manually created before the account_opening_date would be deleted if they were not posted before the next call to _try_create_returns_for_fiscal_year. **Detailed Explanation** We can see the tour being broken when trying to save on the wizard: <img width="1366" height="768" alt="image" src="https://github.com/user-attachments/assets/9443251c-aee1-4fbe-be2f-27c11bcbb77d" /> So we can do a flamegraph to take a look at what's happening on that database during that time and we can see 2 majors time uses, a call to `_generate_or_refresh_all_returns` triggered by a write on the wizard and a call to `action_save_onboarding_fiscal_year` <img width="1396" height="855" alt="image" src="https://github.com/user-attachments/assets/a9d310da-2787-4806-951d-e50b8c1da2a8" /> The first call to `_generate_or_refresh_all_returns` took about 7.8s, the second one took about 1.1s First, we can see a lot of `_compute_company_ids` calls, this is because we have `precompute=True` on this field due to it being needed in the different access rules. Since all the returns that are created have similar main company, tax unit and return type, we can easily batch them to only call `_get_company_ids` once for all the returns that will be created. Resulting in the following flamegraph: <img width="1422" height="866" alt="image" src="https://github.com/user-attachments/assets/c52c88c7-0263-44fb-a16c-52456673dc92" /> The first call to `_generate_or_refresh_all_returns` took about 0.8s, the second one took about 1.2s Another little change we can do is to remove the call to `_generate_or_refresh_all_returns` during `action_save_onboarding_fiscal_year` and adding the forced_date from the first one to the second one. <img width="1294" height="844" alt="image" src="https://github.com/user-attachments/assets/7ad55d06-ecd4-4957-b514-71fffa6de00c" /> We now end up with one call to `_generate_or_refresh_all_returns` that takes 1.4s BUT, we can still do better. We can see that all we did previously was only do to one thing less. The "real" problem was the many search calls done in `_is_available_for` during the `_init_options_variants`. <img width="1268" height="693" alt="image" src="https://github.com/user-attachments/assets/ebae398d-dfdd-4c1e-99ac-44f25e5875e7" /> After the final change, we are down to 0.9s ! One thing to keep in mind, all those flamegraph were done on a dump of a database from a nightly test, which had many companies created as well as **every** modules installed, which means every return types, reports, ... This means those performance improvements wont be as useful on small databases. Forward-Port-Of: odoo/enterprise#95760
The Brazilian localization now shows a specific tooltip explaining how to fill in the Incoterm location for export documents. This helps users provide the city or shipping location required for Brazilian EDI submissions, reducing confusion during export invoicing.
Original PR description
Purpose: Incoterm location is a field that will be widely used with Brazilian Exportation of Goods. It is required by the Brazilian EDI to send the incoterm location in its request specifying the city or location from which the goods are shipped. The field should have a tooltip explaining its specific purpose for the Brazilian EDI. related task-4802462 task-5180499
Belgian 281.50 account tags now include Belgium as their country, making them easier to group and identify in reporting. This helps businesses reuse these tags more reliably in Belgium-specific tax and accounting processes.
Original PR description
Account tags for 281.50 are specific to Belgium. With this PR, the country is added to those tags, allowing easier group by and enabling their use in other cases as well. task-5236632 Forward-Port-Of: odoo/enterprise#98759
Financial reports now use a clearer internal grouping method for report columns. This helps make report generation more reliable and easier to maintain without changing how business users interact with the reports.
Original PR description
task-5164369
A new setting lets users choose to disable barcode lookup instead of being forced to keep it active when an API key is automatically provided. This gives SaaS customers clearer control over the feature and can guide them through uninstalling the module when they no longer want to use it.
Original PR description
### Issue: Currently, the `product_barcodelookup` feature is disabled only when no API key is configured: https://github.com/odoo/enterprise/blob/86937d9c974125d60f6e2e9dc6bf0b048e20e489/product_barcodelookup/models/product_template.py#L199-L203 https://github.com/odoo/enterprise/blob/86937d9c974125d60f6e2e9dc6bf0b048e20e489/product_barcodelookup/tools/barcode_lookup_service.py#L7-L11 FHowever, for SaaS users, the API key is hardcoded, which makes it impossible to disable the feature without uninstalling the module. ### Improvement: The purpose of this commit is to add a boolean setting that allows users to explicitly disable the barcode lookup feature by proposing to uninstall the module for them. Community: https://github.com/odoo/odoo/pull/232794 opw-5096468
The report editor now automatically places the cursor in the first editable area when a report opens. This makes it clearer where users can begin editing, especially for new or blank reports, and shows the relevant placeholder guidance immediately.
Original PR description
Before this commit it was a bit hard to see where to click to start editing a report especially a blank or new one. After this commit, we focus the first hintable node that we can discover. This will: 1. Put the selection and cursor in that element 2. Trigger the hint plugin that will display the relevant placeholder task-4936527
The Belgian POS blackbox queue is now cleared when point-of-sale data is reloaded. This helps prevent repeated queued calls from getting stuck in an unexpected loop, improving stability for affected POS sessions.
Original PR description
This commit adds a clear of the blackbox queue when reloading data. This could avoid potential unexpected deadloop of calls in the queue. Forward-Port-Of: odoo/enterprise#99252
The spreadsheet interface now supports dark mode using shared styling variables, giving users a more comfortable viewing option in low-light environments. This also simplifies future visual maintenance by avoiding separate dark-mode stylesheets.
Original PR description
This commits implements dark mode for the user interface in o-spreadsheet. We can drop the drak mode-specific stylesheets and use CSS variables using `light-dark()` instead. Task: 5082659
The POS opening flow no longer checks Belgian blackbox driver versions before a session starts. This avoids an unnecessary startup check while still notifying users if an update is needed when they use blackbox features.
Original PR description
When introducing the blackbox queue service, we added a check at the opening of the POS to ensure that the blackbox drivers were up to date. This check is done at the start of session opening. It is now not necessary anymore, if the drivers are not up to date, an error will also be shown to the user when they try to use a blackbox functionality. Forward-Port-Of: odoo/enterprise#99014
Record creation controls in kanban and list views now use proper buttons, so they are automatically disabled while another action such as saving is in progress. This prevents users from accidentally triggering conflicting actions on slow connections, reducing crashes and improving reliability across affected workflows.
Original PR description
Before this commit, the `Add a record` in x2many kanban was a `<div>`, and the `Add a line` (and other "creates") in lists were `<a>`. Using buttons is semantically more correct. Morevoer, buttons are disabled when an action is ongoing in the webclient. For instance, when the form view is being saved, buttons are disabled. This allows to avoid concurrent and unwanted behaviors. Before this commit, such a behavior could happen with x2manys: in a form view with some changes (and on a slow network), click on the save icon, and directly click to add a record in the x2many. That "add" request was done on the current version of the static list, but that static list was replaced by a new one when the record is reloaded (post save), so a crash occured. By using `<button>`, those actions are automatically disabled when saving, thus removing the race condition.
User-facing wording has been updated from “Shipping Methods” or sales-level “Carrier” labels to “Delivery Methods” across supported delivery and marketplace integrations. This makes sales and delivery settings more consistent and easier to understand, while keeping carrier wording where it still applies to warehouse or provider-specific operations.
Original PR description
delivery_* = bpost, dhl, easypost, envia, fedex, sendcloud, shiprocket, starshipit, ups, usps, ups_rest, delivery_easypost, delivery_shiprocket, l10n_br_edi_website_sale, sale_amazon, sale_shopee…
delivery_* = bpost, dhl, easypost, envia, fedex, sendcloud, shiprocket,
starshipit, ups, usps, ups_rest, delivery_easypost, delivery_shiprocket,
l10n_br_edi_website_sale, sale_amazon, sale_shopee
With this PR:
---
1. Renamed 'Shipping Methods' to 'Delivery Methods'
* Renamed all user-facing labels of "Shipping Method(s)" to "Delivery Method(s)"
for consistent terminology across apps and improved user clarity, without
altering terminology used by specific delivery providers or third-party
integrations.
2. Renamed 'Delivery Carrier'/ 'Carrier' to 'Delivery Methods'
* A `Carrier` label is used at the stock level, while `Delivery Method` is used at
the sales level.
* A Delivery Method represents the complete carrier process along with the
required parameters defined at the sales level, whereas a Delivery Carrier
(or Carrier) is used at the transfer/picking level, where the focus is on
which carrier actually ships the goods rather than the full delivery
configuration.
* Therefore, all relevant occurrences of Delivery Carrier have been updated to
Delivery Method.
* The remaining occurrences of Carrier/Delivery Carrier refer either to
stock-level usage, delivery provider's internal labels, or
localization-specific terminology.
Impact:
-------
- This avoids confusion between "Shipping Method" and "Delivery Method", as
"Delivery Method" better reflects how an order is handed over to the customer,
making the terminology clearer and more contextual.
- Clarifies when "Delivery Method" vs. "Carrier" should be used by keeping "Carrier"
terminology where it correctly reflects stock-level operations, while ensuring sales-level
terminology remains consistent.
task-4720174Currency rates will now use only values from before the requested date, reflecting that rates apply to the following day and should remain stable during the day. This improves consistency in accounting, reporting, payments, and electronic invoicing where exchange rates affect financial amounts.
Original PR description
Currency rates are valid for the next day and should not change during the day. Use only rates strictly earlier than the requested date task-5173684
This update standardizes module information such as authors, licenses, website links, and app page references across many Odoo Enterprise apps. It improves consistency and trust in app listings without changing day-to-day product behavior.
Several automated tests were adjusted to match a recent change in how incoming email processing returns results. This helps keep quality checks reliable across invoicing, helpdesk, and Belgian SODA import features without changing user-facing behavior.
Original PR description
message_process now returns a recordset, tests are updated to not browse the return value anymore and simply use it as is.
This update simplifies how tag displays are customized in several Odoo apps, making it easier to keep tag-related screens consistent and adaptable. Users should see little direct change, but teams benefit from cleaner maintenance and more reliable future improvements.
Original PR description
* account_reports,helpdesk,knowledge,planning This commit adds a slot to the component TagsList and removes the tag part of its template so the component does not render tags anymore. M2m tags fields needed to be updated to support this change. The change allows these field to define their tag more easily. task-4660360
Resolved issues and error corrections
This update simplifies a styling workaround used in spreadsheet side panels. It helps keep the interface consistent while reducing overly complex rules that could make future maintenance harder.
Original PR description
Because of a really strong rule in o_spreadsheet lib that forced the box-sizing property pretty much everywhere, we came up with a super dense rule to counteract it inside odoo and specifically inside the side panels. This commits aims to simplify it at best with the common denominator of those rules. Task-4878174 Forward-Port-Of: odoo/enterprise#99240 Forward-Port-Of: odoo/enterprise#98876
Connecting a bank with payments disabled no longer creates an alarming error report. The system now treats this expected setup condition as a warning, reducing false error alerts while keeping the bank connection flow clearer for users and support teams.
Original PR description
Currently, an error occurs when a user connects a bank that has payments not enabled. **Steps to replicate:** * Install `account_online_payment` * Invoicing > Bank > dropdown menu and connect the…
Currently, an error occurs when a user connects a bank that has payments not enabled. **Steps to replicate:** * Install `account_online_payment` * Invoicing > Bank > dropdown menu and connect the demo bank. **Error:** `Non-blocking error during payment activation: To activate payments, you must first enable them when connecting a bank account.` **Root cause:** * The error happens because payment is disabled on the bank page. As `is_payment_enabled` is `False` in the `data` at [1], which comes from [2],and that `data` comes from a response in the super call at [3]. **Solution:** * Since this error comes from a `UserError`, it would be better to use logger warning instead of logger error. [1]: https://github.com/odoo/enterprise/blob/b5ff6fff193a7197b3983985c8af13512d677146/account_online_payment/models/account_online_link.py#L18 [2]: https://github.com/odoo/enterprise/blob/b5ff6fff193a7197b3983985c8af13512d677146/account_online_payment/models/account_online_link.py#L24 [3]: https://github.com/odoo/enterprise/blob/b5ff6fff193a7197b3983985c8af13512d677146/account_online_synchronization/models/account_online.py#L963-L970 sentry-6936347663 Forward-Port-Of: odoo/enterprise#99227
Odoo Sign now checks PDF files before processing them, so encrypted or unreadable documents are rejected cleanly instead of causing an error. This helps users understand when a file cannot be used and prevents interruptions when creating sign documents or templates.
Original PR description
Currently, an error occurs when trying to upload an encrypted/invalid document in the Sign Documents. **Steps to reproduce:** 1. Install **Sign** module. 2. Try to upload the encrypted PDF in Sign Document or templates. **Sample files:** https://drive.google.com/drive/folders/1MkiFRgJOlv2zc6ZW3SJYnMwHZYy9CFtX?usp=drive_link **Errors:** ``` DependencyError - PyCryptodome is required for AES algorithm UnicodeDecodeError - 'utf-8' codec can't decode byte 0xa4 in position 0: invalid start byte ``` **Cause:** The `flatten_pdf` function calls `PdfFileReader`, which raises an error if the file is encrypted or cannot be read/decrypted properly. Also, adding AES encrypted document in already uploaded valid document will triggers the same error. **Fix:** This commit prevents a traceback when uploading invalid or encrypted PDF files by validating the PDF data beforehand. sentry-6913657420 Forward-Port-Of: odoo/enterprise#96830
This fixes an intermittent issue where moving articles in the Knowledge sidebar could prevent the next selected article from opening correctly. Users should see more reliable editing behavior after reorganizing Knowledge articles.
Original PR description
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously…
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor. The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article. Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)). This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile. runbot error~182073 Forward-Port-Of: odoo/enterprise#99174
BACS payment export files now correctly round payment amounts when converting pounds to pence. This prevents rare cases where amounts such as £645.30 could be exported as one penny less, helping avoid payment discrepancies.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413 Forward-Port-Of: odoo/enterprise#99180
GSTR-1 reporting now correctly checks eligible Point of Sale lines that have a unit of measure but are missing an HSN code. This helps businesses catch missing tax classification details in warnings while still excluding older POS lines that cannot be validated reliably.
Original PR description
Previously, POS move lines from the original POS entries were not considered during the HSN validation in the GSTR-1 report. As a result, lines without an HSN code were incorrectly skipped from the warning check. This commit updates the domain logic to ensure that: - POS move lines with a Unit of Measure (UoM) but without an HSN code are now included in the check. - Older POS lines without a UoM remain excluded from validation. opw-5252620 Forward-Port-Of: odoo/enterprise#99261
This fixes an issue where selecting several bank reconciliation lines and creating a statement could start from the wrong balance. The system now keeps track of the selected lines correctly, helping ensure statement balances are accurate.
Original PR description
When selecting multiple lines and doing a statement in the list view. The balance start was wrong because the computation relies on the active_ids that wasn't correctly filled. The reason is that during the refactoring: https://github.com/odoo/enterprise/commit/2335c953723dce66af8811fdfbfd5b811d42b109 We actually remove a custom widget allowing to pass the active_ids. task-5245426 Forward-Port-Of: odoo/enterprise#99013
The journal audit report now presents tax details more clearly, especially when taxes span multiple countries or have long names. This reduces clutter and makes the report easier to read and review without changing the underlying accounting data.
Original PR description
Improve the display of the tax details in the journal audit report. A few issues were spotted: * The header of the "Taxes Applied" table was not covering the full width when there are taxes related…
Improve the display of the tax details in the journal audit report. A few issues were spotted: * The header of the "Taxes Applied" table was not covering the full width when there are taxes related to multiple countries, fixed by using the right variable in the `colspan` * When taxes have long names, which happens easily with OSS etc, they were displayed on multiple lines in the table, making the table very long. This is fixed with the new `.name` css class, wrapping the line with an ellipsis. * When there are taxes related to multiple countries, the full name of the country was used. Since the vertical space is scarce, we display the country code instead. * A lot of space was wasted with poor usage of table elements. - The sub-tables were defined inside of `td` elements with fixed `colspan`. This doesn't make sense as they have nothing to do with the headers. By using a single `td` using the full width of the table, and splitting the tables inside of a flex element, we are now more free to have tables of different width depending on the content of the sub tables - The sub tables were using `table-layout: fixed` for no apparent reason. This is forcing thin columns (i.e. the country code) to take a lot of space, and making larger (larger amounts) columns overflow.
Opening Studio on calendar views now works even when a calendar field is limited to specific user groups. This prevents an unexpected crash and lets authorized users continue editing calendar views normally.
Original PR description
Have a calendar view that has a field A. the field A has a group on it, defined either in python or in the XML. Before this commit, opening studio in the calendar view crashed, because calendar did not support yet those fields that are marked with studio_no_fetch in their attributes. After this commit, there is no crash Forward-Port-Of: odoo/enterprise#99254 Forward-Port-Of: odoo/enterprise#98903
The document sharing panel now shows the correct guidance for the “Access through link” option. This avoids confusion when users configure link-based access, helping them understand the sharing settings more accurately.
Original PR description
This commit fix the helpers for the 'Access through link' option where a condition was mistakenly depending on internal access option. Task-5222910 Forward-Port-Of: odoo/enterprise#98450
This fix prevents an error in Belgian POS certification when a pro forma request finishes after the related order has already been deleted. It helps keep the checkout flow stable by confirming the order still exists before updating it.
Original PR description
Before this commit, when trying to send a pro forma for an order that had been deleted while the pro forma call was in the queue, a JS error would occur because the callback of the call would try to access the order which was no longer existing in the frontend. This is now fixed by checking that the order is still present before accessing it in the callback. Forward-Port-Of: odoo/enterprise#99248
This change adds a regression test to ensure employees with fully flexible schedules can have overlapping absences, such as sick leave and a public holiday, without payroll work entry generation failing. It helps protect payroll reliability for attendance-based contracts by preventing a previously reported error from returning.
Original PR description
**Purpose:** Add regression test to verify that overlapping leave scenarios (sick leave + public holiday) do not cause singleton errors for fully flexible employees using attendance-based work entries. **Test Coverage:** - Fully flexible employee with no calendar assignment - Attendance-based work entry source configuration - Overlapping sick leave and public holiday scenario - Work entry generation and validation without singleton errors Related : [PR](https://github.com/odoo/odoo/pull/223448) opw-4979974 Forward-Port-Of: odoo/enterprise#97947 Forward-Port-Of: odoo/enterprise#93902
Swiss ISO 20022 payment files now avoid adding SEPA-specific details unless explicitly enabled. This helps prevent file rejections by Swiss banks that still require the older supported format, while allowing businesses to opt in when their bank supports the newer SEPA structure.
Original PR description
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after…
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt. The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix. ticket-4535542 ======================= [FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard. Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file. ticket-4535542 Forward-Port-Of: odoo/enterprise#99150 Forward-Port-Of: odoo/enterprise#98918
Folder selection lists outside the main Documents app no longer show actions such as open or rename. This avoids confusing options in settings and popup dialogs and prevents crashes when those actions are not available.
Original PR description
This cleans an initial that was done from 19.0 on, but had to account for stable requirements. Action icons (like 'Open Folder', 'Rename', etc.) were incorrectly appearing in list views outside of the main Documents app, for example, when selecting a folder in a settings menu or a popup dialog. This was confusing and caused a crash when an icon was clicked, as the required functionality was not loaded in those contexts. The fix removed the action icons from these secondary views.The icons are now correctly restricted to the main Documents list view, where they function as intended. Other views (like folder pickers) now behave as standard selection lists without errors. Task-5245425 Cleanup of Task-5166843
This update removes leftover code from a previous reconciliation model change in the accounting tools. It helps keep the system easier to maintain without changing how users work with reconciliation.
Original PR description
In the PR (odoo/enterprise#80787) the reconciliation model was refactored in order to be easier to use for users. However, some dead code was forgotten and not removed. Forward-Port-Of: odoo/enterprise#98923
Fixes an issue that could block employees from activating Stripe expense cards when their language preference was already set. This helps companies complete expense card setup without encountering an unexpected error.
Original PR description
Currently an error occurs when user tries to activate a stripe card. Steps to replicate: - Install `hr_expense_stripe_demo`, `l10n_be`, and `hr_payroll` with demo data. - Use ngrok to portforward…
Currently an error occurs when user tries to activate a stripe card. Steps to replicate: - Install `hr_expense_stripe_demo`, `l10n_be`, and `hr_payroll` with demo data. - Use ngrok to portforward localhost to the public internet and open the link. - Switch to My Belgian Company. - `Settings > Expenses > Expense Card > Agree to T&C > Save > Click Connect`. - Select `Use Test Phone Number > Use Test Code > Save For Later`. - Create a new Employee named `Test` and click `Create User` (provide an email). - Under the `Personal` tab, set the value for the `Payslip Language` field. - Go to `Expenses > Cards > New`, assign Cardholder as `Test`, and save. - Click `Activate`, fill in the required fields, and save. - The error will appear. Error: `KeyError: False` Cause: - The error occurs because line [1] attempts to remove the `False` item from the `preferred_langs` OrderedSet. - Line [1] was added as a guard to remove any `False` value from `preferred_langs`, this occurs when an employee has no language set and hence it will be assigned as False. - However, if the employee has a language selected, there is no `False` value in the `preferred_langs` set, causing line [1] to raise a `KeyError: False`. Solution: - Using the python method `discard()`, we can safely remove any False value and function wont raise any error if False is not found in the `preferred_langs` OrderedSet. [1]: https://github.com/odoo/enterprise/blob/e1d8b1316ce822055a1b42c7f5893cfd1a3dd8a5/hr_expense_stripe/wizard/hr_expense_stripe_cardholder_wizard.py#L176 sentry-6975780020 Forward-Port-Of: odoo/enterprise#98216
The Ask AI command no longer shows empty quotation marks when the command palette search field is blank. This removes a small visual glitch and makes the command label clearer for users.
Original PR description
Before, the "Ask AI" command in the command palette would always display quotes around the search term, even if the input was empty, showing "". Now, the quotes are conditionally rendered only when a search value is present, preventing empty quotes from appearing. task-[5262111](https://www.odoo.com/web#id=5262111&view_type=form&model=project.task) # Before https://github.com/user-attachments/assets/1bb98920-5ec2-48c3-9c13-1e49b8ab5ed4 # After https://github.com/user-attachments/assets/3c985951-a64c-4426-97de-1cdcdd572f0b
The Colombian currency rate update service now uses the national bank's replacement API after the old service was shut down. This helps companies continue receiving official exchange rates automatically without disruption.
Original PR description
The previous SOAP API was decommissioned. A new API was provided that doesn't need SOAP anymore and is a bit simpler [1]. [1] https://suameca.banrep.gov.co/estadisticas-economicas/webService opw-4860262 Forward-Port-Of: odoo/enterprise#99152
Code cleanup and technical improvements
The IoT Box now includes its device handlers by default instead of downloading them from the database during startup. This should make startup faster and reduce setup or connectivity issues for point of sale, payment terminal, scale, camera, and quality control hardware.
Original PR description
To speed up the IoT Box startup process and reduce the amount of potential issues, we now avoid downloading handlers from the database by providing them all by default on the IoT Box. Community PR: https://github.com/odoo/odoo/pull/221948
This update cleans and standardizes the VoIP app's code using Odoo's quality rules for Python and JavaScript. It also corrects small typos, helping keep the module easier to maintain without changing business functionality.
Original PR description
Use both the Odoo Python Ruff config and JavaScript ESLint/Prettier configs on all relevant voip files. Also fix the few existing typos.
21 changes
Enhancements to existing features
This change prevents the special Public User from being deleted, which avoids a site-wide login failure in databases that do not have the Website module installed. It also restores the user automatically when needed during Website installation, helping keep public access and the login page working reliably.
Original PR description
Steps to Reproduce: 1. Create a database without installing the Website module. 2. Navigate to archived users and delete the "Public User." 3. Attempt to log in to the database from another browser or incognito mode. 4. An internal server error occurs because the public user does not exist, making the login page inaccessible. Issue: Previously, it was possible to delete the public user, leading to an internal server error due to its absence, which prevented public access to the login page. Solution: - Implemented a restriction to prevent the deletion of the public user, similar to portal and default users. - Introduced a **pre_init_hook** to verify the existence of the public user in existing databases. If missing, the user is recreated during the Website module installation. - Added a test case to validate this functionality and ensure the public user cannot be deleted. task-4423568 Forward-Port-Of: odoo/odoo#233328 Forward-Port-Of: odoo/odoo#196918
The Belgian account tags used for form 281.50 now carry the country information. This makes them easier to organize and allows them to be reused more flexibly in other situations.
Original PR description
Account tags for 281.50 are specific to Belgium. With this PR, the country is added to those tags, allowing easier group by and enabling their use in other cases as well. task-5236632 Forward-Port-Of: odoo/enterprise#98759
Resolved issues and error corrections
Live chat windows will now only auto-open for people who are actually part of the conversation. This prevents unrelated agents from being interrupted by chats they are not responsible for, while still keeping the right people alerted when action is needed.
Original PR description
Before this commit, when live chat had new messages, all agents including non-members had auto-open of chat window when conversation is not in chat hub. This is meant to make agent active or assigned to conversation to be explicitly aware of conversation and action is needed. However non-members should not have auto-open of chat window since their are not liable. This commit fixes the issue by limiting the auto-open of chat window of livechat on new message for users that are member of conversation.
This update simplifies a complex styling rule used in the spreadsheet side panels. It keeps the interface looking correct while making the code easier to maintain and less fragile going forward.
Original PR description
Because of a really strong rule in o_spreadsheet lib that forced the box-sizing property pretty much everywhere, we came up with a super dense rule to counteract it inside odoo and specifically inside the side panels. This commits aims to simplify it at best with the common denominator of those rules. Task-4878174 Forward-Port-Of: odoo/enterprise#99240 Forward-Port-Of: odoo/enterprise#98876
This fix prevents an unnecessary error message from appearing when a user connects a bank account that does not have payments enabled. The bank connection still works as expected, but the system now handles this situation more appropriately and avoids alarming users with a non-blocking issue.
Original PR description
Currently, an error occurs when a user connects a bank that has payments not enabled. **Steps to replicate:** * Install `account_online_payment` * Invoicing > Bank > dropdown menu and connect the…
Currently, an error occurs when a user connects a bank that has payments not enabled. **Steps to replicate:** * Install `account_online_payment` * Invoicing > Bank > dropdown menu and connect the demo bank. **Error:** `Non-blocking error during payment activation: To activate payments, you must first enable them when connecting a bank account.` **Root cause:** * The error happens because payment is disabled on the bank page. As `is_payment_enabled` is `False` in the `data` at [1], which comes from [2],and that `data` comes from a response in the super call at [3]. **Solution:** * Since this error comes from a `UserError`, it would be better to use logger warning instead of logger error. [1]: https://github.com/odoo/enterprise/blob/b5ff6fff193a7197b3983985c8af13512d677146/account_online_payment/models/account_online_link.py#L18 [2]: https://github.com/odoo/enterprise/blob/b5ff6fff193a7197b3983985c8af13512d677146/account_online_payment/models/account_online_link.py#L24 [3]: https://github.com/odoo/enterprise/blob/b5ff6fff193a7197b3983985c8af13512d677146/account_online_synchronization/models/account_online.py#L963-L970 sentry-6936347663
The Discuss message list in the white theme has been visually adjusted to be easier to read. Message borders are now less distracting, and author names stand out more clearly from the message text, making conversations less tiring to scan.
Original PR description
- reduce slightly message border opacity, so that they are less distracting than message list content itself. - add more weight on message author names so they are more distinct more message text content. Harmonize weight in message reply but with reduced opacity. These changes should make using Discuss in white theme less fatiguing. Before <img width="953" height="791" alt="Screenshot 2025-11-12 at 18 29 01" src="https://github.com/user-attachments/assets/dc9f37d2-acea-44ae-99e7-e3ecdcc40a9d" /> After <img width="962" height="789" alt="Screenshot 2025-11-12 at 18 29 09" src="https://github.com/user-attachments/assets/0239f581-a344-44e1-9a84-0e7877cab047" />
Editing a message with line breaks now keeps the full original content, including the first line. This fixes a display and saving issue that could cause part of a message to disappear after edits.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/231004 Before this commit, when editing a message with at least 1 line, the 1st line was removed after edition. Steps to reproduce: - type message with…
Follow-up of https://github.com/odoo/odoo/pull/231004 Before this commit, when editing a message with at least 1 line, the 1st line was removed after edition. Steps to reproduce: - type message with line breaks: ``` line1 line2 line3 ``` - posts message - start editing of message - add "edit" in its own line in-between line1 and line2: ``` line1 edit line2 line3 ``` - save the edition => message saved has lost the 1st line. The resulting message is: ``` edit line2 line3 ``` This happens because message with line breaks are formatted with `<br/>`: ``` line1<br/>line2<br/>line3 ``` When message is edited with new content: ``` line1<br/>edit</br>line2<br/>line3 ``` The resulting content was: ``` <br/>edit</br>line2<br/>line3 ``` This happens because the html of body has no wrapped tag and consists of just text nodes joined by `<br/>`. While client-side DOM would say each `<br/>` are children (and text nodes are not), the `etree` lib that is used to parse the html has different definition of children: ``` <br/>edit # 1st child <br/>line2 # 2nd child <br/>line3 # 3rd child ``` Parsing of body as html is used to insert the "(edited)" label at the end, attempting to insert in the last children for having the label inline to text content otherwise at the end. When producing the resulting body with "(edited)" label, only the children were joined. Therefore the resulting body was produced: ``` <br/>edit</br>line2<br/>line3<span.o-mail-Message-edited/> ``` Where the `.o-mail-Message-edited` represents the "(edited)" that is rendered on template for translation and style. `line1` is missing because this is not a child: this is text content before the 1st child. This `line1` should still be present in resulting string. This commit fixes the issue by adding missing `tree.text` to the resulting message body with "(edited)" label, which is the text content that is present before the 1st child, i.e. the `line1` in example above.
This update fixes how Swiss bank transfer files are generated so they match the bank’s expected XML structure. It prevents files from being rejected by banks that do not yet support the newer payment format, while keeping the previous behavior only when explicitly enabled.
Original PR description
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after…
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt. The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix. ticket-4535542 ======================= [FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard. Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file. ticket-4535542 Forward-Port-Of: odoo/enterprise#99005 Forward-Port-Of: odoo/enterprise#98918
This update prevents the website editor from showing an error when someone presses Delete without an active text selection. It improves stability during normal editing, especially when working with embedded content like videos.
Original PR description
If the selection of the document is not set and the user presses the delete key, the delete handler of the list plugin throws an error. Steps to reproduce (in 19.0, where the issue was discovered): - Open website builder - Drop the video inner snippet in the header - Double-click & drag from the video to just outside the video - Click once on the video - Press "delete" - Bug: Traceback task-5186954 Forward-Port-Of: odoo/odoo#232643
This update corrects spreadsheet input styling so missing or invalid fields are always shown clearly. It also prevents dark mode styling from unintentionally changing the spreadsheet layout, keeping the interface consistent and easier to use.
Original PR description
Following the style revamp of the o-spreadsheet lib, we introduced a class o-input (differs from odoo o_input) in order to avoid collision with the odoo classes which tend to be altered in dark mode which spreadsheet does not support. However, we still relied on the default behaviour of odoo classes to mark specific inputs as invalid or missing. This commit ensures that missing/invalid are always marked as such while make preventing the dark mode to break the default layout. Task-4878174 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#235236 Forward-Port-Of: odoo/odoo#234517
The product markup used for search engines now follows the website’s tax display setting, so it matches the price customers see on the shop page. This avoids inconsistencies between the visible price and the structured data used by search engines.
Original PR description
## Version
18.2+
SEO Schema refactoring from task-3866937
## Issue
The markup always contains the price without taxes, no matter the website settings for pricing display (with or without taxes).
## Steps to reproduce
- Go to Website settings:
- Choose "Taxes Included" for "Display Product Prices".
- Got to the shop and select any product on which taxes apply (e.g. Customizable Desk):
- Open console and execute `JSON.parse(document.querySelectorAll('[type="application/ld+json"]')[1].innerHTML)[0]['hasVariant'][0]['offers']['price']`;
- The found price and the displayed price (visible on the page) are different
## Fix
Allow tax inclusion based on parameter to mimic template's behavior on variants too depending on the website.
https://github.com/odoo/odoo/blob/52a6d88a188d5456262428847aed229f117da8ed/addons/website_sale/models/product_template.py#L377-L430
opw-4923780
Forward-Port-Of: odoo/odoo#235106
Forward-Port-Of: odoo/odoo#225577This update fixes an issue in BACS batch files where certain payment amounts could be written with the wrong pence value because of rounding errors. It ensures the exported amount matches the actual payment, preventing incorrect bank instructions.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413 Forward-Port-Of: odoo/enterprise#99180
This change fixes the appearance of text fields shown inside image captions so they no longer display with a dark gray background. It improves visual consistency and makes captions look cleaner in the editor.
Original PR description
### Purpose of this PR: - Set the default background of inputs inside `<figcaption>` to transparent. This prevents them from appearing dark gray (rgb(59,59,59)) in caption. task-5122745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230238
This change removes an unnecessary test-only setting from a self-order payment tour. It helps avoid errors when developers run Odoo in debug mode locally, without affecting normal usage.
Original PR description
In this commit: - Removed the `test: true` flag from the `test_kiosk_cart_restore_and_cancel` tour. - The flag is not required for tours and can cause issues when running in debug mode. - This issue only occurs in local environments when debug mode is enabled. - After this fix, no issue is generated in debug mode. Forward-Port-Of: odoo/odoo#234101
The website builder’s dropdown for selecting related options now correctly shows the full set of available choices when changing a selection. This fixes a filtering issue that could hide one of the expected options, making it easier for users to edit visibility settings without confusion.
Original PR description
With the initial [website builder refactor], only 4 options appeared in the `many2x` dropdown when user try to re-select. This commit fixes the issue so the dropdown now fetches all required options through passing domain in rpc call instead of filtering after rpc call this makes sure we only fetch required data by avoiding already selected ids. Steps to Reproduce: 1. Open the website builder. 2. Drop any snippet onto the page. 3. Set the visibility option to conditionally. 4. In the UTM medium dropdown, select any social media option. 5. Try changing the selection again. 6. Only 4 options are shown. Expected: Dropdown should always display 5 options. [website builder refactor]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 Forward-Port-Of: odoo/odoo#227383
This change corrects how inventory valuation is recorded when a subcontracted product is delivered by drop shipment. It prevents the system from leaving behind stock value that could distort future cost calculations, especially for products using FIFO pricing.
Original PR description
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a…
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a remaining_value. (This also happens with 'standard price' and 'avco' but it's mostly problematic for fifo products. This being said the fix solves all 3 cases) Some context: When we confirm a SO and validate the delivery of a dropshipped (not sbc) product, two svls are created, - one with a negative quantity and value. - one with positive quantity and value. Both have a zero remaining value and remaining quantity. The outgoing svl does not trigger run_fifo or decrease the remaining_qty and remaining_value on any svl. In other words the fifo logic is not applied. If it was the case, the dropship delivery would impact the fifo valuation and other layers which we don't want as the product never really entered the stock. In the use case of this PR, a subcontracted dropshipped fifo product being delivered, the outgoing svl(s) are linked to the dropship and have the correct values. But the incoming svl is linked to the subcontract order and has a remaining value and remaining quantity which will impact the fifo logic when it shouldn't. **Steps to reproduce:** - enable the subcontracting setting and the dropshipping setting. - create a storable product, with a fifo category and positive cost. - create a subonctracted bom with a consumable component. - in the purchase tab of the product set a vendor which is the same as the subcontractor of the bom. - in the inventory tab select only the dropship route - create and confirm a SO for this product. - on the PO enter a positive unit price and confirm - validate the dropship delivery - click on the valuation smart button **Current behavior:** the stock valuation layer linked to the subcontract picking (the one with a positive quantity) has a positive remaining quantity and remaining value. **Expected behavior:** As the product is dropship remaining quantity and remaining value should be 0 **Cause of the issue:** When action_done is called on the picking: 1) In the super method, action_done is called on the move. There, _create_dropshipped_svl is called. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 Inside _get_dropshipped_svl_vals only the value for the (first) outgoing svl is returned because the location_id (subcontrating location) is valued. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L226 2) In the mrp_subcontracting override, button_mark_done is called on the mrp.production associated with the picking. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting/models/stock_picking.py#L90 Therefore action_done is called on the finished products move the mrp.production. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp/models/mrp_production.py#L1731 The move is a 'in' move so this lead to the creation of an in svl. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 The problem is that there is no mechanism to prevent the in svl from having a remaining_value and remaining_qty **fix** The mrp_subcontracting_dropshipping override of _action_done (on stock picking) is where, when needed, the other ougoing layer is created specifically in this subcontracting dropshipping use case. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L27-L32 Because the conditions are the same, imo, it's a good place to set the value of remaingin_value and remaining_qty of the incoming svl to 0. opw-5184644 Forward-Port-Of: odoo/odoo#234573 Forward-Port-Of: odoo/odoo#233041
This change corrects how attachments are linked when sending messages and emails, so files are attached to the right records more reliably. It helps prevent attachments from being filtered out incorrectly during common workflows like mail templates, invitations, and scheduled messages.
Original PR description
Description of the issue/feature this PR addresses: Because `_search` is used, we need to set the context to ignore that added search filter. Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents PDF attachments from being included in Turkish e-invoice payloads sent to Nilvera. It resolves failed submissions for invoices that were generated before being sent through the integration, improving reliability for customers using this e-invoicing format.
Original PR description
## Description of the issue/feature this PR addresses: Nilvera rejects E-Invoices if the PDF attachment of the invoice is included in the XML payload. ## Current behavior before PR: When an e-invoice XML is generated, it correctly follows the UBL 2.1 standard, which includes the PDF as an attachment. However, when the user later tries to send this XML to the Nilvera integration, the request fails because Nilvera does not expect the PDF attachment in the payload. ## Desired behavior after PR is merged: After this fix, if the Customer's e-invoice format is set to **Türkiye (UBL TR 1.2)**, the PDF attachment will be skipped during the XML generation to ensure compatibility with Nilvera. task-5169400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update stops blank badges from appearing in list views. It makes the interface cleaner and avoids confusing users with empty status indicators.
Original PR description
A condition was added in the check of listBadgeSelectionField in order to prevent the display of empty badges. task-5096109
The follow-up toggle is now shown only on invoices, where it is relevant. This avoids confusion on other document types and makes the follow-up settings clearer for users.
Original PR description
No followup makes only sense for invoices. Therefor hide the toggle on other move types.
This change prevents a timing issue in Knowledge where an article could fail to open correctly after reorganizing items in the sidebar. As a result, users should now see the expected article stay selected and displayed, making editing flows more reliable.
Original PR description
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously…
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor. The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article. Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)). This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile. runbot error~182073 Forward-Port-Of: odoo/enterprise#99174
12 changes
Enhancements to existing features
The tax tags used for Belgian reporting now include Belgium as their country. This makes them easier to organize and helps reuse them in other situations where country-specific grouping is needed.
Original PR description
Account tags for 281.50 are specific to Belgium. With this PR, the country is added to those tags, allowing easier group by and enabling their use in other cases as well. task-5236632 Forward-Port-Of: odoo/enterprise#98759
When creating a new company bank account, Odoo now preserves the expected account digit length. This prevents newly generated account numbers from becoming one digit too long, which helps keep numbering consistent and easier to read.
Original PR description
**Description of the issue/feature this PR addresses:** When user creates a new company bank account the new account created has not expected lenght when last digits are more than 1 **Current behavior before PR:** account digits = 6 last bank account = **572009** create new bank account = **5720010** **Desired behavior after PR is merged:** account digits = 6 last bank account = **572009** create new bank account = **572010** cc @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199587
Resolved issues and error corrections
This update switches the Colombian exchange rate service to the country’s new central bank API. It restores and simplifies the automatic currency rate update so businesses can keep exchange rates current without interruption.
Original PR description
The previous SOAP API was decommissioned. A new API was provided that doesn't need SOAP anymore and is a bit simpler [1]. [1] https://suameca.banrep.gov.co/estadisticas-economicas/webService opw-4860262
This update corrects a rounding issue in BACS batch exports so payment amounts are written accurately in pence. It prevents small floating-point errors from causing batches to show the wrong amount in the payment file.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413 Forward-Port-Of: odoo/enterprise#99180
When account chart templates are reloaded, translations are now updated consistently across all available languages. This avoids situations where some language versions were left outdated while English was refreshed, helping keep localized account labels aligned.
Original PR description
Before this patch: - English terms were always updated when reloading account chart templates. - Other languages were only updated if the corresponding translation was missing. After this patch: - All languages are consistently updated when reloading account chart templates. - Languages where there is no translation remain unaffected. https://www.loom.com/share/1d9367f2b25f42b7b07dc01743f7e008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-12331 OPW-5237476
The system now correctly ignores the Raspberry Pi 5’s built-in serial port, which was being shown by mistake on newer Raspberry Pi OS versions. This prevents an internal device from appearing as if it were an available serial connection, reducing confusion and setup errors.
Original PR description
The serial interface previously included a filter to not include the built-in serial port on the Pi 5, however this filter is now broken in Raspberry Pi OS Trixie. To ensure the filter works in all versions, we now explicitly look for the device `/dev/ttyAMA10` and ignore it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235074
This change corrects how payroll-related payments choose the recipient bank account. It ensures payments are sent to the bank account specified by the vendor or partner, instead of always defaulting to the employee’s bank account, which avoids payment errors and misdirected transfers.
Original PR description
## Tests ### test_bank_account_partner_payment_payslip Adding 'test_bank_account_partner_payment_payslip' test to check that the payment generated for Professionnal Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment). ### test_sepa_payslip_partner_bank_id Adding 'test_sepa_payslip_partner_bank_id' test to check that the "partner_bank_id" is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the account_register_payment wizard) doesn't raise any error. [Task#4979220](https://www.odoo.com/odoo/all-tasks/4979220) [Community#229506](https://github.com/odoo/odoo/pull/229506)
This change ensures payslip payments use the correct recipient bank account instead of always defaulting to the employee’s bank account. It also prevents an error when users click Pay from the payroll payment screen, so salary-related payments can be created and processed reliably.
Original PR description
## Issues ### Issue 1: incorrect payslip payment bank account When you perform the "pay" action of a payslip, the bank account registered within the resulting payments is always the bank account of the employee, even though some payments should be made to a different bank account (taxes). ### Issue 2: error when clicking on "Pay" in hr_payslip When a payment is created using the "Pay" button defined in the `enterprise/hr_payroll_account/views/hr_payslip_views.xml` (action `action_register_payment`), an error occurs because of the `partner_bank_id` property not being set even when the `partner_id` is set. The `partner_bank_id` returned by the `_get_line_batch_key` method of the `account_payment_register` is not set correctly when calling the method `action_register_payment` from the `hr_payslip`. ## PR Purpose Fix the issues [Task#4979220](https://www.odoo.com/odoo/all-tasks/4979220) [Enterprise#96019](https://github.com/odoo/enterprise/pull/96019)
Products that give access to a course will now be visible in the website shop again. This fixes a visibility issue that prevented customers from finding and buying course-related products, even when searching by name.
Original PR description
Currently, course-related products do not appear in the e-commerce. ### Steps to Reproduce 1. Create a product with type 'Service'. 2. Configure the product to grant access to a course. 3. Publish the product 4. Navigate to the shop as a public user. The course product does not appear, even if you search its exact name ### Cause Since fbbd0aae7b8a6bd9ef35566e712772e3170e31bd, a product's type needs to be explicitly defined as "saleable" for it to be visible on the website shop. The 'course' service tracking type was not included in this list of saleable types. opw-4995639
The OEE value shown on workcenter screens now matches the detailed report users see when they open it. This fixes a rounding issue that could cause small but confusing differences between the summary value and the report, improving trust in production metrics.
Original PR description
**Current behavior:** The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed…
**Current behavior:** The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed when actually clicking the button and looking at the report. **Expected behavior:** Same values **Steps to reproduce:** 1. Make a workcenter and a BoM with an operation performed at the workcenter 2. Use the BoM in an MO such that there is some un-productive time (e.g., recorded production duration takes longer than expected duration) * example: 0:20 expected, 1:01 actual 3. Go to the workcenter list view -> click on the created workcenter -> look at OEE smart button display value -> click on it to see report -> report values are different **Cause of the issue:** the `oee` field on the workcenter is computed with rounded intermediary `blocked_time` and `productive_time` values, the actual report uses the raw values. **Fix:** Don't use the rounded intermediary values in computing `oee`. Post-this-diff, we actually do one less `_read_group` (along with computing a more accurate field value). opw-4795463 Forward-Port-Of: odoo/odoo#218310
When adding an element to a report, the editor now keeps the cursor and selection in the right place. This makes it easier for users to continue typing or interacting with the report immediately after an insert, without unexpected focus changes.
Original PR description
On a new report, add a X2Many table in a new Report. In many cases there will be some issues with the selection as, when inserting the Element via the command of the report Editor we explicitly focus the editable of the html_editor. We need the document inside the iframe to get the focus, because our flow implied to click on some popover bound to the main window. But focusing the editable element changed the selection. So, instead, we focus the iframe's inner window, and the selection stays at the right place, and the user can immediately interact with it (by continuing typing after the insertion) task-5159482
This fix allows users to generate a debit note from an existing credit note in the Argentine localization. It removes an error that previously blocked this correction flow, making it easier to properly reverse and adjust mistaken documents.
Original PR description
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of…
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of the issue/feature this PR addresses: - In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. Steps to reproduce the error. - Install the Argentine localization - Create an invoice and post it - From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. Current behavior before PR: When creating a debit note from a credit note get an error. Desired behavior after PR is merged: We can create a debit memo from a credit note. opw-4304256 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#225501
5 changes
Resolved issues and error corrections
This fix lets managers refuse a validated time allocation even if employee leave records already exist in that period. It prevents an unnecessary error and makes it possible to correct the allocation without having to remove leaves that were linked to an earlier allocation.
Original PR description
## Issue: When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later A…
## Issue: When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later A UserError was raised asking to remove the leave even if it should be linked to the first allocation created ## Cause: The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves The leaves will be allocated to the last allocation created, so the last one can't be removed later As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation ## Steps to reproduce: - Create an initial Allocation (that should end after the next created Allocation) - Create a Leave from 22/12/2025 to 31/12/2025 - Create an Allocation including the leave period (01/12/2025 to 31/12/2025) - Validate, then Refuse opw-4900686
This update corrects how currency rates are calculated in the Uruguay EDI module. Rates are now always converted against the Uruguayan Peso (UYU), which keeps electronic invoice values consistent no matter what currency the company uses internally.
Original PR description
This PR fixes the currency rate calculation in the Uruguay EDI module to always compute the rate relative to UYU (Uruguayan Peso) regardless of the company's base currency. * Replaces the previous logic that calculated rates based on company currency with a direct UYU conversioni * Simplifies the rate calculation by removing the amount-based fallback logic * Ensures consistent UYU rate computation for all non-UYU currencies LATAM Task 1358 / Adhoc task 51716
This fix lets vendor bills and invoices with deferred amounts be reset to draft repeatedly, even when audit trail controls are active. It removes a restriction that could block normal accounting corrections after an entry had already been cancelled once.
Original PR description
Resetting a vendor bill or invoice with deferred amounts will unlink or reset all existing deferred entries. If the audit trail is enabled, some of these entries must be cancelled instead. [AccountMove.button_draft()](https://github.com/odoo/enterprise/blob/a3f461040cb3443fbcb190c28fddae7044bbd1e7/account_accountant/models/account_move.py#L80-L88) If a protected entry is already cancelled, `AccountMove._unlink_or_reverse()` will still attempt to cancel it. This prevents entries from being Reset to Draft more than once. The current commit removes this restriction. opw-5187737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes a problem in batch barcode scanning where one of the underlying steps was not being waited on properly. As a result, some scans could behave inconsistently or fail intermittently; the fix makes the process reliable again.
Original PR description
Commit bc9247d46225c696842bc7b0e3c883320231ab1b has introduced an override of the `processBarcode` method. However, it does not return nor await the super call. In particular, in the case where the super call should be done the overrides returns "undefine" rather than a promess to await and hence that call is not awaited anymore. Note: This error has been noticed from the fact that the test `test_barcode_batch_scan_lots` sometimes fails on step 29/31. runbot-233631
This fix makes purchase order and invoice line matching use the same product price precision when comparing unit prices. As a result, invoices with tiny rounding differences can still be correctly linked to their related purchase orders, avoiding missed matches during bill creation.
Original PR description
Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is…
Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is compared to the price_unit of an invoice line. However, currently the comparisons do not take into account the precision to be applied to product prices. In some cases, the invoice line price_unit differs from the price_unit in a PO line, but by less than the "Product Price" precision. With the current comparisons this leads to not matching the lines. This has prevented matching some invoices received via Peppol for at least one big customer (see Task-5213234) Steps to reproduce: - Create an XML document for an EDI UBL invoice with 2 lines; the first line has a price_unit 113.57 euros (for example) - Create a PO with a reference matching the invoice, and one PO line with a price_unit matching the price_unit of the first invoice line (113.57 euros) - Upload the XML invoice and create a bill from it; during the creation of the account.move.line, the price_unit gets a value which is slightly different from 113.57 (113.57000000000001) (due to python rounding ?) - Result: no link is established between the PO and the invoice. This fix makes sure that the "Product Price" precision is used when comparing the invoice line price_unit with a PO line price_unit. opw-5213234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr