Daily updates from Odoo
Tuesday, August 13, 2024
13 changes · saas-17.2
Resolved issues and error corrections
Fixes the mailing template editor so it resizes to the template content instead of leaving extra blank space or making the snippet panel hard to use. This improves the email campaign editing experience, especially when working with very small or large templates.
Original PR description
Purpose ======= Fix the height of the mail templates in the mailing form. Specification ============= For small templates / theme selector, there is a blank space below the editor because the…
Purpose ======= Fix the height of the mail templates in the mailing form. Specification ============= For small templates / theme selector, there is a blank space below the editor because the iframe's height is matching the full height of the website snippets on the side. For big templates, the website snippets doesn't follow the template scrolling which makes it difficult to drag and drop the snippets. This happens following the removal of the full width view and a related js file which was previously resizing the editor height accordingly (ref commit: https://github.com/odoo/odoo/commit/cf6cd5ef46287f4e71fe96ad6b404ba9b08c1066 ) Reverting a part of the old "mailing_mailing_view_form_full_width" file into the "mass_mailing_html_field" one so that the editor iframe is correctly resized depending on its content and the editor sidebar is correctly resized to follow the scrolling behavior. Concretely, introducting back the resize observer and the "_updateIframe", "_isFullScreen", "_resizeMailingEditorIframe" and "_repositionMailingEditorSidebar" methods. Task-4086341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Presence status updates are now sent only to users who share a chat or channel with the person whose status changed. This reduces unnecessary client-server traffic and should improve performance without changing the visible messaging experience.
Original PR description
Since [1], presences are only sent when necessary. This PR greatly reduced the traffic between client and server. This PR is a follow-up to reduce the traffic between server and client: the presences should only be sent to people sharing a chat or channel with the presence user. [1]: https://github.com/odoo/odoo/pull/174814 enterprise: https://github.com/odoo/enterprise/pull/68022
Miscellaneous changes
### Description of the issue/feature this PR addresses: In Odoo 15, only stock.group_stock_manager can use the Lock and Unlock button on stock.move ( https://github.com/odoo/odoo/blob/b361be31e446919ffc0ee14e99f8b88fae630ede/addons/stock/views/stock_picking_views.xml#L257 ) When moving the button to an ir.actions.server, the group_ids was not ported properly in #116799 . This commit fixes it and restore the group restriction ### Current behavior before PR: Users without the group `
Original PR description
### Description of the issue/feature this PR addresses: In Odoo 15, only stock.group_stock_manager can use the Lock and Unlock button on stock.move ( https://github.com/odoo/odoo/blob/b361be31e446919ffc0ee14e99f8b88fae630ede/addons/stock/views/stock_picking_views.xml#L257 ) When moving the button to an ir.actions.server, the group_ids was not ported properly in #116799 . This commit fixes it and restore the group restriction ### Current behavior before PR: Users without the group `stock.group_stock_manager` (Administrator) can lock/unlock stock.picking ### Desired behavior after PR is merged: Only users with that group can lock/unlock stock.picking opw-4075127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176442
Current behavior before PR: - Selecting the last text of a paragraph and applying hex color on it resulted in a traceback. - Selecting the initial text of a long paragraph and applying hex color resulted in unintended coloring of other unselected text. Desired behavior after PR is merged: - Applying a hex color on text will no longer lead to a traceback. - Only the selected text will be colored. task-3578454 Forward-Port-Of: odoo/odoo#174039 Forward-Port-Of: odoo/odoo#158006
Original PR description
Current behavior before PR: - Selecting the last text of a paragraph and applying hex color on it resulted in a traceback. - Selecting the initial text of a long paragraph and applying hex color resulted in unintended coloring of other unselected text. Desired behavior after PR is merged: - Applying a hex color on text will no longer lead to a traceback. - Only the selected text will be colored. task-3578454 Forward-Port-Of: odoo/odoo#174039 Forward-Port-Of: odoo/odoo#158006
This solve 2 problems: -------------------- * Singleton Error: - STEP TO REPRODUCE: Go to tree view mode of task, press New to create a new Task, input 'description' -> Save -> Then edit its description again -> Save -> View history revision -> Error - Solution is to ensure 'recordId' has value when opening History Dialog * Wrong resId when switching task: - when you have 2 tasks, and you navigate between them, this.props.resId will usually be the one for the first task, so
Original PR description
This solve 2 problems: -------------------- * Singleton Error: - STEP TO REPRODUCE: Go to tree view mode of task, press New to create a new Task, input 'description' -> Save -> Then edit its description again -> Save -> View history revision -> Error - Solution is to ensure 'recordId' has value when opening History Dialog * Wrong resId when switching task: - when you have 2 tasks, and you navigate between them, this.props.resId will usually be the one for the first task, so the history is wrong when we navigate between tasks, Instead we use this.model.root.resId Video to reproduce on runbot saas-17.1 https://github.com/odoo/odoo/assets/56789189/1cfd2dd8-a80e-4bdd-aac4-82856eadc8de --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171090
Before this commit, performing a cash in/out operation in a session without any other cash transactions would result in the cash in/out not appearing in the report. It will become like this:  opw-4076188 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175364
Original PR description
Before this commit, performing a cash in/out operation in a session without any other cash transactions would result in the cash in/out not appearing in the report. It will become like this:  opw-4076188 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175364
### Steps to reproduce: 1. Create a storable product and set the quantity on hand to 100 units 2. Create a delivery of 20 units and mark as to-do 3. In the detailed operations, change the quantity to 10 units 4. Validate the transfer without backorder 5. Go to Inventory > Reporting > Locations 6. Click on Inventory at Date, and select a date one month in the past 7. The on hand quantity for the product is 10 ### Before this commit: When viewing a product's quantity in the past, the va
Original PR description
### Steps to reproduce: 1. Create a storable product and set the quantity on hand to 100 units 2. Create a delivery of 20 units and mark as to-do 3. In the detailed operations, change the quantity to 10 units 4. Validate the transfer without backorder 5. Go to Inventory > Reporting > Locations 6. Click on Inventory at Date, and select a date one month in the past 7. The on hand quantity for the product is 10 ### Before this commit: When viewing a product's quantity in the past, the value was based on the `product_qty` of the done stock moves. However, this is the demand, and it is not always equals to the quantity that moved. ### After this commit: Use the quantity of the done stock move lines, which reflect better what really moved in the past. opw-3946354 Forward-Port-Of: odoo/odoo#168456
Before this commit: When a form view was set to non-editable (edit="0"), its x2many fields could still contain editable boolean fields (e.g., Boolean Toggle). After this commit: Boolean fields within x2many fields are now also read-only when the form view is non-editable. Task-3802653 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 ww
Original PR description
Before this commit: When a form view was set to non-editable (edit="0"), its x2many fields could still contain editable boolean fields (e.g., Boolean Toggle). After this commit: Boolean fields within x2many fields are now also read-only when the form view is non-editable. Task-3802653 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 Forward-Port-Of: odoo/odoo#174989
- Go to Project App; - Add a task in any project; - Move the task to "Cancelled State"; - Click on the progress bar above the stage. Before this commit, the task will get hidden but load more button appears. This occurs because the group bar, and the progress bar are out of sync with the latest search read (executed when clicking on a progress bar). Now, when filtering the progress bar is updated, and when removing the filtering the group count is updated, this maintains a correct synch
Original PR description
- Go to Project App; - Add a task in any project; - Move the task to "Cancelled State"; - Click on the progress bar above the stage. Before this commit, the task will get hidden but load more button appears. This occurs because the group bar, and the progress bar are out of sync with the latest search read (executed when clicking on a progress bar). Now, when filtering the progress bar is updated, and when removing the filtering the group count is updated, this maintains a correct synchronization between the current showing records and the group count and the progress bar. Note that, this commit also prevents to shown negative values for the "Other" progress bar. opw-3935547 Forward-Port-Of: odoo/odoo#176511
### Steps to reproduce: - Enable Multi-Step Routes and Batch Transfers in the settings - Inventory > Configuration > Warehouse Management > Operation Types - Click on internal transfer: Enable Auomatic batches group by dest - Create a internal transfer with two moves: 1 x screw and 1 x bolt - Mark the transfer as Todo, duplicate it and `mark as Todo` > the two transfers should be added to a batch - In the barcode app, batch transfers, go on your batch - Add a single screw and validate
Original PR description
### Steps to reproduce: - Enable Multi-Step Routes and Batch Transfers in the settings - Inventory > Configuration > Warehouse Management > Operation Types - Click on internal transfer: Enable…
### Steps to reproduce: - Enable Multi-Step Routes and Batch Transfers in the settings - Inventory > Configuration > Warehouse Management > Operation Types - Click on internal transfer: Enable Auomatic batches group by dest - Create a internal transfer with two moves: 1 x screw and 1 x bolt - Mark the transfer as Todo, duplicate it and `mark as Todo` > the two transfers should be added to a batch - In the barcode app, batch transfers, go on your batch - Add a single screw and validate > A pop up appears to tell you that the rest will be backordered - Validate ### Bug: Instead of being redirected to the barcode app, you are left on the old version of the batch. If you go back the barcode app you will see that your old batch is actually empty (0 lines) and its state is "in progress" instead of being done. If you click on the the empty batch you get a traceback since its picking_type is nowhere to be found by owl ### Cause of the issue: When you added your screw via the barcode app, you marked the move of the picking as picked. When you validated the batch, you are going to mark this move as done and to back order its picking since only part of it was completed. However, since one of its move is 'done' and the other one is 'assigned', its state will not be done and the picking to backorder will be removed from the original batch y these lines: https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L140-L144 It would make sense if the the other pickings were to stay in the batch, which is what the "any" part of the if condition is trying to check. However the other picking of the batch is going to be removed later by these lines (since none of its move are picked so that it is considered to be empty): https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking_batch.py#L233-L234 https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L120-L121 This is the cause of all the issues since the old batch is now emptied from all of its picking so that its state will stay in progress and its picking_type_id can't be found from its pickings. ### Expected behavior: The part of the picking that was marked as done should have stayed in the old batch. ### Fix: The any part of this if condition should take into account the pickings that are going to be detached from the batch. https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L140-L144 opw-4088846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176121
Oversight from task-3637983 (https://github.com/odoo/odoo/pull/161265) task-4104583 Forward-Port-Of: odoo/odoo#176224 Forward-Port-Of: odoo/odoo#176147
Original PR description
Oversight from task-3637983 (https://github.com/odoo/odoo/pull/161265) task-4104583 Forward-Port-Of: odoo/odoo#176224 Forward-Port-Of: odoo/odoo#176147
To reproduce the bug: - Add extra step during checkout - Make Sign in/up at check out Mandatory - Add a non-service product to the cart without being logged in and proceed to checkout - Create an account and once logged in continue the checkout process normally until payment is done When the process is done, a request is sent to /shop/payment/validate, and we get a server error message since we try to fetch `sale_last_order_id` from the session but it's not set. To simplify, the buying
Original PR description
To reproduce the bug: - Add extra step during checkout - Make Sign in/up at check out Mandatory - Add a non-service product to the cart without being logged in and proceed to checkout - Create an account and once logged in continue the checkout process normally until payment is done When the process is done, a request is sent to /shop/payment/validate, and we get a server error message since we try to fetch `sale_last_order_id` from the session but it's not set. To simplify, the buying process goes like this: cart > [sign in/up] > [delivery] > checkout > extra_step or confirm_order > payment. The issue is that `sale_last_order_id` is set in confirm_order, which we don't pass through if we have extra_step enabled. To fix that, I moved the set operation a step earlier. opw-3988807 Forward-Port-Of: odoo/odoo#174638
In order to be more accessible, commit [1] allowed the hoverable menus to have an outline when they are focused by using the Tab key. When hovering these menus with the mouse, the outline should not appear, unless it was already focused (with the Tab key). Also, when hovering, the focus should stay on the already focused element. This last part causes some issues: indeed, the focus is kept by calling the `focus` function and the issue with it is that it scrolls to the element on which it is c
Original PR description
In order to be more accessible, commit [1] allowed the hoverable menus to have an outline when they are focused by using the Tab key. When hovering these menus with the mouse, the outline should not…
In order to be more accessible, commit [1] allowed the hoverable menus to have an outline when they are focused by using the Tab key. When hovering these menus with the mouse, the outline should not appear, unless it was already focused (with the Tab key). Also, when hovering, the focus should stay on the already focused element. This last part causes some issues: indeed, the focus is kept by calling the `focus` function and the issue with it is that it scrolls to the element on which it is called. This made the screen scroll unexpectedly anytime we hovered a hoverable menu, to bring the focused element into view. This commit fixes this issue by specifying that the screen should not scroll when focusing the element. Steps to reproduce: - In the menu editor, add some submenus. - In edit mode, click on the header and set the "Sub Menus" option to "On Hover" and the "Scroll Effect" option to "Scroll". - Go to the "/shop" page. - In edit mode, add the cart button on the products and then save. - Scroll down the page and add a product to the cart. - Scroll up the page and hover the menu with a submenu. => The page scrolls down to the product we just added, since it was the focused element. [1]: https://github.com/odoo/odoo/commit/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4 opw-4069610 Forward-Port-Of: odoo/odoo#175710