Daily updates from Odoo
Thursday, June 5, 2025
16 changes
3 changes
Resolved issues and error corrections
The asset depreciation schedule header now correctly matches the number of columns shown in the report. This prevents a small visual layout issue and keeps the report easier to read for users reviewing asset depreciation details.
Original PR description
A previous fix removed one column without updating the colspan of the custom header. https://github.com/odoo/enterprise/commit/78265a864fafd789df10c0f75590aaa605547b33
This change updates WhatsApp-related automated tests to match a recent change where channel access settings moved into a popup menu. It helps keep quality checks reliable without changing day-to-day user behavior.
Original PR description
Purpose of this commit: After [1], the channel access setting have been add inside into a popup menu, adapt the conflicting testcases accordingly. [1] odoo/odoo#178313 task-4100138 Backport of https://github.com/odoo/enterprise/pull/73626
This fixes the Discuss app so chat hub options no longer appear in places where they are not usable. Users get a cleaner interface and avoid confusion from actions that should only be available in chat windows.
Original PR description
https://github.com/odoo/odoo/pull/212452
2 changes
Resolved issues and error corrections
Spreadsheet cell comment windows now use the right reply box layout, preventing duplicate send buttons and confusing keyboard shortcuts. This makes commenting on spreadsheet cells more consistent and easier to use.
Original PR description
## Description This PR changes the props passed to the composer by avoiding the use of `mode: 'extended'` when `inChatWindow: true` is set. That combination caused UI inconsistencies such as duplicate send buttons and conflicting keyboard shortcuts. The chat window is meant to use the compact composer/normal configuration for proper styling and expected behavior. Task: [4727169](https://www.odoo.com/odoo/project/2328/tasks/4727169)
This update adjusts automated WhatsApp-related tests to match a recent change where channel access settings moved into a popup menu. It helps keep quality checks reliable without changing the user-facing WhatsApp features themselves.
Original PR description
Purpose of this commit: After [1], the channel access setting have been add inside into a popup menu, adapt the conflicting testcases accordingly. [1] odoo/odoo#178313 task-4100138
11 changes
Resolved issues and error corrections
This fixes an issue in the Mail module where replacing an item in a linked list could leave the old item connected and fail to connect the new one correctly. The change helps keep message-related data relationships accurate and prevents follow-up inconsistencies after edits.
Original PR description
Before this commit, when a Many field has a One inverse, assigning on the many field in a specific index lead to a crash. The crash was fixed by https://github.com/odoo/odoo/pull/212963 But the resulting relations were still incorrect: the old record still was linked in the relation, and the new record was not properly linked in the inverse field. This was happening due to similar typo in the inner code of JS models: deletion and addition of respectively old and new records were done with respectively `recordList.delete(recordList)` and `recordList.add(recordList)`. The error comes from passing `recordList` instead of `recordList._.owner`, i.e. the old/new records. The typo comes from `RecordUses` that also have methods `add` and `delete` and have `recordList` as 1st param. FYI, `RecordUses` is used for very-low level internal links of record being used by other records. Semantically this is like a relational field but the shape differs for improved computational complexity.
This fix ensures the website payment donation test runs reliably even when demo data is not installed. It helps keep automated checks stable for custom builds without changing customer-facing payment or donation behavior.
Original PR description
Commit [1] added the use of the portal user in test_01_donation. Its forward-port at [2] was adapted so that it works without demo data, and more, as it became the new default in that version. But [1] still made our test fail in some custom non-demo runbot builds. This commit fixes that by backporting the relevant parts of [2]. [1]: https://github.com/odoo/odoo/commit/4229a3f68e17f05b75bd13347589497682575bd0 [2]: https://github.com/odoo/odoo/commit/c4418cdbf82627fa7c0dc43087de790d61c01208 runbot-223118
The HTML editor now safely handles attempts to crop external images, which cannot be cropped. Instead of causing an error, it closes the cropper and shows a clear notification that the image type is not supported.
Original PR description
**Current behavior before PR:** Steps to reproduce the issue: - Upload an external image. - Click on it to open the toolbar. - Try to open image cropper. - Clicking on "Apply" button leads to traceback. This issue happens because after merging this commit [1] `closeCropper` method closes the cropper only if `cropperOpen` flag is true. In case of external image, cropper should be closed before it gets fully mounted as such images are uncroppable. In this case `cropperOpen` flag is false and `closeCropper` fails to close cropper which results in traceback later. **Desired behavior after PR is merged:** Cropper gets closed in case of external image and there is a toaster notification at the top-right showing "This type of image is not supported for cropping". [1]: https://github.com/odoo/odoo/commit/df64afb4e9504413f966a153772c568b625a5e13 task-4677287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where the deadline date picker could remain visible after users navigated away from a task using the browser back button. The change ensures the pop-up is properly tied to the page component lifecycle, improving the user experience and avoiding stray interface elements.
Original PR description
Steps to reproduce ================== - Go to project - Open a project - Open a task - Click on the deadline field - Go to the previous page using the browser back button => The datepicker stays open Cause of the issue ================== `datetimePicker.create` was called using three parameters. But since bb1f912f04fbc4b1efe57847bceffce5895ced9b, it only accepts two. Solution ======== `createPopover` should be added to the `hookParams` This allows the popover to be closed when the owner component is destroyed. https://github.com/odoo/odoo/blob/bb1f912f04fbc4b1efe57847bceffce5895ced9b/addons/web/static/src/core/popover/popover_hook.js#L65 opw-4811594
This update corrects an automated test related to flexible time off expiration rules. It helps ensure the Human Resources time off module remains reliable when validating leave balance behavior.
This fix improves validation of domain filters when expressions are not allowed. It now detects invalid expressions inside nested filter sections, helping users catch configuration mistakes before they cause incorrect behavior.
Original PR description
If allowExpressions = false, the domain field is supposed to detect when expressions are used in the domain and notify the user that the domain is invalid. The current version of domainContainsExpressions do not allow detection of expressions in sub domains used in conjunction with the any operator. We fix that.
This fixes an issue where some sales order lines could have no product name in the first line. It helps ensure sales orders display correctly and avoids confusion when reviewing order details.
Original PR description
Finetuning of 47d223759f07c6b393f8fb6b031fd9d8b1acc1a6 Some lines might not have a product in the first line. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Scheduled messages sent from the chatter now correctly carry over the subject entered by the user. This prevents recipients from receiving emails with a missing or incorrect subject when scheduled messages are sent immediately.
Original PR description
Steps to reproduce =================== 1. Open a record with chatter, and open the full composer. 2. Add a custom subject and add a body. 3. Schedule message to send in the future. 4. Click on send now from chatter. => Subject is not propagated to the mail After this commit ================= This commit propagate subject to mail. Task-4845440
Fixes an issue in the mail module where replacing an item in a related record list could delete the wrong underlying record. This improves data reliability for features built on Odoo's mail-related JavaScript models without changing user workflows.
Original PR description
Before this commit, when defining a `fields.Many()` in JS models with an inverse as `fields.One()`, assign a new record on index of the `Many()` field leads to erroneously record deletion. This…
Before this commit, when defining a `fields.Many()` in JS models with an inverse as `fields.One()`, assign a new record on index of the `Many()` field leads to erroneously record deletion. This happens because when record list changes, it should sync the inverse relation by deleting the old record from the record list. In the internal code of JS models, all relational fields are stored as recordList, and the removal of a record from a relational field is made with recordList.delete(). In business code, Many fields values are returned as recordList, but One fields are returned as record or undefined. The recordList is not exposed. When the inner-code has to retrieve the record list of the relational field, it should make sure to use raw accessors rather than proxy accessors. Due to a typo in internal code of JS models, it retrieved the record rather than the record list of the One relational field, and thus called `record.delete()` instead of `recordList.delete()`, which lead the bug at hand. This commit fixes the issue by ensuring proper access to relational field to retrieve the record list even with One relational fields. The `toRaw()._raw` is to "remove" the proxy layer so we retrieve the raw object of relation which is always the record list for all relational fields.
Changing a company's country-specific VAT label now reliably updates the label shown on contact forms. This prevents users from seeing outdated form labels after configuration changes, reducing confusion and ensuring the interface matches the saved settings.
Original PR description
**PROBLEM** When changing the vat label associated to the country of the user's company, it should change the label of the `vat` field. The cached partners views are not invalidated as they should…
**PROBLEM** When changing the vat label associated to the country of the user's company, it should change the label of the `vat` field. The cached partners views are not invalidated as they should and the old views with the old label are presented to the user instead of the new ones. This can be confusing to the user, because while their change had an effect on the database, it doesn't reflect on the views showed to them. **STEP TO REPRODUCE** 1. On a fresh database, install the contact app. 2. From the contact app, Configuration->Countries, select United States which should be the country of the demo company. 3. Change the Vat Label field value. 4. Go on any contact form view, and notice the label of the `vat` field wasn't updated. 5. You can refresh the pages, and sometimes the new value will be there, sometimes not. **CAUSE** https://github.com/odoo/odoo/blob/ac106704f3c2d3e3fa94415134b9d5522b325378/odoo/addons/base/models/res_partner.py#L41C1-L55C1 In the mixin `FormatVATLabelMixin` we modify the form view, changing the label of the vat field accordingly. However, the `_get_view_cache_key` override that would add the field used to make the change (`self.env.company.country_id.vat_label`) to the cache key is missing. Which means the cache isn't invalidated when it should. **FIX** Add the `_get_view_cache_key` override to invalidate the cache when needed. opw-4825749
This fixes an issue where switching to the Follow-up Report from a customer statement could fail if journal filters had been cleared. Accounting users can now change reports more reliably without encountering an unexpected error.
Original PR description
When executing follow-up actions, a KeyError could occur if the 'journals' key was missing from the options dictionary Steps to reproduce: Go to Accounting > Reports, open the Follow-up Report, and click Options. Untick journals so that the 'journals' list is effectively removed. Go to Customers, select any customer, Click on Customer Statement. Try to change Report (up right) to Follow_Up Report OPW-4798813