Wednesday, February 25, 2026
9 changes · 19.0
Resolved issues and error corrections
This update resolves an issue where helpdesk users with limited access were unable to view tickets due to a restriction in accessing related stock records. The fix adds a necessary permission group, allowing helpdesk users to correctly read ticket information and access associated products. This ensures all helpdesk users can efficiently manage tickets.
Original PR description
To reproduce: ============= - install helpdesk_stock - with user having only User rights on helpdesk and nothing on other modules - try to access a ticket -> AccessError Problem: ======== when reading the ticket, the field `suitable_product_ids` is computed, and it requires read access to records the user doesn't have access to, which raises an AccessError. Solution: ========= Add the group `stock.group_stock_user` to the field, so that only users having access can read it. backport of https://github.com/odoo/enterprise/pull/59605 opw-5907657 Forward-Port-Of: odoo/enterprise#108139 Forward-Port-Of: odoo/enterprise#107291
This update resolves an issue where the payroll data update process would fail when the 'Standard 40 hours/week' working schedule was deleted. The fix ensures the system correctly handles the absence of this schedule, preventing errors and maintaining accurate payroll calculations for supported countries. This ensures consistent payroll processing across multiple regions.
Original PR description
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us When the ``Standard 40 hours/week`` working schedule is deleted and the ``Payroll: Update data`` cron runs, a traceback is raised. For…
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us
When the ``Standard 40 hours/week`` working schedule is deleted
and the ``Payroll: Update data`` cron runs, a traceback is raised.
For ``l10n_us_hr_payroll`` module
Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Standard 40 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron
Traceback:
```py
ValueError: External ID not found in the system: resource.resource_calendar_std
ParseError: while parsing /home/odoo/src/enterprise/l10n_us_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="structure_type_employee_us" model="hr.payroll.structure.type">
<field name="name">United States: Employee</field>
<field name="default_resource_calendar_id" ref="resource.resource_calendar_std"/>
<field name="country_id" ref="base.us"/>
</record>
```
The ``Payroll: Update data`` cron updates payroll data that references
the ``Standard 40 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists,
leading to the above traceback.
sentry-7166574553This update resolves an error that occurred when computing payslips with salary rules that used hidden input fields. The issue stemmed from how the system tracked folded input sections, leading to a data type mismatch. This fix ensures that these hidden inputs are correctly ignored during payslip calculations, preventing errors and ensuring accurate payroll processing.
Original PR description
**Steps to reproduce** - Have a salary rule - Condition based on: Salary Input - Input on: Employee - On the employee form, click on "Add inputs" in the Payroll tab - Add an input - Enter a value - Click on "Inputs" to fold the section and hide the input - Try to compute a new payslip for this employee, error: `ValueError: invalid literal for int() with base 10: 'separator_1'` **Cause** By default, the separator doesn't have a `value` key, but after the first interaction to hide its elements, it is added to keep track of the folded state (see `_toggleSeparators` in `web`). **Solution** Ensure separators are ignored. opw-5928247
This update corrects a technical issue causing duplicate receipts to be printed for point of sale transactions. The problem stemmed from a system error triggered by a specific browser interaction, leading to unnecessary receipt confirmations. This fix ensures accurate and consistent receipt generation for all transactions.
Original PR description
This PR fixes two same worldline receipts appearing on the point of sale ticket Reproduced by blocking the action url in browser but not the event one. Websocket fallback action is sent and the confirmation is sent both to the longpolling and websocket, resulting in _setCardAndReceipt method being called twice.
This update resolves an issue where the SRI payment method wasn't correctly applied to invoices for POS orders paid entirely with gift cards in Ecuador. The fix automatically sets the SRI payment method (code '01') when no other payments are associated with the order, ensuring accurate invoice generation and compliance. This prevents errors and improves the user experience for Ecuadorian POS operations.
Original PR description
When a POS order has no payment associated (e.g. when the order is fully paid with a gift card), the SRI payment method was not set on the invoice Steps to reproduce: ------------------- * Create a PoS in Ecuador with the l10n_ec_edi_pos module installed * Create a gift card program and some gift cards * Create a PoS order and pay it fully with a gift card and invoice it > Observation: You get an error saying that the SRI payment method is required Why the fix: ------------ When setting the SRI payment method on the invoice, we check if there are more than 1 payment associated with the order, and if not we fallback on the SRI payment with code "01" opw-5432004
This update addresses a long-overdue refresh of tax codes within the Avatax module, ensuring continued accuracy for sales and accounting calculations. The change is a routine maintenance fix to maintain compatibility and avoid potential issues with tax regulations. A future enhancement will automate this process for users.
Original PR description
It's been 4 years since the last update [1]. No codes were removed. At some point it would be nice to add this to the avatax_sync_company_params() method so it can be initiated by the user. But we need to update this file regardless, and the mechanism would need to be smart enough to not cause duplicates when e.g. the user has synced it themselves, we then update the csv and they then update the module. [1] https://github.com/odoo/enterprise/pull/30220 opw-5928245 Forward-Port-Of: odoo/enterprise#108209
This update fixes an issue where warehouse names with only numbers (e.g., '01') were displayed incorrectly in the barcode app. The fix removes a browser setting that caused numerical warehouse codes to be reversed, ensuring accurate and consistent display of warehouse names regardless of their format.
Original PR description
### Steps to detect the bug: - Download stock apps - Enable "storage locations" settings under warehouse index - Change name of warehouse with a name composed only of numbers (ex. 01) - Create a…
### Steps to detect the bug:
- Download stock apps
- Enable "storage locations" settings under warehouse index
- Change name of warehouse with a name composed only of numbers (ex. 01)
- Create a product (with barcode number)
- Insert a number of products available with smart button "on hand"
- Create a new delivery for that product
- Go to barcode app and search for the delivery you just created
- Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.
### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
opw-5730199
Forward-Port-Of: odoo/enterprise#107920This update removes an unnecessary wrapper div from article content, streamlining the HTML structure. Previously, the system added a `div` to ensure proper parsing of article bodies, but this caused increased HTML depth. This change improves efficiency and maintains consistent article formatting.
Original PR description
Prior to this commit, `_get_transformed_body_from` wrapped the source body in a `div` because `lxml.html.fragment_fromstring` is used with a `create_parent=True` argument. That argument is required because otherwise, the function throws an error if there are multiple root nodes in the parsed string, which is frequent in an article body. The final returned string still contained that additional `div` ancestor. This does not break an article per se, but repeated usage would increase the html structure depth by 1 every time, and that additional `div` was not part of the function desired transformations. task-5960616 Forward-Port-Of: odoo/enterprise#108310
Features or functions removed from Odoo
This update removes a temporary feature that automatically disabled longpolling after device connection errors. We've shifted to a model where clients are expected to have reliable networks, so errors are handled gracefully. This change improves system stability and reduces unnecessary interruptions.
Original PR description
We used to disable longpolling for 5 min after a failure, in order not to lose time while making requests to an unreachable device, and jump directly to WebSocket. As we now recommand using LNA, clients should have a correctly configured network: if an error occurs the next one should work correctly. We then removed the longpolling auto disable feature.