Daily updates from Odoo
Thursday, July 30, 2026
36 changes · saas-19.2
Resolved issues and error corrections
Corrects a payroll validation mistake that could stop the Mexican payroll accounting EDI module from installing. This helps ensure payroll setup completes successfully and avoids blocking customers during module installation or upgrades.
Original PR description
[`_l10n_mx_is_curp_needed`] was called with self instead of slip. However, the method expects a payslip record from its caller, [`_compute_issues`]. This typo was introduced in:…
[`_l10n_mx_is_curp_needed`] was called with self instead of slip. However, the method expects a payslip record from its caller, [`_compute_issues`].
This typo was introduced in:
odoo/enterprise@07201466e54f28c6d295d63b908e9a65e39f4862
```py
/home/odoo/src/enterprise/saas-19.3/hr_payroll/models/hr_payslip.py(1913)_compute_issues()
-> issues = generate_issue(slip, context)
/home/odoo/src/enterprise/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py(235)_issue_mx_warnings()
-> if not slip.company_id.l10n_mx_curp and self._l10n_mx_is_curp_needed():
/home/odoo/src/enterprise/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py(322)_l10n_mx_is_curp_needed()
-> not self.company_id.partner_id.is_company
/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py(1726)__get__()
-> record.ensure_one()
> /home/odoo/src/odoo/saas-19.3/odoo/orm/models.py(5344)ensure_one()
-> raise ValueError("Expected singleton: %s" % self)
```
This causes module installation to fail with:
```py
File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 779, in convert_csv_import
raise Exception(env._(
Exception: Module loading l10n_mx_hr_payroll_account_edi failed: file l10n_mx_hr_payroll_account_edi/data/hr.employee.type.csv could not be processed:
Ocurrió un error desconocido durante la importación: <class 'ValueError'>: Expected singleton: res.partner(7, 9)
```
upg-4468049
[`_l10n_mx_is_curp_needed`]: https://github.com/odoo/enterprise/blob/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py#L235
[`_compute_issues`]: https://github.com/odoo/enterprise/blob/saas-19.3/hr_payroll/models/hr_payslip.py#L1904-L1913
Forward-Port-Of: odoo/enterprise#125623Fixes an issue in Studio reports where deleting the last character in a paragraph also removed the paragraph itself. Users can now keep empty paragraphs while editing reports, preserving layout and spacing as expected.
Original PR description
Problem: In Studio reports, deleting the last character of a paragraph removes the entire paragraph. Cause: `cleanEmptyStructuralContainers` removes the empty paragraph because it is considered empty. Solution: Disable `cleanEmptyStructuralContainers` for reports same as website builder. Steps to reproduce: - Create a new report. - Add multiple paragraphs. - Leave one paragraph with a single character. - Delete the character. - Observe that the paragraph is removed. task-6368965 Forward-Port-Of: odoo/enterprise#124834
This update adjusts internal checks for the French FEC accounting export so they match the latest naming fallback behavior. It helps keep automated validation reliable after a related accounting logic update, with no expected change for day-to-day users.
Original PR description
Adjust the FEC export test expectations to match the updated `EcritureLib` fallback logic introduced in the related community change. Related: https://github.com/odoo/odoo/pull/257242 task-5346068 Forward-Port-Of: odoo/enterprise#125684 Forward-Port-Of: odoo/enterprise#112822
Uninstalling AI Documents now also removes its leftover auto-sort rules. This prevents document uploads from triggering broken automation and logging errors after the AI Documents module has been removed.
Original PR description
Currently, an error occurs when a user uploads a document. **Steps to Reproduce:** - Install the `ai_documents` module. - Go to `Documents` and create a `folder`, or use an `existing one`. - Open the…
Currently, an error occurs when a user uploads a document.
**Steps to Reproduce:**
- Install the `ai_documents` module.
- Go to `Documents` and create a `folder`, or use an `existing one`.
- Open the `folder` > click `Actions` > `Auto-sort`, and `save`.
- Uninstall the `ai_documents` module.
- Go back to `Documents`, open the `same folder`, and `upload any document`.
- Error is logged in the `terminal`.
`ValueError: Invalid field documents.document.ai_sortable in condition ('ai_sortable', '=', True)`
When the ai_documents module is installed and the user enables Auto-sort for a folder [1], an
automation rule and its linked server action are created [2] (if they do not already exist).
Whenever a document is uploaded to that folder, the automation rule triggers the server action,
which runs the AI prompt to classify and sort the document.
However, when the ai_documents module is uninstalled, the related automation rule and server
action are not removed. As a result, uploading a document to the same folder still triggers the
automation rule. While evaluating its domain, it attempts to access the ai_sortable field, which
no longer exists because it is defined by the ai_documents module, raise the error [3].
This commit ensures that uninstalling the ai_documents module removes the related automation
rules. The linked server actions are then deleted automatically through the field's ondelete='cascade' [4].
[1]: https://github.com/odoo/enterprise/blob/c6d3efb164a23d555e30d0f0f7de3de2ef1d08d3/ai_documents/wizard/ai_documents_sort.py#L100
[2]- https://github.com/odoo/enterprise/blob/c6d3efb164a23d555e30d0f0f7de3de2ef1d08d3/ai_documents/models/documents_document.py#L313-L330
[3]- https://github.com/odoo/enterprise/blob/c6d3efb164a23d555e30d0f0f7de3de2ef1d08d3/ai_documents/models/documents_document.py#L321
[4]: https://github.com/odoo/odoo/blob/2cb2f33c871bf83c74098ada568e167aad24f2a5/addons/base_automation/models/ir_actions_server.py#L17
sentry-7607903354
Forward-Port-Of: odoo/enterprise#124488Ri.Ba. batch payment validation now accepts valid San Marino bank accounts in addition to Italian ones. This prevents eligible payments from being blocked and keeps generated payment files within the required banking format.
Original PR description
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a…
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a Batch Payment using the Ri.Ba. payment method. - Validate the Batch Payment. **_Observed behavior :_** The validation fails with the error: `Only bank accounts with an Italian IBAN are allowed to use Ri.Ba. payments` **_Cause :_** The Ri.Ba. validation logic only accepts IBANs with the IT country code and incorrectly rejects valid San Marino (SM) IBANs. **_Fix :_** - Update the Ri.Ba. IBAN validation to accept both Italian (IT) and San Marino (SM) IBANs when generating Ri.Ba. payment files. - While validating Batch Payments for SM IBANs, we observed that the extracted value could overlap with the branch code portion, causing the generated RIBA record to exceed the expected 120-character length. This change updates the extraction logic to prevent overlap and ensure compliance with the required record format. **_opw_** - 6303820 Forward-Port-Of: odoo/enterprise#125694 Forward-Port-Of: odoo/enterprise#121439
This fix prevents customers from increasing rental product quantities in the cart beyond what is actually available for the selected dates. It also rechecks availability when rental dates are changed, reducing overbooking risk for services tied to planning shifts.
Original PR description
From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning…
From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning module 2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period 3. In the General Information tab, click on the internal link to "Developer" 4. Enable Sync Shifts and Rental Orders 5. Go to the eCommerce website and search for product "test" 6. Add as much product "test" to the cart as possible (the quantity is limited) 7. Open the cart 8. You can increase the amount of the product regardless of its availability Issue: We don't check the renting availabilities to limit the maximum quantity of the product Solution: Check that the new quantity of the product is available in `_verify_updated_quantity` for the specified dates. We also need to check the availability of the product when we modify the rental dates opw-6274035 Forward-Port-Of: odoo/enterprise#125783 Forward-Port-Of: odoo/enterprise#123056
This fix stabilizes Australian payroll accounting tests by ensuring they run against a fixed date. It helps prevent false test failures when payroll reporting rules change over time, supporting more reliable releases without changing user-facing payroll behavior.
Original PR description
The new qualifying earning rule introduced was breaking the tests that were not frozen in the past as it changed over to the new reporting code. runbot-940160 related too [11736](https://github.com/odoo/enterprise/pull/117367#event-26694075694) Forward-Port-Of: odoo/enterprise#122576
The bank reconciliation report now includes all unreconciled statement lines up to the selected date, not just those from the most recent statement. This gives finance teams a complete view of pending transactions and helps avoid missed reconciliation work.
Original PR description
The reconciliation report lists only the unreconciled transactions from the last statement instead of all of them Steps: - Create 4 statements with one statement line each with different dates - Go to the reconciliation report (via the three dot menu on bank journal kanban card) - select date as Today -> only the line from the last statement is displayed opw-6250370 Forward-Port-Of: odoo/enterprise#124837 Forward-Port-Of: odoo/enterprise#119386
This fixes an automated test for Mexican point-of-sale invoicing and refunds by ensuring the original sale is fully saved before a refund begins. It helps prevent false test failures and improves confidence that the refund workflow remains reliable.
Original PR description
In this commit: =============== - Fix the `test_mx_pos_invoice_order_and_refund` tour, which fails with the warning: `The amount of the order must be positive for a sale and negative for a refund`. - The failure is caused by the refund flow starting before the original order has been fully synced with the backend. - A previous attempt to fix this in odoo/enterprise#109362 by waiting for `FeedbackScreen.isShown()` was not sufficient. Fix: ==== - Add a `Chrome.waitForOrdersSync()` waiting step to the tour to ensure the original order is fully synced before starting the refund flow. Error: 237980
Timesheet suggestions now respond correctly when users Ctrl-click them, adding the suggestion to the form instead of opening a new browser window. This prevents an unexpected navigation issue and keeps timesheet entry smoother.
Original PR description
Currently, when a user use ctrl + click on a suggestion, instead of adding it to the view form, it opens a new window. This is due to the default behavior when ctrl+click is used on a link. Using a button instead of an a href="#" solves this issue.
Ecuadorian electronic invoices using Special Consumptions (ICE) taxes can now be processed without errors. This helps businesses submit compliant invoices reliably when using non-VAT tax groups.
Original PR description
Currently, an error occurs when processing Ecuadorian EDI invoices that use taxes from the `Special Consumptions (ICE)` tax group. **Steps to reproduce:** - Install `l10n_ec_edi` and switch to an EC…
Currently, an error occurs when processing Ecuadorian EDI invoices that
use taxes from the `Special Consumptions (ICE)` tax group.
**Steps to reproduce:**
- Install `l10n_ec_edi` and switch to an EC Company.
- Create a new tax with the `Tax Group` set to `Special Consumptions (ICE)`.
- Create an invoice using this tax.
- Confirm the invoice and click `Process Now`.
**Error:**
```
File "/home/odoo/odoo/enterprise/saas-18.4/l10n_ec_edi/models/account_edi_format.py", line 373, in _l10n_ec_get_base_lines
code_percentage = L10N_EC_VAT_SUBTAXES[tax_data['tax'].tax_group_id.l10n_ec_type]
KeyError: 'ice'
```
**Root Cause:**
At [1], non-VAT tax groups such as `ICE` are explicitly not supported
and are not included in `L10N_EC_VAT_SUBTAXES`.
At [2], the code assumes that every Ecuadorian tax group exists in
`L10N_EC_VAT_SUBTAXES` and directly indexes the mapping using
`tax_group_id.l10n_ec_type`. When an invoice uses an `ICE`
tax, causing an error.
**Fix:**
This commit prevents errors by using the tax's `Code ATS` as the
`codigoPorcentaje` value and the tax's `amount` as the `tarifa` in
the XML when the tax group is not present in `L10N_EC_VAT_SUBTAXES`.
(Confirm with the PO [here], just to fix it from 18.4, that the problem is
that it is not working on the versions where we already introduced the feature.)
[1]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_move.py#L17-L38
[2]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_edi_format.py#L372-L377
[here]:
https://www.odoo.com/mail/message/1121493378
opw-6373984
opw-6430589
opw-6423812
Forward-Port-Of: odoo/enterprise#123918Fixed an issue where the online payment status could show outdated information when users moved between batch payment records. This helps users see the correct signing or initiation status for each payment batch without needing to refresh manually.
Original PR description
To display the `payment_online_status` field, we use a widget called `account_online_payment_refresh_button`. The issue is that the widget don't update the field value when switching from one record to another. Steps to reproduce: 1. Create 2 batch payments 2. Do a payment initiation with the first one, and sign it 3. Do another payment initiation with the second one, but don't sign it. 4. Open 1 batch, and try to switch records with the pager 5. You should see the value is not updated task-6420585 Forward-Port-Of: odoo/enterprise#126105 Forward-Port-Of: odoo/enterprise#125643
Swiss payroll declarations now avoid sending the pension fund number when checking BVG-LPP status. This prevents incorrect status requests and helps keep Swiss pension reporting aligned with expected requirements.
Original PR description
Forward-Port-Of: odoo/enterprise#126040
This fixes an error that could occur when users proposed adding a step from the Shop Floor improvement flow for manufacturing orders with very similar operations. The change helps Product Lifecycle Management users submit improvement suggestions reliably, even when operations share the same name, work center, and variant setup.
Original PR description
[FIX] mrp_workorder_plm: avoid singleton traceback when matching BOM operations **Issue** Adding a step in a manufacturing order with two operations that are too similar could lead to a traceback…
[FIX] mrp_workorder_plm: avoid singleton traceback when matching BOM operations **Issue** Adding a step in a manufacturing order with two operations that are too similar could lead to a traceback when proposing an improvement from the Shop Floor. **Steps to reproduce** - Install the Product Lifecycle Management app. - Create a BOM for any product with two operations that: - Have the same name and work center - Have no variant - Create and confirm a Manufacturing Order for that product. - Open the Shop Floor view. - Click the gear icon -> Update Instructions -> Improvement Suggestion -> Add a Step -> Propose a Change. -> A traceback occurs **Cause** When adding a step: https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L10 It tries to find the corresponding operation in the ECO's new BoM. This relies on `_get_sync_values()`: https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_plm/models/mrp_routing.py#L9-L13 Because two operations share the same name, work center, and no variant, both match the filter: https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L39 This results in a singleton error when accessing `operation.id`: https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L42 opw-6241880 Forward-Port-Of: odoo/enterprise#123673 Forward-Port-Of: odoo/enterprise#119404
Issue caused because of https://github.com/odoo/odoo/commit/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd Steps to reproduce- Create db with demo and install l10n_in Create a new company for India (other than IN Company) Go to Settings -> Accounting/Invoice Tab -> Enable Ewaybill traceback ```py Traceback (most recent call last): File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5385, in ensure_one _id, = self._ids ^^^^ ValueError: not enough values to unpack (expected
Original PR description
Issue caused because of https://github.com/odoo/odoo/commit/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd Steps to reproduce- Create db with demo and install l10n_in Create a new company for India (other…
Issue caused because of https://github.com/odoo/odoo/commit/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd Steps to reproduce-
Create db with demo and install l10n_in
Create a new company for India (other than IN Company) Go to Settings -> Accounting/Invoice Tab -> Enable Ewaybill
traceback
```py
Traceback (most recent call last):
File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5385, in ensure_one
_id, = self._ids
^^^^
ValueError: not enough values to unpack (expected 1, got 0)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/odoo18/community/odoo/http/router.py", line 273, in __call__
response = serve_db(request)
^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/http/router.py", line 380, in serve_db
registry = Registry(request.db)
^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 105, in __new__
return cls.new(db_name)
^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 217, in new
cr.rollback()
File "/home/odoo/odoo18/community/odoo/sql_db.py", line 568, in rollback
with rollbacking:
File "/home/odoo/.pyenv/versions/3.12.0/lib/python3.12/contextlib.py", line 144, in __exit__
next(self.gen)
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1004, in rollbacking
self.restore_state()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1067, in restore_state
self.reset()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 912, in reset
self._reset_registry_change()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 832, in _reset_registry_change
registry._setup_models__(cr)
File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 422, in _setup_models__
env.invalidate_all()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 395, in invalidate_all
self.flush_all()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 413, in flush_all
self._recompute_all()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 406, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/odoo18/community/odoo/orm/models.py", line 6462, in _recompute_field
field.recompute(records)
File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2042, in recompute
apply_except_missing(self.compute_value, recs)
File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2012, in apply_except_missing
func(records)
File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2066, in compute_value
records._compute_field_value(self)
File "/home/odoo/odoo18/community/addons/mail/models/mail_thread.py", line 498, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/orm/models.py", line 4387, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 82, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 228, in _compute_document_partners_details
seller_buyer_details = ewaybill._get_seller_buyer_details()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 185, in _get_seller_buyer_details
return move._get_l10n_in_seller_buyer_party()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/addons/l10n_in/models/account_invoice.py", line 629, in _get_l10n_in_seller_buyer_party
self.ensure_one()
File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5388, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move()
```
In this commit, we resolve the above traceback
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#276216To improve compliance with French requirements for FEC exports. Now we avoid exporting empty or placeholder labels ('/') by improving the fallback logic for EcritureLib. So now we, - Use existing line label when valid - For receivable/payable lines, fallback to 'partner - reference' - Otherwise fallback to move reference or name - Replace '/' with 'Balance initiale' for opening entries Related: https://github.com/odoo/enterprise/pull/112822 task-5346068 Forward-Port-Of: odoo/odoo#2786
Original PR description
To improve compliance with French requirements for FEC exports. Now we avoid exporting empty or placeholder labels ('/') by improving the fallback logic for EcritureLib. So now we,
- Use existing line label when valid
- For receivable/payable lines, fallback to 'partner - reference'
- Otherwise fallback to move reference or name
- Replace '/' with 'Balance initiale' for opening entries
Related: https://github.com/odoo/enterprise/pull/112822
task-5346068
Forward-Port-Of: odoo/odoo#278644
Forward-Port-Of: odoo/odoo#257242Currently, an error occurs when installing the hr_holidays_attendance module. **Steps to Reproduce:** - Install the `hr_attendance` module without demo data. - Go to `Attendance` > `Configuration` > `Overtime Rulesets` and open the `Default Ruleset` record. - Delete its `linked overtime rules`. - Install the `hr_holidays_attendance` module. **Error:** ```py Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule' odoo.tools.conver
Original PR description
Currently, an error occurs when installing the hr_holidays_attendance module. **Steps to Reproduce:** - Install the `hr_attendance` module without demo data. - Go to `Attendance` > `Configuration` >…
Currently, an error occurs when installing the hr_holidays_attendance module.
**Steps to Reproduce:**
- Install the `hr_attendance` module without demo data.
- Go to `Attendance` > `Configuration` > `Overtime Rulesets` and open the `Default Ruleset` record.
- Delete its `linked overtime rules`.
- Install the `hr_holidays_attendance` module.
**Error:**
```py
Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule'
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo18/community/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml:7, somewhere inside <record id="hr_attendance.hr_attendance_overtime_employee_schedule_rule" model="hr.attendance.overtime.rule">
<field name="compensable_as_leave" eval="True"/>
</record>
```
This error occurs when the user deletes all overtime rules and then installs the hr_holidays_attendance
module. During installation, the module attempts to update the deleted overtime rule records,
which raises an error [1].
This commit uses forcecreate="0" to skip updating records if the corresponding overtime
rules do not exist.
[1]- https://github.com/odoo/odoo/blob/da0a83761f38ee4a2940015b6c8f7190c310a4a0/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml#L7-L12
sentry-7372074675
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#277656hash_sign has become very used all over the place, so more and more tokens depend on `database.secret`, increasing the impact of that secret needing one day to be rotated or being compromised. To avoid making `database.secret` a single point of failure, we would like `hash_sign` to support a custom secret supplied by caller. task-6391264 Forward-Port-Of: odoo/odoo#277348 Forward-Port-Of: odoo/odoo#276474
Original PR description
hash_sign has become very used all over the place, so more and more tokens depend on `database.secret`, increasing the impact of that secret needing one day to be rotated or being compromised. To avoid making `database.secret` a single point of failure, we would like `hash_sign` to support a custom secret supplied by caller. task-6391264 Forward-Port-Of: odoo/odoo#277348 Forward-Port-Of: odoo/odoo#276474
Version: -------- - 19.0+ Steps to reproduce: ------------------- - Install `mrp` module - Go to the setting enable `Lots & Serial Numbers` and `Storage Locations` - Create a storable product tracked by Lots - Configure a Putaway Rule for the product so it is stored in a sub-location - Create a Bill of Materials for the product with at least one component - Create and confirm a Manufacturing Order - Increase the production quantity (e.g. using the "Change Production Quantit
Original PR description
Version: -------- - 19.0+ Steps to reproduce: ------------------- - Install `mrp` module - Go to the setting enable `Lots & Serial Numbers` and `Storage Locations` - Create a storable product tracked…
Version:
--------
- 19.0+
Steps to reproduce:
-------------------
- Install `mrp` module
- Go to the setting enable `Lots & Serial Numbers` and `Storage Locations`
- Create a storable product tracked by Lots
- Configure a Putaway Rule for the product so it is stored in a
sub-location
- Create a Bill of Materials for the product with at least one
component
- Create and confirm a Manufacturing Order
- Increase the production quantity (e.g. using the "Change Production
Quantity" wizard)
- Click **Generate Lot/Serial Number**
- Click **Produce All**
Issue:
------
Completing the Manufacturing Order raises:
Invalid Operation
You need to supply a Lot/Serial Number for product:
- Product
even though a single lot should be sufficient for a lot-tracked
product.
Cause:
------
When the production quantity is increased, `change_prod_qty()` updates
the finished move's demanded quantity and re-reserves it through
`_update_finished_moves()`:
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/wizard/change_production_qty.py#L77
which calls `_action_assign()` on the finished move:
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/wizard/change_production_qty.py#L49
Since finished moves originate from the production location, they
bypass the normal reservation flow:
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2070
`_action_assign()` then tries to reuse the move's existing move line,
but the lookup requires `location_dest_id` to still match the move's
generic destination:
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2092-L2106
That existing line's `location_dest_id` was already redirected to the
putaway sub-location by the previous `_apply_putaway_strategy()` call
(at MO confirmation), so the lookup no longer matches and a second,
distinct move line is created and appended instead of the first one
being reused:
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2170
Later, clicking **Generate Lot/Serial Number** creates a single lot and
stores it on the production order's `lot_producing_ids`:
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L1602
When **Produce All** is clicked, which trigger `button_mark_done()` it calls
`_post_inventory()`:
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L2227
which assigns that lot to the finished move through `move.lot_ids`:
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L1925
Since `lot_ids` is declared with `inverse='_set_lot_ids'`, this write
triggers that inverse method:
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L192
The current implementation of `_set_lot_ids()` only assigns the lot to
a single available move line, regardless of tracking type:
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L656-L668
Since only one lot is ever generated for a lot-tracked product, only
the first finished move line receives a `lot_id`. The second move line
created after increasing the production quantity is left without one.
When `button_mark_done()` validates the finished move lines, it
detects that one of them still has no lot assigned and raises the
"Invalid Operation" error, even though a single lot is valid for the
entire production of a lot-tracked product.
Fix:
----
`action_generate_serial` produces a single lot for the whole production.
In `_post_inventory()`, right after the generated lot is set on
the finished move, propagate it to any remaining lot-less move lines
of a **lot**-tracked finished move.
---
opw-6366060
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#275000Issue: If a product has a pricelist that updates on quantity and in quotation preview the customer changes the quantity the unit price doesn't update. Steps to reproduce: Create a product with price list that change depending on quantity. In a new quotation create a section and set it to optional. Add your product under this new section, and enter preview. Notice that if you change the quantity so that a different pricelist would apply the unit price still does not change. Cause: The va
Original PR description
Issue: If a product has a pricelist that updates on quantity and in quotation preview the customer changes the quantity the unit price doesn't update. Steps to reproduce: Create a product with price list that change depending on quantity. In a new quotation create a section and set it to optional. Add your product under this new section, and enter preview. Notice that if you change the quantity so that a different pricelist would apply the unit price still does not change. Cause: The value for unit price was not getting updated. Fix: After changing quantities update the price unit if there are active pricelists. As not all customers might want this change, it also checks for `sale.disable_sale_update`, so that the user can choose whether to update or not. opw-6377679 Forward-Port-Of: odoo/odoo#278802 Forward-Port-Of: odoo/odoo#275868
**Current behavior before PR:** Steps to reproduce the issue: - Go to a To-Do. - Insert a heading, write something. - Insert a table of content. - Make sure that editable is not scrollable. Clicking on heading label inside toc leads to traceback. The issue occurs after merging commit [1]. When editable is not scrollable then `closestScrollableY` returns null which leads to traceback. **Desired behavior after PR:** If editable is not scrollable then clicking on heading inside to
Original PR description
**Current behavior before PR:** Steps to reproduce the issue: - Go to a To-Do. - Insert a heading, write something. - Insert a table of content. - Make sure that editable is not scrollable. Clicking on heading label inside toc leads to traceback. The issue occurs after merging commit [1]. When editable is not scrollable then `closestScrollableY` returns null which leads to traceback. **Desired behavior after PR:** If editable is not scrollable then clicking on heading inside toc should hightlight the corresponding heading without traceback. [1]: https://github.com/odoo/odoo/commit/f5cf8565e7d09edd3a29fd95537381fb70d75785 task-6405894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277657
**Issue** A traceback is raised when creating a batch if the batch sequence prefix does not contain the expected '/' separator. **Steps to reproduce** - Go to settings > technical > sequences & identifiers > sequence: - batch transfer: - prefix: BATCH- - Create a new batch: - operation type: delivery orders - Try to save -> a traceback is triggered: ```ValueError: not enough values to unpack (expected 2, got 1)``` **Cause** `_prepare_name()` assumes that the sequence
Original PR description
**Issue**
A traceback is raised when creating a batch if the batch sequence prefix does not contain the expected '/' separator.
**Steps to reproduce**
- Go to settings > technical > sequences & identifiers > sequence:
- batch transfer: - prefix: BATCH-
- Create a new batch:
- operation type: delivery orders
- Try to save -> a traceback is triggered:
```ValueError: not enough values to unpack (expected 2, got 1)```
**Cause**
`_prepare_name()` assumes that the sequence returned by
`next_by_code()` contains a '/' separator and directly unpacks the
result of `rsplit('/', 1)`.
When no '/' is present, `rsplit()` returns a list containing a single
element, causing the unpacking to fail.
https://github.com/odoo/odoo/blob/18407651d2912b7d30463ec72cd379177530ef4f/addons/stock_picking_batch/models/stock_picking_batch.py#L418-L419
opw-6304270
Forward-Port-Of: odoo/odoo#277281
Forward-Port-Of: odoo/odoo#272212Problem: Clicking an image padding option in Studio reports closes the dropdown, but the selected option is not applied. Cause: When editing inside an `iframe`, `unFocusEditable` is triggered on `focusin`, which runs `selection_leave_handlers` and closes the dropdown before the `click` event can propagate. Solution: Add `data-prevent-closing-overlay="true"` to the image padding dropdown, as done for other dropdowns, so it remains open until the click event is handled. Steps to reprod
Original PR description
Problem: Clicking an image padding option in Studio reports closes the dropdown, but the selected option is not applied. Cause: When editing inside an `iframe`, `unFocusEditable` is triggered on `focusin`, which runs `selection_leave_handlers` and closes the dropdown before the `click` event can propagate. Solution: Add `data-prevent-closing-overlay="true"` to the image padding dropdown, as done for other dropdowns, so it remains open until the click event is handled. Steps to reproduce: - Open a new report. - Add an image. - Select the image. - Open the padding dropdown. - Click a padding option. - Observe that the dropdown closes but the padding is not applied. task-6368964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276448
Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0: Internal compiler error #12345: error mmapping datablock to 30283637 Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubl
Original PR description
Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0: Internal compiler error #12345: error mmapping datablock to 30283637 Root cause: the…
Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0:
Internal compiler error #12345: error mmapping datablock to 30283637
Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubles the size of the final installer, which is not acceptable.
The chosen fix is to pre-bundle all `.po` files into a single solid 7z archive and extract it at install time using the `Nsis7z` plugin. This keeps the NSIS datablock well below the and yields comparable or better final installer size than the previous approach, along with faster build times.
While at it, this commit also modernizes the Windows build environment to unblock a separate wine-devel install regression that has been affecting Odoo 17.0 nightlies on Debian Bookworm.
Changes:
- Bundle `.po` files into `i18n_bundle.7z` inside the build container prior to invoking makensis; extract it at install time via the `Nsis7z` plugin.
- Bump the base image from Debian Bookworm to Trixie.
- Switch from `wine-devel` to `wine-stable`, which resolves the install regression on Bookworm-based builds.
- Upgrade NSIS to the latest release.
- Refactor the NSIS installation step to remove the hardcoded version from `package.py`.
This fix is made in Odoo 17.0 to unblock the wine-devel issue there and to benefit from the smaller installer size on supported stable branches.
Forward-Port-Of: odoo/odoo#278681
Forward-Port-Of: odoo/odoo#278378The test "show pulse effect on fullscreen mode only when another participant's camera is on" fails from time to time on runbot: the pulse never lands on the fullscreen button. The first rtc session of a channel posts a call notification message, whose new_message notification fetches channels_as_member. That response carries the rtc sessions with their server values, so when it lands after the mock remote turned the camera on, is_camera_on goes back to false. videoCountNotSelf drops to 0 and
Original PR description
The test "show pulse effect on fullscreen mode only when another participant's camera is on" fails from time to time on runbot: the pulse never lands on the fullscreen button. The first rtc session of a channel posts a call notification message, whose new_message notification fetches channels_as_member. That response carries the rtc sessions with their server values, so when it lands after the mock remote turned the camera on, is_camera_on goes back to false. videoCountNotSelf drops to 0 and its onUpdate sets promoteFullscreen to INACTIVE for good, as only a change of the count sets it back to ACTIVE. A real participant also stores is_camera_on on the server, so a fetch never brings outdated values back. Make the mock remote do the same. https://runbot.odoo.com/odoo/error/242050
Steps: - Install portal app - Go to my/addresses page. - Update main address of current user. Issues: - `Main Address` badge is not visible on main address. - Editing main address is not opening `my/account` page. Cause: - Since PR https://github.com/odoo/odoo/pull/232539 t-call syntax changed and expect to add attribute directly instead t-set but forget to adept it for `is_user_address` and `address_update_url`. Fix: - Move those variable directly into t-call instead t-set.
Original PR description
Steps: - Install portal app - Go to my/addresses page. - Update main address of current user. Issues: - `Main Address` badge is not visible on main address. - Editing main address is not opening `my/account` page. Cause: - Since PR https://github.com/odoo/odoo/pull/232539 t-call syntax changed and expect to add attribute directly instead t-set but forget to adept it for `is_user_address` and `address_update_url`. Fix: - Move those variable directly into t-call instead t-set.
No description available.
Reading the `display_name` of a working schedule line of a 2 weeks calendar crashes: the compute reads `record.weektype` while the field is named `week_type`. ### Steps to reproduce - Switch a working schedule to a 2 weeks calendar. - Open one of its lines in a form view, e.g. with the `View Button` optional column in developer mode. opw-6427314
Original PR description
Reading the `display_name` of a working schedule line of a 2 weeks calendar crashes: the compute reads `record.weektype` while the field is named `week_type`. ### Steps to reproduce - Switch a working schedule to a 2 weeks calendar. - Open one of its lines in a form view, e.g. with the `View Button` optional column in developer mode. opw-6427314
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7914fd5173 [REL] 19.2.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/71271b3bf4 [FIX] ui_sheet: `getCellWidth` getter for non-active sheet [Task: 6409426](https://www.odoo.com/odoo/2328/tasks/6409426) https://github.com/odoo/o-spreadsheet/commit/4db1721557 [FIX] pivot: prevent drag & drop in pivot side panel [Task: 6268403](https://www.odoo.com/odoo/2328/tasks/6268
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7914fd5173 [REL] 19.2.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7914fd5173 [REL] 19.2.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/71271b3bf4 [FIX] ui_sheet: `getCellWidth` getter for non-active sheet [Task: 6409426](https://www.odoo.com/odoo/2328/tasks/6409426) https://github.com/odoo/o-spreadsheet/commit/4db1721557 [FIX] pivot: prevent drag & drop in pivot side panel [Task: 6268403](https://www.odoo.com/odoo/2328/tasks/6268403) https://github.com/odoo/o-spreadsheet/commit/8ec91c94d4 [FIX] dashboard: clickable cell is not triggered by a right click [Task: 6365823](https://www.odoo.com/odoo/2328/tasks/6365823) 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>
Current behavior before PR ----- The "unit cost" footer line was showing up on each page of the bom overview, overlapping with other lines. Desired behavior after PR is merged ----- The "unit cost" footer line should only appear at the bottom of the overview.
Original PR description
Current behavior before PR ----- The "unit cost" footer line was showing up on each page of the bom overview, overlapping with other lines. Desired behavior after PR is merged ----- The "unit cost" footer line should only appear at the bottom of the overview.
**Steps to reproduce:** * Install the **Accounting** module. * Open a **Bank Journal** and go to the **Inbound Payment Methods** tab. * Add the **Manual** payment method multiple times and give each payment method line a different name. * Go to **Customers → Payments** and create a payment using any of these payment method lines. * Print the **Payment Receipt** from the gear menu. **Observed behavior:** * The receipt always displays the **Manual** payment method name. * The custom name
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Open a **Bank Journal** and go to the **Inbound Payment Methods** tab. * Add the **Manual** payment method multiple times and give each…
**Steps to reproduce:** * Install the **Accounting** module. * Open a **Bank Journal** and go to the **Inbound Payment Methods** tab. * Add the **Manual** payment method multiple times and give each payment method line a different name. * Go to **Customers → Payments** and create a payment using any of these payment method lines. * Print the **Payment Receipt** from the gear menu. **Observed behavior:** * The receipt always displays the **Manual** payment method name. * The custom name configured on the selected payment method line is ignored. **Cause:** * The report retrieves the payment method name from `account.payment.method`. * However, the displayed name is configured on `account.payment.method.line`, so the report always shows the generic payment method name. **Fix:** * Read the payment method name from the selected `account.payment.method.line`. * The payment receipt now displays the configured payment method line name. opw-6395829 Forward-Port-Of: odoo/odoo#277104
odoo/odoo#155588 was a workaround to the lack of location permissions in the iOS app, skipping geolocation entirely for check in/out. Since odoo/mobile#118 added support for them, we can now revert that fix so iOS users get prompted for their location again. task-6279460 Forward-Port-Of: odoo/odoo#278685 Forward-Port-Of: odoo/odoo#276934
Original PR description
odoo/odoo#155588 was a workaround to the lack of location permissions in the iOS app, skipping geolocation entirely for check in/out. Since odoo/mobile#118 added support for them, we can now revert that fix so iOS users get prompted for their location again. task-6279460 Forward-Port-Of: odoo/odoo#278685 Forward-Port-Of: odoo/odoo#276934
Follow-up to #247929, which limited `forever` recurrences to a 15-year horizon (`calendar.max_recurrence_years`) for *yearly* and *monthly* frequencies but left *weekly* and *daily* on the hard cap `MAX_RECURRENT_EVENT` (720), ignoring the parameter. A weekly `forever` event therefore always materializes 720 occurrences (~14 years) regardless of `calendar.max_recurrence_years`, and a daily one ignores the parameter too. This applies the year limit to weekly and daily as well, accounting for th
Original PR description
Follow-up to #247929, which limited `forever` recurrences to a 15-year horizon (`calendar.max_recurrence_years`) for *yearly* and *monthly* frequencies but left *weekly* and *daily* on the hard cap `MAX_RECURRENT_EVENT` (720), ignoring the parameter. A weekly `forever` event therefore always materializes 720 occurrences (~14 years) regardless of `calendar.max_recurrence_years`, and a daily one ignores the parameter too. This applies the year limit to weekly and daily as well, accounting for the number of selected weekdays and the interval, while still capping at `MAX_RECURRENT_EVENT`. Steps to reproduce: 1. Set `calendar.max_recurrence_years` to e.g. 2. 2. Create a weekly event repeating "forever". 3. Before: 720 occurrences (~14 years). After: ~106 (2 years). task / context: extends #247929. Forward-Port-Of: odoo/odoo#272615 Forward-Port-Of: odoo/odoo#270348
The discuss action's breadcrumb name is set asynchronously: a useEffect on the current thread's displayName calls setDisplayName after the OWL render. The tour clicked "Starred messages" then immediately clicked "View or join channels" (a sidebar category action that is always present, so there was no implicit wait). Under runbot load the starred render and its effect lagged, so the action was restored with the stale "Inbox" breadcrumb name and the ".breadcrumb-item:contains('Starred messages')"
Original PR description
The discuss action's breadcrumb name is set asynchronously: a useEffect on the current thread's displayName calls setDisplayName after the OWL render. The tour clicked "Starred messages" then immediately clicked "View or join channels" (a sidebar category action that is always present, so there was no implicit wait). Under runbot load the starred render and its effect lagged, so the action was restored with the stale "Inbox" breadcrumb name and the ".breadcrumb-item:contains('Starred messages')" step timed out.
This is a test-timing artifact: a real user always sees the starred view render before navigating away, so the breadcrumb is correct for them.
Wait for the starred thread to be displayed before opening the channels list, and assert the channels view opened via its "Public Channels" breadcrumb. Also use :text instead of :contains for the text selectors.
https://runbot.odoo.com/odoo/error/242893
Forward-Port-Of: odoo/odoo#278909**Steps to reproduce:** 1. Enable debug mode and add a snippet. 2. Add a YouTube video with options like autoplay enabled. 3. Double click the video or use "Replace Media". 4. A traceback occurs while reopening the video options. **Root Cause:** When the media dialog is reopened on an existing video, `syncOptionsWithUrl()` derives each switch option's value from the URL: `value = this.state.urlInput.includes(urlParameter)`, which stores Boolean `true` when e.g. autoplay is enabled.
Original PR description
**Steps to reproduce:** 1. Enable debug mode and add a snippet. 2. Add a YouTube video with options like autoplay enabled. 3. Double click the video or use "Replace Media". 4. A traceback occurs…
**Steps to reproduce:**
1. Enable debug mode and add a snippet.
2. Add a YouTube video with options like autoplay enabled.
3. Double click the video or use "Replace Media".
4. A traceback occurs while reopening the video options.
**Root Cause:**
When the media dialog is reopened on an existing video,
`syncOptionsWithUrl()` derives each switch option's value from the URL:
`value = this.state.urlInput.includes(urlParameter)`, which stores
Boolean `true` when e.g. autoplay is enabled. Similarly, toggling an
enabled option off stores Boolean `false`
The `value` prop was already `Boolean` but after commit https://github.com/odoo/odoo/commit/ae894892e048b
we declared the prop as `value: { type: String, optional: true }` on
`VideoOption`. In debug mode, OWL validates props and throws
"Invalid props for component 'VideoOption': 'value' is not a string"
when it receives those booleans. The declaration does not match the
values the component actually receives.
**Fix:**
Normalizing the state to strings at the source would require rewriting
the option-state logic for no behavioral gain. Since booleans are
produced deliberately by two code paths, the honest prop type for value
is `[String, Boolean]`.
task-6233423
Forward-Port-Of: odoo/odoo#266304Miscellaneous changes
Backport of #275640 Despite resolving the conflicts (file moved) this version also checks the python version since PyUnstable_Type_AssignVersionTag does not exists in python 3.10 To be safer, the whole logic is skipped if python < 3.13 Forward-Port-Of: odoo/odoo#277697
Original PR description
Backport of #275640 Despite resolving the conflicts (file moved) this version also checks the python version since PyUnstable_Type_AssignVersionTag does not exists in python 3.10 To be safer, the whole logic is skipped if python < 3.13 Forward-Port-Of: odoo/odoo#277697