Daily updates from Odoo
Monday, December 9, 2024
21 changes · 18.0
Resolved issues and error corrections
Emoji reactions in Mail are now styled so reactions from others are less visually prominent in dark theme. This makes it easier for users to distinguish their own highlighted reactions while keeping the light theme unchanged.
Original PR description
When message has emoji reactions, they have slightly different visual whether the current user has reacted or not: When the user has reacted, this is highlighted. This works great in white them, but in dark theme the non-self reacted visual was more highlighted, which goes against the intend of highlighting self-reactions more. The problem is that non-self reactions are too distracting in dark theme, which isn't the case in white theme, This comes from borders being too visible. The color of default `border` is too much in dark theme. This commit fixes the issue by using `border-secondary`, which has reduced opacity in dark theme. In white theme, this is unchanged. Before <img width="868" alt="Screenshot 2024-12-09 at 13 03 23" src="https://github.com/user-attachments/assets/963f6b65-a280-4be9-b15f-8a1cdbd562a5"> After <img width="864" alt="Screenshot 2024-12-09 at 13 03 31" src="https://github.com/user-attachments/assets/5c43b705-d750-4370-af5b-2f3ab3dac51e">
This fixes an issue where installing batch picking could unintentionally change the appearance of empty-screen messages across Odoo. The styling is now limited to the intended stock batch and fleet views, keeping other screens visually consistent.
Original PR description
**[FIX] stock_{picking_batch,fleet}: scope no content helper**
Since [1], a CSS rule was changing the size of all the no content
helpers throughout Odoo when `stock_picking_batch` was installed.
This commit fixes that by scoping the rule to its original intent.
opw-4370026
[1]: https://github.com/odoo/odoo/commit/06d1d48199ccfc79a80aea314f75d649b3149dba#diff-87ad06e3496be4ac6761b7052a11d9e9f1464e291d305405aae839f1a4d2ba9cR1
---
In order to achieve this, we needed to add support for the class attribute for graph and pivot views. It is only a matter of RNG validation as the code already support the parsing of the `class` attribute. The following commit is therefore added:
**[FIX] base,web: class attr for `<graph/>` & `<pivot/>`**
Before this commit, the class attribute for `<graph/>` and `<pivot/>` views
was not allowed.
As there is no valid reason not to do so, this commit now allows it.This fix ensures that when a screen component fails while loading, Odoo avoids leaving users with a partially displayed and inconsistent page. Instead, the web client replaces the failed view with a safe blank component so the interface remains stable.
Original PR description
Before this commit, if a component raised an error on it's onMounted hook, the rest of the onMounted hooks of all the other components would not execute. This is a desired behaviour, if an error is raised, we need to stop the execution. The issue with this, is that the error component (and the others), are already in the DOM, and since the onMounted hook functions haven't been executed, this leaves an inconsistent state. This commit will allow the action service to identify this particular case, and mount an BlanckComponent, to avoid having an inconsistent view.
The self-order interface now shows the product information icon when a public product description exists. This lets kiosk and self-order customers view helpful product details before ordering, reducing confusion and improving the ordering experience.
Original PR description
Problem: The `public_description` field is not loaded in `_load_pos_data_fields`, which prevents the product information icon from appearing in the self-order interface, thus hiding the public description from users. Solution: Ensure the `public_description` field is loaded so that the product info icon is displayed, allowing users to view the product's public description. Steps to reproduce: - Add a Public description to a product. - Open the Kiosk/Self-order interface. - The info icon is not visible, and the product description cannot be viewed. opw-4250442 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Chat windows now use the full mobile screen correctly in Safari instead of being constrained by a desktop-style shape. This keeps longer conversation names and header content visible, making mobile chat usable and consistent across browsers.
Original PR description
Chat window have their style improved recently [1]: their size and aspect-ratio have changed. The aspect-ratio is intended for desktop use. In mobile, it should take whole height and width of screen.…
Chat window have their style improved recently [1]: their size and aspect-ratio have changed. The aspect-ratio is intended for desktop use. In mobile, it should take whole height and width of screen. This works well in almost all browsers: `w-100 h-100` seems to take precedence over explicit aspect-ratio. On Safari however, it seems to comply with given aspect-ratio even if this means cropping the content. This is unintentional and makes chat windows barely useable. Steps to reproduce: - Open a chat window with a relatively long conversation name on safari browser in small screen => The header content on the left is cropped. This commit fixes the issue by putting the `aspect-ratio` in a non-mobile rule. That way `w-100 h-100` will be used correctly in Safari browser as in all other browsers. [1]: https://github.com/odoo/odoo/pull/188665 Before / After <img width="233" alt="Screenshot 2024-12-09 at 11 46 10" src="https://github.com/user-attachments/assets/b60a306d-1357-41cc-874e-da0529e40b4c"> <img width="233" alt="Screenshot 2024-12-09 at 11 46 32" src="https://github.com/user-attachments/assets/efd5a75a-73a8-4f79-b273-56516bd4996e">
Spellcheck indicators in the Odoo HTML editor now appear only when the user is actively focused on the editor. This keeps red spelling underlines from staying visible in places where rich text content is being viewed but not edited, making screens cleaner and less distracting.
Original PR description
This commit fixes the behavior of spellcheck on the WYSIWIG component, which previously enabled this only on focus. Since we use this element in many scenarios accross Odoo, we don't want red lines to keep their visibility all the time, when the WYSIWIG is not directly focused. ~~A test has been introduced, since the contenteditable attribute was not correctly accessed by the hook.~~
This fix updates an internal website editor test so it matches the allowed customization behavior for button styles. It helps keep quality checks active for the website editor and reduces the risk of regressions in future updates.
Original PR description
In this commit, we fix the test_tour in order to reactivate it from v18. The probleme that is fixed in this commit is that we can't customize a "secondary" button in the sidebar of web editor tools but it is allowed with "custom" button. runbot-error-id~109213 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where expanding a table in the HTML editor could cause the row picker to jump around and add rows too quickly. The table resizing controls now stay stable, making table editing smoother and less frustrating for users.
Original PR description
**Problem**: When creating a table and expanding its size, its position shifts upon reaching the window border due to the following code:…
**Problem**: When creating a table and expanding its size, its position shifts upon reaching the window border due to the following code: https://github.com/odoo/odoo/blob/1f4a85386eb258b08a3a6f43f1f3910598f005c4/addons/html_editor/static/src/core/overlay.js#L55-L57 The resize mechanism keeps the bottom of the table picker aligned with the top of the target element. When hovering over the gray square to add rows, the table expands upward (due to the position change), triggering a hover event again. This results in rapid row additions, causing the picker to jump back and forth, creating a poor user experience. **Solution**: Allow dynamic enabling or disabling of position changes during resizing, to match the fixed overlay positioning as prior versions (approved by the Product Owner). **Steps to reproduce**: 1. Open the editor and insert a table. 2. Start adding rows by hovering over the table's resize picker. 3. As the picker moves above the target element, try to hover to add more rows. 4. Observe that rows are rapidly added during mouse movement, and the picker jumps back to the bottom, causing chaotic behavior. opw-4351695 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change ensures email templates handle empty dynamic placeholders correctly by converting certain template tags into a safer format. It prevents broken rendering when a placeholder has no value, improving reliability for users editing or sending templated emails.
Original PR description
**Problem**: Self-closing `t` tags do not render properly, leading to issues in templates where the tag is opened but never closed. **Solution**: Extend the fix introduced in the following commit: https://github.com/odoo/odoo/commit/26b922ef5cad42da7e188195e919e54878d472fc to also cover `t` tags, ensuring proper conversion to open/closed tag format. **Steps to reproduce**: 1. Open Email templates. 2. Add a dynamic placeholder with no default value. 3. If the record has no value for that attribute, the `t` tag is opened but never closed, causing rendering issues. opw-4376109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where opening a project could take users straight to a new sales order form instead of the expected sales order list. The change ensures the selected project shortcut uses its own settings, so users can still navigate and adjust the project top bar as intended.
Original PR description
Before this commit, when the user creates a new billable project and change the order of the embedded actions inside the topbar of that project to put `Sales orders` embedded action first to be able…
Before this commit, when the user creates a new billable project and change the order of the embedded actions inside the topbar of that project to put `Sales orders` embedded action first to be able to load that action first, the context of that embedded action is not given the `doAction` rpc and so the view loaded in the form view of SO to be able to create a new SO. The problem is if the user does not want to create a SO, it will not be able to change the first action to load for that project since the topbar is not visible in the form view. This commit makes sure the context of the embedded action to load is given to `doAction` rpc. Steps to reproduce the issue: ============================ 1. Install Sales and project apps 2. Create new billable project 3. go inside that project to see the tasks of that project and open the top bar 4. display the `Sales Order` embedded actions inside the top bar of that project 5. reorder the embeddded actions inside the top bar to first load `Sales Order` action when we open that project. 6. Go back to the project kanban view 7. Click on that project Expected Behavior ----------------- The list view of sale.order model should be displayed Current Behavior ---------------- The form view of sale.order model is opened to be able to create a new SO for that project. task-4295738
This fix makes an automated online shop test wait for the page address to fully update before checking it. It reduces false test failures, helping teams trust release checks without changing the customer shopping experience.
Original PR description
In this commit, we fix a undeterministic behavior about check the pathname of window in function assertPathName. In this function, we check the url of the window but the url can changes few ms after the DOM has been loaded. So the check can occurs after the DOM has been loaded. To avoid this behavior, we wait for the pathname instead of check it direclty. runbot-error-id~70316
Applications received by email now create the candidate under the same company as the related job. This prevents recruitment records from being split across companies and avoids errors that could block incoming applications.
Original PR description
When an application is received through email, an `hr.candidate` is created without `company_id`. The default for this field is self.env.company. When processing an email this will be the company of OdooBot. `hr.applicant` on the other hand, will compute its default company based on the linked `hr.job`.
Because of this, it's possible that these two records are created in different companies leading to:
File ".../addons/hr_recruitment/models/hr_applicant.py", line 351, in create
raise ValidationError(_("You cannot create an applicant in a different company than the candidate"))
Fix it by creating the candidate in the same company the job is in.
opw-4384806This fix allows scheduled automated tasks to run even when assigned to a non-administrator user. It prevents jobs from failing due to overly strict permissions when recording their progress, improving reliability for routine background operations.
Original PR description
Step to reproduce: - Set any non-admin user as the cron scheduler - The cron won't run as the permission required to create the ir.cron.progress are admin Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where document actions with no group restrictions were hidden from users. These actions now correctly appear globally, helping teams access expected document workflows such as creating vendor bills.
Original PR description
**Current behavior:** Having some embedded action for `documents.document` which has no `groups_ids` set will result in that action not ever appearing in the actions bar/menu in the documents app.…
**Current behavior:**
Having some embedded action for `documents.document` which has no `groups_ids` set will result in that action not ever appearing in the actions bar/menu in the documents app.
**Expected behavior:**
In the absence of any records in the `groups_ids` relation, the actions should be exposed globally.
**Steps to reproduce:**
*`-i documents_account` for example*
1. In technical settings, open the embedded actions list view
2. Edit the `Create Vendor Bill` action so that it has an empty `groups_ids` field
3. Open the documents app, click on the finance tab on the left sidebar
4. Click on one of the demo documents, observe in the actions menu for the record that the create vendor bill action is no longer present
**Cause of the issue:**
The domain was constructed incorrectly, as the
`('field', 'in', [False] + X.ids)`
pattern does not work when `'field'` is itself a m2m recordset.
**Fix:**
Split this domain leaf into 2 so we can check for membership as well as falsy-ness.
opw-4342841Users limited to a branch company can now open contact records without being blocked by a company access error. This prevents unnecessary disruption for teams working in branch-based company setups.
Original PR description
Steps to reproduce 1. Install account_followup and contacts 2. Have a branch company 3. Have a user with only the branch in its allowed companies (setting in the "Access rights" tab) 4. With this user, go to Contacts and click on any contact. ** Access Error: Access to unauthorized or invalid companies. ** Cause Commit https://github.com/odoo/enterprise/commit/fb59524a95b0f78112002d1e4d5ad3d6c301de7e modified the way company dependent fields work, which reveals an access error issue: a user may not have access to the root company of the currently selected company. Change Currently `.with_company(self.env.company.root_id.id)` has no effect, remove it to fix access error. opw-4368736
The Knowledge app now lets users create new records from externally embedded views without hitting an error. This restores expected behavior for teams using embedded Knowledge views and prevents interruptions when adding content.
Original PR description
This commit fixes an issue with the external embedded views in Knowledge where the `New` button would raise a traceback. The issue was introduced in the big Knowledge refactor via #67083. This was caused by the action service when the doAction was called inside the createRecord of the ReadonlyEmbeddedViewComponent. The views returned by the find method called upon the action's views array were always undefined. This meant that we never found the correct view to use which raised the traceback. To fix this, the arrow function given to the find method has been updated so that it returns a correct value. task-4367683
The Documents app now silently handles cases where a document access link is used after the document has already been deleted. This prevents confusing “missing record” messages and keeps document cleanup flows smooth for users.
Original PR description
The goal of this commit is to avoid getting an error message when using the /documents/touch/ route for an access_token that no longer exists. This bug was detected in the document_delete_tour where this route is used when the document has already been deleted. This caused a "missing record" message to appear. This commit fixes this behavior.
Dragging a document shortcut to My Drive now places it in My Drive instead of leaving it in the original folder. This makes document organization behave as users expect and reduces confusion when moving shortcuts.
Original PR description
**Before this PR**: Dragging a shortcut to My Drive would create the shortcut within the current folder. **After this PR**: The shortcut will be created in My Drive, rather than remaining in the original folder. **Task**-4313298
Urban Piper order statuses in the POS ticket screen now refresh without requiring staff to reload the POS. This helps teams see when kitchen orders are completed in real time, reducing confusion and manual checks.
Original PR description
Steps to Produce: - Configure Urban Piper in your POS. - Open the particular session. - Configure preparation display. - Place test order and accept in through POS. - Order gets placed in Kitchen display. - Done the order from Kitchen Display. - Order status does not get updated in POS without reloading it. Issue: - Order status was not updated when the order was done from the Kitchen display. Fix: - Initially, only draft orders were fetched from the server but now all orders are been fetched from server that belongs to urbanPiper. task- 4320193
A timing issue in the document deletion flow was corrected so the automated deletion check waits for recent access tracking before removing items. This helps keep document deletion behavior reliable and prevents false failures in quality checks.
Original PR description
The logAccess method is a debounce function with a 1000ms delay, which is a good idea to avoid flooding the network in case a user clicks incessantly in the browser. The bug identified in the document_delete_tour tour is that this method is called AFTER the selected item has been deleted... only because of this "debounce". The tour engine is faster than the 1 second it takes µfor the debounce to be executed BEFORE the deletion of the selected document(s). The solution is therefore that this debounce is directly executed when the document deletion modal opens.
Users can now change a document or folder's parent location directly instead of relying only on drag and drop. When company folders are pinned or moved, the system better preserves the right access for previous owners or document managers without unnecessarily spreading those permissions to every child item.
Original PR description
Commit 1: Follow-up of previous owner keeps and `edit` permission on the documents set as company root. When moving a folder in Company, to pin it, and we add the previous owner or the document manager as member for them to keep access, we do not want to add the member on all children (default behavior). Adding a parameter to skip member propagation is more convenient than checking for partner existence before adding/editing them. Tests are adapted. Commit 2: It is not convenient nor necessary to restrict moving documents to using drag & drop. Note that we keep the action for the webclient as it will call action_create_shortcut or action_move_documents (with the same arguments list). Task-4365165