Monday, September 15, 2025
11 changes · 18.0
Resolved issues and error corrections
Corrects an issue that could prevent Italian companies from posting tax return closing entries. This ensures the tax return workflow completes normally instead of failing with an unexpected error.
Original PR description
The `osv.expression.AND` operator was incorrectly used, leading to an invalid search domain and raising an error. Steps to reproduce: - Set the company country to Italy - Go to Accounting > Reporting > Tax return - Create a closing entry - Try to post the closing entry - An error is raised: ```python elif token[1] == 'in' and not (isinstance(token[2], Query) or token[2]): ~~~~~^^^ IndexError: string index out of range ``` The fix wraps the subdomain in a list so the domain is properly evaluated. opw-5075640 Forward-Port-Of: odoo/enterprise#94277
Fixes an issue where Razorpay OAuth webhook generation could fail when Website Payment was installed. The update builds callback URLs more safely, preventing authentication errors caused by malformed links.
Original PR description
A bad URL could be generated when the `website_payment` module is installed, as it overrides `get_base_url` and may return a URL ending with `/`. Using f-strings to create URLs could result in a double slash `//`, causing errors. Steps to reproduce: - Install `website_payment` and `payment_razorpay_oauth` - Go to Payment Acquirers and connect via OAuth - Click "Generate your webhook" - "Authentication failed" error appears This fix uses `url_join`, like other payment providers, to build URLs correctly and avoid the double slash issue. opw-5079295 Forward-Port-Of: odoo/odoo#226248
This fixes an access issue where timesheet approvers could not see other users' time entries on tasks they followed in private projects. Approvers with the right permissions can now view those timesheets both on the task and in reporting, aligning access with their task visibility.
Original PR description
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security…
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access. https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117 **Steps to reproduce:** 1. Create a private project (`privacy_visibility == 'followers'`) 2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access 3. Add Marc Demo as a follower of a task in that private project 4. Have another user log time on that task 5. Log in as Marc Demo Marc cannot see the other user's timesheets, neither on the task form nor in reporting. opw-5022877 Forward-Port-Of: odoo/odoo#224025
EU OSS taxes created for Spanish localization are now assigned the correct tax classification instead of being marked as a standard taxable type. This helps businesses keep OSS tax reporting aligned with Spanish compliance requirements and avoids incorrect tax categorization after refreshing mappings.
Original PR description
The EU OSS taxes were generated with the wrong l10n_es_type. - Install l10n_es and l10n_eu_oss. Then go to Settings and refresh the tax mapping in “EU Intra-community Distance Selling.” - In Taxes, filter by tax group containing “OSS.” All OSS taxes appear with l10n_es_type = sujeto. This is incorrect. The correct type should be “No Sujeto por reglas de localización” (see section 2): https://a3responde.wolterskluwer.com/es/s/article/version-3-05-del-moduloticketbai-batuz-de-a3erp-mejoras#OSS This commit adds the possibility of adding country specific field during the account_tax creation using chart_template -> fields mapping. opw-5009180 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224192
Fixes an issue that prevented Ecuadorian delivery guides from being generated when barcode scanning was disabled in Inventory settings. This helps businesses create required delivery documents reliably without needing to enable an unrelated barcode feature.
Original PR description
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch…
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch to the `EC company`. - Uncheck `Barcode Scanner` in the Inventory `settings`. - Create a new warehouse and set the `Entity` and `Emission Point`. - Navigate to Inventory > Operations > Deliveries and create a new delivery. - Add details > mark as Todo > Validate > Generate Delivery Guide. **Error:** `AttributeError: 'stock.move.line' object has no attribute 'qty_done'` **Root Cause:** At [1], the code references `line.qty_done`, but this field is defined in the `stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, the field is not available, leading to the `error`. **Fix:** This commit updates the delivery guide values to use `line.quantity` instead of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3], `qty_done` is derived from `quantity`. [1]: https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354 [2]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23 [3]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50 [4]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165 sentry-6851008674
Users can now add several new comma-separated tags when creating a forum post without triggering an error. This prevents failed post submissions and makes forum tagging more reliable.
Original PR description
Currently, an error occurs when a user tries to add multiple comma-separated new tags to a forum post. **Steps to reproduce:** - Install the `website_forum` module. - Go to: `Website > Configuration…
Currently, an error occurs when a user tries to add multiple comma-separated new tags to a forum post. **Steps to reproduce:** - Install the `website_forum` module. - Go to: `Website > Configuration > Forums`, create a new forum, then click `Go to Website`. - Click on `Start by creating a post`, enter content, and set the `Tags` to `_test, retour affectif rapide`. - Click on `Post Your Question`. **Error:** `ValueError: invalid literal for int() with base 10: 'retour affectif rapide'` **Root Cause:** After PR #169472, at [1], the code prepends an underscore (_) only to the entire input string instead of each tag. When multiple tags are entered, the backend receives a mixed list of values (e.g., ['__test', 'retour affectif rapide']), leading to an error during `int()` conversion at [2]. **Fix:** This commit updates the `onCreateOption` logic to prepend an underscore to each tag in the comma-separated input, similar to [3]. Also updated the test case at [4], to click `Create option` to save the tags. [1]: https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/static/src/js/website_forum.js#L54-L61 [2]: https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/models/forum_forum.py#L304 [3]: https://github.com/odoo/odoo/blob/ac93a25b216e6194895a64fe12c0d01f6833f743/addons/website_forum/static/src/js/website_forum.js#L69-L80 [4]: https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/website_forum/static/tests/tours/website_forum_question.js#L34-L37 sentry-6761920887
Employees with more than one running contract can now open the Time Off app without encountering an error. This fixes a contract-handling issue so Odoo correctly processes unusual days across multiple active contract periods.
Original PR description
**Step to Reproduce** - install hr_contract and hr_holidays module - go to employee -> contracts - Add 2-3 contract to a employee, which can be done by having contracts in different interval (but…
**Step to Reproduce**
- install hr_contract and hr_holidays module
- go to employee -> contracts
- Add 2-3 contract to a employee, which can be done by having contracts in different interval (but same year)
- set their stage to `running`
- open Time off App
**Observation:**
- we receive a traceback
```
File "/data/build/odoo/addons/hr_contract/models/hr_employee.py", line 229, in _get_unusual_days
tmp_date_from = max(date_from_date, selected_contract.date_start)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/fields.py", line 1424, in __get__
record.ensure_one()
File "/data/build/odoo/odoo/orm/models.py", line 5635, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.contract(1, 2)
```
**Cause:**
- `_get_unusual_days` assumes that there is only one running contract
- Hence with multiple contract, it raises traceback
Fix:
- Adjust the method to accept multiple contracts
opw-5045306
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe accounting KPI summary now counts posted entries that still need accountant review, not just draft entries. This gives teams a more accurate view of pending accounting work by journal category.
Original PR description
The `kpi.provider:get_account_kpi_summary` method should count draft moves by category, but also include posted moves that still are to be checked by the accountant. Task-id: 5062431 Forward-Port-Of: odoo/odoo#226976 Forward-Port-Of: odoo/odoo#226411
The email editor now handles certain copied marketing designs more safely, preventing an error when users switch between editing tabs. This helps staff reuse email layouts across marketing emails and templates without interrupting their workflow.
Original PR description
If we copy "Event Promo" design from mailing.mailing to mail.template JS will fail. The quesryselector can fail so better to safeguard the working function. To reproduce the bug: - open mailing.mailing and create a new record - Choose "Event Promo" to be mail body - copy the HTML of the body - go to mail.template and create a new record - paste that HTML in the body of mail.template new record - switch between Content and Settings tabs and observe. The next error will raise up UncaughtPromiseError > TypeError Uncaught Promise > can't access property 1 of null TypeError: can't access property 1 of null formatTables@http://localhost:8069/web/assets/319-85bee19/web.assets_backend.min.js:13286:268 toInline@http://localhost:8069/web/assets/319-85bee19/web.assets_backend.min.js:13275:478
Sales orders created from a branch company can now be confirmed when they use loyalty programs owned by the parent company. This prevents access errors and keeps loyalty discounts and history working consistently across company branches.
Original PR description
If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised. Steps to reproduce: ------------------- * Create a…
If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised. Steps to reproduce: ------------------- * Create a loyalty cards program * Set company to the current company * Create a branch company for the current one * Switch to branch company * Create a sale order, no need to add products, just a partner * Try to confirm the order > Observation: Access Error: > Sorry, Mitchell Admin (id=2) doesn't have 'create' access to: > -History for Loyalty cards and Ewallets (loyalty.history) Why the fix: ------------ Here's where the access error is being triggered: https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/sale_loyalty/models/sale_order.py#L106 Branches currently have access to the discounts & loyalty programs from the parent company, we extend the access to include loyalty history. Another solution could be to create the loyalty history using sudo() if the coupon's program id is a parent of the current company. opw-5055999
This fixes an issue where Point of Sale orders could remain stuck if the browser was refreshed before cancelling a Worldline terminal payment. The POS now continues receiving the cancellation confirmation, reducing checkout disruption and manual recovery for staff.
Original PR description
This PR fixes a bug where the point of sale didn't receive notifications from the Worldline payment terminal for the cancellations if the browser webpage was refreshed How to reproduce: 1. Open a POS session with Worldline terminal 2. Send a transaction to the terminal 3. Refresh the browser webpage before paying 4. Click on "Cancel" on the POS screen --> your order will be stuck and never receive the confirmation This PR removes the check for the iot longpolling action identifier which changes on refresh of the webpage + adds more error messages for Worldline terminals Related PR in >= saas-18.3: https://github.com/odoo/enterprise/pull/94629 task-5075860 Forward-Port-Of: odoo/enterprise#94635