Tuesday, April 14, 2026
7 changes · saas-18.2
Resolved issues and error corrections
Updated outdated links used by Sales and product screens so users can open the sample quotation PDF without reaching a blank 404 page. This restores the intended onboarding/sample flow when the Sales app is installed without demo data.
Original PR description
Currently, a 404 error is occurring when the user clicks on the Check the sample button. **Steps to produce:** - Install sales module without demo data. - Click on the check a sample. its clean! button. **Issue:** - A 404 error occurs with a blank page. **Cause:** - This issue is occurring because the link to open the sample quotation pdf was changed in the Odoo documentation. **Solution:** - Give a valid link to open the sample quotation pdf. - similar fix already did [here1] & [here2]. [here1]: https://github.com/odoo/odoo/commit/38431f3aef57c5b91644b4c5241f226beb917b12 [here2]: https://github.com/odoo/odoo/commit/610cea89c37454a4ddb68939333b4b363f2f81a2 opw-6099641 opw-6074953 Forward-Port-Of: odoo/odoo#258003
This fixes an issue where portal users could not edit their own messages in a shared project task, with the action failing silently and showing an error in the browser console. The change makes the message editor handle loading details safely, improving reliability for external collaborators using Project sharing.
Original PR description
## Issue When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything. ## Steps to reproduce 1. Install *Project* (`project`) 2. Create a Project P and a…
## Issue When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything. ## Steps to reproduce 1. Install *Project* (`project`) 2. Create a Project P and a Task T 3. In the Setting of Project P, click *Share Project* and select a portal user 4. Logged as a portal user, open Task T, send a message in the chatter, then try to edit it by clicking the *Edit* (pencil) button. 5. **Nothing happens, but a traceback appears in the console: _Caused by: TypeError: Cannot read properties of null (reading 'id')_** ## Cause The condition causing this error is the following: https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L9-L13 where `this.thread` is not defined yet. Other conditions in this patch check for `this.thread` before trying to read its `id` [[1](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L25), [2](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L32)], which leads to believe that the check was simply forgotten in this condition. opw-6072570 Forward-Port-Of: odoo/odoo#258234
Fixed an issue where website form fields marked as hidden could still appear when the form was placed inside a Masonry block. This ensures published pages respect editor visibility settings while keeping hidden fields manageable during editing.
Original PR description
# How to reproduce - Go to the website editor - Add a Masonry block - Add a Form inner block in the Masonry block - Select any fields of the form - Set it's visibility to Hidden - Save # The problem…
# How to reproduce - Go to the website editor - Add a Masonry block - Add a Form inner block in the Masonry block - Select any fields of the form - Set it's visibility to Hidden - Save # The problem The field is still visible. # Cause When a field has its visibility set to hidden, it is applied the `.s_website_form_field_hidden` CSS class which applies `display: none`. https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/snippets/s_website_form/001.scss#L26-L28 But that CSS rule is overriden by the masonry's `.s_masonry_block[data-vcss='001'] .row > div` CSS class. https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/snippets/s_masonry_block/001.scss#L1-L3 https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/scss/website.scss#L3246 # Proposed solution We set `display: none` with `!important` to prevent it from being overidden. We also need to add `!important` to its edit mode counter-part so that the field is still visible in that mode. opw-6038955 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256100
This update resolves an issue where ticket submissions with emails in different capitalization (e.g., 'partner@mail.com' vs. 'Partner@mail.com') would incorrectly create a new partner. Now, the system correctly identifies and uses the submitted email to create the ticket without unnecessary partner creation.
Original PR description
**Steps to reproduce** - Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123"). - Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com"…
**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.
Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.
Behavior after this fix: no partner is created.
**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)
Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.
opw-5914064
Forward-Port-Of: odoo/enterprise#109393This update fixes an issue where users would lose their search filter selections in the MRP Planning view (MPS) after navigating away and returning. The fix ensures that search filter state is correctly maintained, improving the user experience and allowing users to quickly resume their planning tasks. This resolves a minor usability problem.
Original PR description
Issue: In the MPS view, when the user sets a search filter, navigates away and then returns via the breadcrumb, the search filters that were applied are gone. This happened because the MPS client action was not passing `globalState` to the `WithSearch` component. Fix by passing `globalState` in `withSearchProps`. task-5368078 Forward-Port-Of: odoo/enterprise#113183 Forward-Port-Of: odoo/enterprise#113125
This update fixes an issue where website date defaults were using the wrong timezone. The change ensures dates are correctly converted back to the website's timezone before displaying them to users, improving the accuracy of rental and sales information. This ensures consistent and reliable date presentation.
Original PR description
should be converted from website tz as they're going to be converted back by the front-end to that specific timezone. Runbot issue: 234756 Forward-Port-Of: odoo/enterprise#102153
A bug was preventing users from deleting timesheets when a confirmation dialog was open. This was caused by the timer incorrectly responding to the Enter key. This update ensures the delete confirmation dialog functions as expected, allowing users to properly remove timesheet entries.
Original PR description
When a delete confirmation dialog is open in the timesheet list view, pressing Enter starts/stops the timer instead of confirming the dialog. This happens because the timer's window keydown handler does not check for active modals before intercepting the Enter key. Add a `.modal` check consistent with the grid renderer's onKeyDown. Steps to reproduce: 1) Open timesheet list view 2) Select a record and delete it 3) When the confirmation dialog opens, hit ENTER key Current behavior: The Timer starts recording timesheet Expected behavior: The record should be deleted For ref: https://youtu.be/tzm_3RNe1ig Forward-Port-Of: odoo/enterprise#112583