Friday, January 17, 2025
9 changes · 17.0
Enhancements to existing features
The follow-up level reminder tooltip has been shortened to make its message easier to understand. This improves clarity for users reviewing customer follow-up settings without changing the underlying process.
Original PR description
The tool tip is being replaced with a more concise message. task-4437887
Resolved issues and error corrections
Studio no longer shows the option to add videos when editing HTML fields, because that capability is not supported in this context. This prevents users from selecting a setting that would not work as expected and reduces confusion during page or form customization.
Original PR description
**Problem**: Enabling the addition of videos from Studio is not supported. This option should be removed. **Steps to Reproduce**: 1. In Studio, focus on any HTML field. 2. Under "Properties," there should be no "videos" option. opw-4405801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
There is already a placeholder image displayed when an image fails to load. opw-4419565 Forward-Port-Of: odoo/odoo#193825
Original PR description
There is already a placeholder image displayed when an image fails to load. opw-4419565 Forward-Port-Of: odoo/odoo#193825
Discuss calls now keep the small video preview stable when users share their screen and turn on their camera. This removes distracting flicker during call interactions, making meetings feel smoother and more professional.
Original PR description
Before this commit, during a discuss call while sharing screen and enabling camera, the inset card (= small video stream preview in bottom right of call view of the participant, either camera or screen-sharing depending on other stream being main active) was flickering. This happens because each rendering of the call view re-renders the inset, which leads to the perceived flickers from stream being re-rendered. The main cause of re-render comes from `setInset()` that is invoked whenever the `visibleMainCards` getter is called with inset, which is triggered on renderings like mouse-hovering on call view to display the call actions. Even when the inset card is unchanged, `setInset()` produces another object, which forces OWL to re-render the inset component. This commit fixes the issue by having `setInset` reusing the inset data object if the inset to render refers to the same inset session. Task-4484908
Fleet document centralization now automatically assigns the correct folder for every company, not just the main one. This prevents company-specific document settings from showing an enabled fleet option with no folder selected.
Original PR description
How to reproduce: - install stock and documents_fleet - go in the settings and chose the company "My company (Chicago)" - go to the Document settings "Centralize your Fleet' documents" is enabled but the folder is empty. This is because the fleet folder is not yet created when the ORM add the field "documents_fleet_folder" and that documents_fleet only set the folder for the main company. We solve the problem by setting the default folder in the post init hook for every company that has an empty folder. Task-4294237
Versions -------- - 16.0+ Steps ----- 1. Have a user with only access to "Sales User: Own Documents Only"; 2. open a product variant page; 3. add a comment in the chatter. Issue ----- Access Error Cause ----- Commit 35a07975deb0 added `_mail_post_access = 'read'` to the `product.template` model. This allows users with read-only access to still comment on `product.template` records. This was not done for product variants, leading to an inconsistency where an internal user ca
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a user with only access to "Sales User: Own Documents Only"; 2. open a product variant page; 3. add a comment in the chatter. Issue ----- Access Error Cause ----- Commit 35a07975deb0 added `_mail_post_access = 'read'` to the `product.template` model. This allows users with read-only access to still comment on `product.template` records. This was not done for product variants, leading to an inconsistency where an internal user can comment on product templates, but not variants. Solution -------- Add `_mail_post_access = 'read'` to `product.product` as well. opw-4189326 Forward-Port-Of: odoo/odoo#194005
In odoo/odoo#192449, we removed the only code patch we had on the IoT Box. We can then remove the patching logic. Forward-Port-Of: odoo/odoo#193935
Original PR description
In odoo/odoo#192449, we removed the only code patch we had on the IoT Box. We can then remove the patching logic. Forward-Port-Of: odoo/odoo#193935
**Problem**: When `lot['lot_record'].product_id.valid_ean` is `False`, the `final_barcode` variable retains the value from the previous iteration. This leads to incorrect concatenation with the current `lot['name']` when `lot['lot_record'].product_id.tracking == 'lot'`. **Solution**: Reset the `final_barcode` variable at the start of each iteration. **Steps to Reproduce**: 1. Go to Inventory > Settings and enable "Print GS1 Barcodes for Lots & Serial Numbers". 2. Navigate to Inventory
Original PR description
**Problem**: When `lot['lot_record'].product_id.valid_ean` is `False`, the `final_barcode` variable retains the value from the previous iteration. This leads to incorrect concatenation with the current `lot['name']` when `lot['lot_record'].product_id.tracking == 'lot'`. **Solution**: Reset the `final_barcode` variable at the start of each iteration. **Steps to Reproduce**: 1. Go to Inventory > Settings and enable "Print GS1 Barcodes for Lots & Serial Numbers". 2. Navigate to Inventory > Products > Lots/Serial Numbers. 3. Select all records and click Print > Lot/Serial Number (ZPL). 4. Observe that some barcodes incorrectly include the previous barcode as a prefix. opw-4437745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192651
Without this change it's impossible to remove the user groups from internal users, because they're being re-added upon the module updates. The reason is because there's a mechanism in place that synchronizes the newly added groups to the default user, so they're automatically added to all internal users ([ref](https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/addons/base/models/res_users.py#L621-L626)). For this reason and by convention, groups added t
Original PR description
Without this change it's impossible to remove the user groups from internal users, because they're being re-added upon the module updates.
The reason is because there's a mechanism in place that synchronizes the newly added groups to the default user, so they're automatically added to all internal users ([ref](https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/addons/base/models/res_users.py#L621-L626)).
For this reason and by convention, groups added to the default user should be non-updateable, so system administrators can remove them if they wanted to.
Related to: https://github.com/odoo/enterprise/commit/621824fb3fe1b5b895d1a37a15d45e903bc7dc6f
--
ping @tde-banana-odoo @tivisse
Forward-Port-Of: odoo/enterprise#55024