Daily updates from Odoo
Wednesday, October 15, 2025
19 changes · 17.0
Enhancements to existing features
The website editor now detects when a user's browser or device cannot support image filters and disables that option instead of showing an error. This improves editing reliability, especially on Linux Chrome setups where WebGL may no longer fall back to software rendering.
Original PR description
On recent versions of Chrome for Linux (v140+), the old SwiftShader software fallback for WebGL has been removed. As a result, new window.WebGLImageFilter() now throws if no GPU context is available, typically when WebGL is disabled or unsupported. Since the application cannot enable WebGL from JavaScript, this commit improves the user experience by detecting the absence of a WebGL context early and disabling image filters in edit mode. Instead of raising a traceback, the editor now skips the filter feature and can optionally display a friendly message explaining that WebGL is required to use image filters. This avoids runtime errors and ensures a more robust behavior on platforms where WebGL is unavailable. task-5117584
Resolved issues and error corrections
This fixes issues in the Social app when commenting on Twitter posts. Images now upload with the correct file type, and comment text is no longer lost when adding files or emojis.
Original PR description
Issue 1 ======= Steps to reproduce ----------------------- 1. Go to the Social app. 2. Create or Select any twitter post. 3. Add a comment to that post with an image. 4. Press Enter. ---> An error…
Issue 1
=======
Steps to reproduce
-----------------------
1. Go to the Social app.
2. Create or Select any twitter post.
3. Add a comment to that post with an image.
4. Press Enter.
---> An error notification will be shown.
When adding an image in a post comment to Twitter, the image was not uploaded properly because the MIME type was not set, and it defaulted to `application/octet-stream`.
This caused the following error:
```
{"errors": [{"parameters": {"$.media_type": ["'application/octet-stream'"]},
"message": "$.media_type: does not have a value in the enumeration
[video/mp4, video/webm, video/mp2t, video/quicktime, text/srt, text/vtt,
model/gltf-binary, model/vnd.usdz+zip, image/jpeg, image/gif, image/bmp,
image/png, image/webp, image/pjpeg, image/tiff]"}], "title": "Invalid Request",
"detail": "One or more parameters to your request was invalid.",
"type": "https://api.twitter.com/2/problems/invalid-request"}
```
From the above error, it's clear that Twitter only accepts specific MIME types.
This fix ensures the image has the correct MIME type so it can be uploaded without issues.
-------------------------------------------------------------------------------------------------------------------------------
Issue 2
=======
Steps to Reproduce
------------------------------
1. Select any post from social feed.
2. Add text comment or edit existing comment.
3. Upload file or add emoji.
=> The comment text is cleared/reset to its initial value.
Technical
------------------------------
With commit [1] we added `t-att-value` which sets the value of the textarea
on every re-render of the component.
After this commit
------------------------------
The initial value is only set once when component is mounted.
Removed `remove image` button for attachment while posting comments.
[1] https://github.com/odoo/enterprise/commit/ced5e88f433b7b9a8e1429259cd8bb6594b34852
Task-4845385Users can now print or export their own timesheets from a single private project without encountering an access error. This removes an inconsistency that blocked valid reporting for assigned users while keeping the same information visibility already available elsewhere in Odoo.
Original PR description
****Behavior:**** **Current:** When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as…
****Behavior:**** **Current:** When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as it appears under "My Tasks". The user might then want to print or export the timesheets form the list view. - If the selected timesheets come from only a single private project : an Access Error is raised - If the selected timesheets come from multiple private projects, or a mix of public and private ones : no Error is raised The issue comes from the need to access to the project's name (since the project is private to the user the code raises the error) as well as the company's name. And it only happens when single projects are selected, in the other cases, the exported pdf shows the project's name at another location without error. **Expected:** Since the information is already accessible through multiple other places in odoo (and even in the exported pdf), we should allow the access here aswell. So now when printing or exporting a timesheet from a single private project, no Access Error is raised. **Steps to reproduce:** - Create 2 different projects - Create a task in each - Assign it to another user (Make sure the other user only has user access to timesheets and projects) - Set each project's visibility setting to private - Log in with the other user - Go to Timesheets --> List View Single projects: - Select one or multiple timesheet entries from one of the private projects - Select Print -> Timesheets - You should see an Access Error Multiple projects: - Select one or multiple timesheet entries from a combination of both private projects - Select Print -> Timesheets - You should not have any Errors opw-5127526
Changing the timezone on an appointment page could crash the booking flow when no specific resource filter was selected. The fix ensures the system uses the appropriate available resources automatically, keeping appointment slot refreshes working smoothly.
Original PR description
Changing the timezone on the appointment page triggers a refresh of the available slots. In that flow, the controller computes the maximum possible capacity using `filter_resources`. When no specific…
Changing the timezone on the appointment page triggers a refresh of the available slots. In that flow, the controller computes the maximum possible capacity using `filter_resources`. When no specific resource is selected, `filter_resources` remained falsy and was passed down to `_get_max_capacity_possible`, which then attempted to call a recordset method on a boolean value. Steps to reproduce: 1. Appointments > Dental Care 2. Select a person 3. Change the timezone 4. Observe a traceback Current behavior: `AttributeError: 'bool' object has no attribute '_get_filtered_possible_capacity_combinations'` because `filter_resources` is falsy (boolean) instead of a recordset. this fix: When `filter_resources` is falsy, compute it with `self._get_possible_resources(appointment_type, filter_resource_ids)` before calling `_get_max_capacity_possible(...)`. This guarantees a proper recordset is used and avoids calling recordset methods on a boolean. If a resource is explicitly selected, behavior is unchanged. If not, we now use the same "possible resources" logic already employed by the rest of the route. opw-5152162
Fixed an issue that could show an error when customers switched resources on an appointment page after capacity management was turned off. This helps keep the online booking flow working smoothly for resource-based appointments such as courts or rooms.
Original PR description
Step to reproduce: - Open Appointments app. - create a appointment with resources (for eg: create few courts) - untick "manage capacities" - set Assignment method to "Pick User/Resource then Time" - Go to Website -> switch the resource and you'll get the error message. Issue: - method "_updateResourceCapacityOptions" tries to access `capacitySelect` value - if 'manage capacities' is unchecked, we do not have the actual element and hence error Fix: - we use null safety in the if condition to fix the issue opw-5158477
Appointment booking no longer crashes when a visitor changes the selected resource while capacity management is disabled. This keeps the website booking flow working reliably for appointment types that let customers pick a user or resource first.
Original PR description
Currently, a traceback is occurring when the user selects a resource. **To reproduce this issue:** 1) Install the website and appointment modules. 2) Create an appointment with: - Availability set to…
Currently, a traceback is occurring when the user selects a resource.
**To reproduce this issue:**
1) Install the website and appointment modules.
2) Create an appointment with:
- Availability set to "resource" and add 2 resources
- Assignment Method set to "Pick User/Resource then Time"
3) Ensure that "Manage Capacities" is unchecked.
4) Open the appointment on the website.
5) Change the selected resource.
**Error:**
`TypeError: Cannot read properties of null (reading 'value')
at Class._updateResourceCapacityOptions `
**Cause:**
When the user unchecks `resource_manage_capacity` in the appointment settings,
the `resourceCapacity` element is not present in the DOM, resulting in a null return
value from the query selector. Accessing .value on this null causes the traceback.
https://github.com/odoo/enterprise/blob/546e295743c06853a0dd8595bb1a5e2a9b302c36/appointment/static/src/js/appointment_select_appointment_slot.js#L81-L85
**Solution:**
Add an additional check to verify the presence of `capacitySelect` before accessing its value.
opw-5105225The Saudi Arabia e-invoicing module now labels the second street/address field as “District” instead of “Street 2”. This helps users enter the correct district or borough information and reduces the risk of e-invoicing compliance mistakes.
Original PR description
## Before this commit The `street2` field on `res.company` and `res.partner` was mapped to `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CitySubdivisionName`, but its placeholder displayed `Street 2…`. This caused confusion among users, as they assumed it referred to `cbc:AdditionalStreetName`, leading to incorrect data entry and potential non-compliance. ## After this commit The placeholder of the `street2` field has been changed from `Street 2…` to `District…`, clarifying that this field represents the city subdivision (district or borough) of the Seller/Customer, in line with the Saudi Arabia e-invoicing specification. > Task-4951545 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes a Romanian SAF-T report test independent of the current date, so it produces consistent results whenever it runs. It helps reduce false test failures and improves reliability of ongoing maintenance without changing user-facing behavior.
This update corrects an internal calculation problem in account reports that could cause report values to be computed using the wrong context. It helps ensure financial reporting behaves reliably without changing how users interact with the feature.
Replies to signature request, confirmation, or refusal emails are now shown in the related signing record's chatter. This helps teams keep all signer communication visible in one place and reduces the risk of missed responses.
Original PR description
Previously, when users replied to sign request, signature confirmation, or refusal emails, their responses were not displayed in the corresponding sign request’s chatter. This fix ensures that replies to those emails are now properly routed and shown in the related record’s chatter. task-5105494
This fixes an issue where Mexican electronic invoice XML attachments could be saved with the wrong file type for users with limited permissions. As a result, related Documents records are created correctly when accounting centralization is enabled.
Original PR description
When creating an XML attachment as a user without Write access on the ir.ui.view model, the Mimetype will be set to plain/text. In particular, this causes issues when Accounting centralization is enabled in Documents, as the corresponding Document will only be generated if the Mimetype is application/xml. Creating the XML as Superuser avoids this issue. Similar to https://github.com/odoo/odoo/pull/124507 opw-5057038
This update prevents an error that could crash the screen when users expand a Spanish VeriFactu document record. It removes an unsupported messaging panel from that view, improving reliability without changing the document data or workflow.
Original PR description
The system will crash with error when user clicks on expand button. **Error:** `AttributeError: 'l10n_es_edi_verifactu.document' object has no attribute '_get_thread_with_access'` **Cause:** - `l10n_es_edi_verifactu.document` does not inherits ['mail.thread', 'mail.activity.mixin'] and used chatter in it's form view. - In this PR, removed `<chatter/>` from view. Already fixed for master here: https://github.com/odoo/odoo/pull/231477 **sentry-6792833694** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures French VAT reports sent through ASPOne use the correct values and length limits for company name and address fields. It helps prevent rejected or invalid filings caused by formatting that does not match ASPOne's 2025 XML requirements.
Original PR description
The aim of this commit is making sure that the field Designation, DesignationSuite1, DesignationSuite2, AdresseVoie and AdresseComplement are correctly filled. Indeed, the XSD implied that these fields have to be respectively 35, 35, 35, 30 and 35 characters max. [Documentation 2025](https://www.aspone.fr/files/tutoriaux/xmledi/Documentation_XML-EDI.zip) no task id
Administrators can now retry or cancel system-generated SMS messages without being blocked by an access error. This helps support and operations teams manage failed delivery or notification messages more reliably from technical settings.
Original PR description
## Issue: In debug mode, the administrator could not resend or cancel an SMS that was sent by the system (e.g. delivery confirmation) using the `Retry` / `Cancel` button in the Technical Settings An Access Error was raised ## Cause: When using the `Retry` or `Cancel` button, the method `_update_sms_notifications()` is called and finds `mail.notifications` records to update However, `notifications.write()` triggers an Access Error because only the recipient of a `mail.notification` is allowed to modify it: https://github.com/odoo/odoo/blob/98610ea2a1369b84b10adb8913c5d7725a0fad67/addons/mail/security/mail_security.xml#L184-L192 This happens even when the user has the rights to resend or cancel the SMS ## Steps to reproduce: - Install an app like stock_sms to create blocking entries - Create and confirm a Delivery - Choose Send SMS - Enable developer mode - Search for the technical settings SMS - Retry sending the automatically sent SMS opw-4904157
The French FEC import now uses a valid debit account for rounding entries after a chart of accounts update changed the previous account code into a grouping account. This prevents import issues and helps ensure accounting data can be processed correctly.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id
This fix ensures Argentina electronic invoicing test validations only use dummy AFIP validation when the system is in testing mode and required test credentials are missing. It prevents test-only behavior from being triggered incorrectly, improving reliability for localization validation workflows.
Original PR description
This PR corrects the logical condition in the `_is_dummy_afip_validation` method. Previously, the or operator was not properly grouped, which could result in incorrect evaluation when checking if the AFIP certificate (`l10n_ar_afip_ws_crt`) or key (`l10n_ar_afip_ws_key`) are missing in a testing environment. By adding parentheses, the code now accurately ensures that the dummy AFIP validation is activated only when the environment is set to "testing" and either the certificate or key is not present. This improves the reliability of the testing logic and prevents unintended behavior in AFIP validations. Forward-Port-Of: odoo/enterprise#96432
Fixed an issue in the website team section where images added inside team member descriptions were incorrectly resized on mobile. The change keeps the intended avatar styling while allowing description images to keep their own sizes, improving page presentation on smaller screens.
Original PR description
Scenario:
- Add s_company_team snippet ("Meet our team" with avatar side by side
with description)
- Add an image in the description (small or big)
- See the page with mobile
Result: all images in the description get a fixed 50% max-width (from
18.0 a 8rem height) which was only meant for the avatar image.
Fix: be more specific with the selector to target only the avatar. The
selector .row.s_col_no_resize > .o_not_editable img.o_editable_media
should only target the intended avatar.
opw-4997932This change ensures accounting localization tests always install the required demo data before running. It keeps test behavior consistent across versions and reduces the risk of false test failures, with no direct impact on everyday users.
Original PR description
In later versions, we improve the testing suite to avoid having to install demo data in order to reduce the testing time. In order to keep the testing configuration simple across versions, we force the installation of demo data instead of only asserting that demo is installed before launching the script. Forward-Port-Of: odoo/odoo#231660
Miscellaneous changes
opw-5018450
Original PR description
opw-5018450