Wednesday, September 17, 2025
16 changes · saas-18.4
Resolved issues and error corrections
When the AI feature cannot read a webpage, the system now records it as a warning instead of an error. Users are already informed about the failed URL, so this change keeps monitoring cleaner without changing the user workflow.
Original PR description
Currently, an error can occur on unsuccessful scrapping of URL.
**Error:**
`Error scraping URL https://agenciavirtualpy.com: HTTPError('403 Client Error: Forbidden for url: https://agenciavirtualpy.com/')`
- Instead of logging an error, we log only warning during unsuccessful URL
scraping because it is not a blocking point in the code.
- On unsuccessful scraping, we log warnings [1] and raise a UserError [2] to
inform the user about the failed URL scraping. Therefore, we should log a
warning as the UserError is already present.
[1]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L258
[2]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L283-L285
sentry-6634525990
Forward-Port-Of: odoo/enterprise#94002This fixes a rare internal failure that could occur when Odoo tries to capture diagnostic information after a serious error. It helps preserve the original problem details, making troubleshooting more reliable without changing normal user workflows.
Original PR description
Cf #226267 the "error condition" on the ws socket is that it's not present at all, not that it's `None`. So when used after a fatal error (e.g. in the context of trying to take a screenshot or take a screencast) these methods *can* in some cases trigger a compound failure and lose the original error because they fail on trying to access the ws to check if it's truthy. Forward-Port-Of: odoo/odoo#227469 Forward-Port-Of: odoo/odoo#227385
This fixes an error that could appear when a user’s default landing page was set to Shop Floor. Users can now log in directly to Shop Floor without seeing a crash, improving reliability for manufacturing floor workflows.
Original PR description
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback…
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback after logging in. **STEP TO REPRODUCE** 1. Go in debug mode 2. Change the home action of a user to the 'Shop Floor' action (in the user form, in the preference tab). 3. log out, and log in with this user. 4. a js traceback should appear. **CAUSE** In mrp_workcenter_dialog.js, the Shop Floor action uses the `menu` service to get the name of the current app. `setCurrentMenu()` which set the current app in the `menu` service is not called before the `appName` getter is called. https://github.com/odoo/odoo/blob/5c1234085b1c1e227846b24bde55a0392779069b/addons/web/static/src/webclient/menus/menu_service.js#L29-L36 This lead to a traceback because this.menu.getCurrentApp() is `undefined`. **FIX** Workaround if the current app is undefined. We already check what is returned by `getCurrentApp()` where it is used. opw-4926317 Forward-Port-Of: odoo/enterprise#94655 Forward-Port-Of: odoo/enterprise#93043
This fix prevents an installation error when the withholding tax module is installed alongside Indian localization demo data. It makes setup more reliable by ignoring purchase taxes that do not include the expected tax distribution details.
Original PR description
Traceback when no `repartition_line_ids` found in tax data. Steps to reproduce:- - Install `l10n_in` module with demo data. - Install `l10n_account_withholding_tax` module. Error:- ``` File /data/build/odoo/addons/l10n_account_withholding_tax/__init__.py, line 27, in _make_demo_tax tax_repartition_lines = [line[2] for line in tax_data[purchase_taxes[0]]['repartition_line_ids'] if line[2]['repartition_type'] == 'tax'] KeyError: 'repartition_line_ids' ``` Root Cause: At [1], No `repartition_line_ids` found in `tax_data[purchase_taxes[0]]`. Solution: Select only purchase taxes having `repartition_line_ids`. [1]: https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/l10n_account_withholding_tax/__init__.py#L27 Forward-Port-Of: odoo/odoo#227381
This update fixes Philippine tax setup data so the 0% Exempt tax is no longer incorrectly linked to both VAT Exempt and VAT Registered statuses. It also adjusts the VAT Exempt fiscal position setup, helping Filipino companies get more accurate tax behavior and reporting out of the box.
Original PR description
### Steps to reproduce: - Install "l10n_ph" and switch to a Filipino company - Check the tax "0% Exempt", it has both "VAT Exempt" and "VAT Registered" ### Cause: The CSV was badly generated because of the fiscal position tax mapping before 18.3. ### Solution: Fix the CSV. Also delete the country for the fiscal position "VAT Exempt". This is a [recommendation from AYH on discord](https://discord.com/channels/678381219515465750/687337689988726949/1410930795329097880). opw-5044305 Forward-Port-Of: odoo/odoo#227261
Fixes an issue where configuring website-related fields from the backend could fail because the system expected storefront pricing data to be available. Odoo now safely falls back to the company currency, helping users continue website setup without errors.
Original PR description
Prior to this commit, the website currency was computed using the request pricelist. However, this logic assumed that the compute method could only be called from a frontend request.
However, via `web_studio`, a user can add fields linked to a website, which triggers the computation in a backend request, causing the following traceback:
```
Traceback (most recent call last):
...
File "/data/build/odoo/addons/website_sale/models/website.py", line 282, in _compute_currency_id
request and request.pricelist.currency_id or website.company_id.sudo().currency_id
^^^^^^^^^^^^^^^^^
AttributeError: 'Request' object has no attribute 'pricelist'
```
This commit fixes the issue by first ensuring that the pricelist exists and falling back to the company currency if it does not.
opw-5068581
Forward-Port-Of: odoo/odoo#227450The Malaysian EDI fields now show identity card numbers without hyphens, matching how they are typically entered in ERP systems. This reduces user confusion and helps ensure company and contact details pass validation with IAP and MyInvois.
Original PR description
Hyphens are generally omitted in ERPs, and just shown on the Identity card. Putting hyphens in the placeholder is actually misleading for users, and prevents validation through the IAP server and MyInvois Ref: https://en.wikipedia.org/wiki/Malaysian_identity_card#Structure_of_the_National_Registration_Identity_Card_Number_(NRIC) Task [link](https://www.odoo.com/odoo/project/967/tasks/5054821) task-5054821 Forward-Port-Of: odoo/odoo#225094
When a payment memo is changed, the related journal entry reference is now updated as well. This keeps payment and accounting records aligned, reducing confusion during reconciliation and review.
Original PR description
Issue: In previous versions, the memo field of account payments and ref field of account move were related Now that payments do not required to have generated account move's when the memo is updated the ref remains unchanged. Purpose of this PR: To update the account move ref when the payment memo is updated. Steps to Reproduce on Runbot: install accounting go to bank account and assign outstanding accounts for manual payment methods create a payment -- a related account move should be created update the memo on the payment -- the ref on the related account move is unchanged. opw-4989260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226168 Forward-Port-Of: odoo/odoo#223459
This fixes an issue where clicking empty areas in social media, share, and rating blocks while editing a website could accidentally select content and show an unwanted toolbar. The blocks now behave as intended, keeping normal title editing available while preventing confusing accidental selections.
Original PR description
This PR fixes undesired selections that might happen when clicking on empty spaces on the following snippets: - s_social_media - s_share - s_rating Such selections are undesired as: - these snippets are not meant to be editable via the Editor (except for their title, when present). - the uncollapsed selection results in the floating toolbar being displayed. This PR's strategy was: - to make sure these snippets are contenteditable=false at their root, in case that was not already the case in the snippet template. - to make the snippets' content non user-selectable. While this does not affect the contenteditable=true areas (.i.e. the title), it effectively prevents selecting the non editable areas. task-5066301
The website builder now handles invalid progress bar number entries safely instead of triggering an error. It also prevents confusing duplicate percent signs, making editing progress bars more reliable for users.
Original PR description
Before this commit, putting an invalid input in the progressbar value would lead to a traceback. Moreover, the input could display "0%%" (one being in the input, the other being the displayed unit). This commit solves this issue by defining a saveUnit for the input and using the defaultValue when an input is invalid.
The Discuss app no longer shows the compact chat hub button when chat hub conversations are not meant to appear there. This removes a redundant and confusing interface element, making the messaging experience cleaner for users.
Original PR description
Before this commit, chat hub compact was visible in disucss app. This happens because while chat windows and bubbles are conditioned to not be shown in discuss app (with exceptions), the compact mode of chat hub was solely relying on compact mode on/off, ignoring the overall condition for whether some conversations are shown in chat hub (note: conversations in compact are still considered as "shown"). This commit adds extra condition on showing compact button to take into account chat hub showing some conversations. If no conversations are shown, then the compact mode should not be shown at all. Discuss app prevents showing of conversations in chat hub (with exceptions), as this is redundant with discuss app itself. Backport of https://github.com/odoo/odoo/pull/227162 Forward-Port-Of: odoo/odoo#227190
A test for Swiss payroll contract templates was corrected by removing a reference to a field that is not supported in this context. This helps keep automated checks reliable and reduces the risk of false failures during future updates.
Original PR description
The CH contract template whitelist test referenced `overtime_from_attendance` when creating a Version. task-5095572
This update fixes issues that caused the Sign app guided tour to fail in different situations, including adding signature fields and handling users with saved signatures. It helps ensure the onboarding/testing tour runs consistently, reducing interruptions for users and testers.
Original PR description
Fix `sign_tour`. How to reproduce: 1. Go to tours in Odoo 2. Look up sign_tour 3. Click testing ( If testing stops at Sign App, change search filters or archive sign all .request records so that the…
Fix `sign_tour`.
How to reproduce:
1. Go to tours in Odoo
2. Look up sign_tour
3. Click testing ( If testing stops at Sign App, change search filters or archive sign all .request records so that the following screen displays )
<img width="780" height="591" alt="image" src="https://github.com/user-attachments/assets/b164c224-0e3e-4dce-97e6-89848263e59e" />
4. tour fails!
---
First commit
The `sign_tour` was failing after the conversion of the `sign.Template` client action to OWL. The standard `drag_and_drop` tour helper can no longer be used for automatic tour testing because the drop target is inside an iframe whose content is managed by PDF.js.
This commit fixes the tour by utilizing the custom helper function, `dragAndDropSignItemAtHeight`, to programmatically simulate the drag and drop action.
---
Second commit
The step "footer.modal-footer button.btn-primary:enabled" assumes that the Signature Dialog opened from its previous step ("Sign It" navigation button).
However, the "Sign It" navigation button does not always open the dialog.
If signing user (res.users) already has "sign_signature" data, the data will be automatically filled in to the Signature input.
Otherwise, the navigation button will open the Signature Dialog.
Luckily, we can see whether user has "sign_signature" data or not by checking if the <input data-item_type='signature'/> node has "data-auto_value" attribute or not.
We now skip the step if data-auto_value is set for signature.
---
Third commit
If `sign.template_sign_tour` has sign request, it means that the template might have a sign item because the `sign_tour` tour adds the Signature sign item to the template. (If user followed the tour)
When we're copying the sign template to trigger the template tour, we should not copy the sign item. User will be guided to add the sign item during the tour.
---
Note:
ci/security needs to be overriden as it was done for https://github.com/odoo/odoo/pull/134793#issuecomment-1711440188
---
opw-4752794
Forward-Port-Of: odoo/enterprise#93601
Forward-Port-Of: odoo/enterprise#91565Many-to-one selection fields now shorten long text correctly so the ellipsis is visible and fields stay aligned. This improves readability and layout consistency, including in the employee form's Private Information tab.
Original PR description
The text-truncate bootstrap class of the m2o field does not work properly as the ellipsis is not visible and create an alignment issue with the private_state_id field. This PR solves this issue which can be seen in the "Private information" tab of the employee form. Task-5078736 Forward-Port-Of: odoo/odoo#226214
The Hungarian electronic invoicing module now includes the missing SZJ product code required by official NAV XML 3.0 documentation. This helps businesses using Hungarian localization create compliant electronic invoice data without manual workarounds.
Original PR description
Description of the issue/feature this PR addresses: In the official NAV XML 3.0 documentation (available at: https://onlineszamla.nav.gov.hu/dokumentaciok page 123), according to the list of possible product codes, there is an 'SZJ' code that is missing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226213