Daily updates from Odoo
Tuesday, August 13, 2024
17 changes
11 changes
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
5 changes
Enhancements to existing features
The 1099 box field is repositioned on partner records so it appears below the payment method field. This keeps related payment and tax reporting information grouped together, making the form easier to read and complete.
Original PR description
In this commit:https://github.com/odoo/odoo/pull/174537/commits/09d2b29e14425c1e333bbe4ae6e5caa2e6361f9f We moved the field property_payment_method_id into the account module and we want it to be below the payment terms in the res_partner view. This commit will change the xpath so that the field box_1099_id is now below the payment method field. task: 4016652
Planning warnings for single-day time off are now shorter and easier to read. Instead of repeating the same date twice, the message shows the leave date once and includes custom hours only when relevant.
Original PR description
Before this commit even if there was a single day leave the warning would read as "Person is on leave from 12/7/21 (fromTime) to 12/7/21 (toTime)". After this commit if leave is of single day type then the warning would be read as "Person is on leave on 12/7/21 (fromTime to toTime)". If Time is not custom hours the warning would be read as "Person is on leave on 12/7/21" Here fromTime and toTime are subject to availabilty. task-3887999
Payment follow-up email templates no longer include the customer's general partner address by default. This keeps reminders focused on the designated follow-up contact, reducing confusion and helping messages go to the right recipient.
Original PR description
Since https://github.com/odoo/enterprise/pull/61861, we include the template partners and email addresses, but Payment followup typically uses the followup contact's email address, and doesn't need partner's address in the template Found due to OPW-3988791
Miscellaneous changes
Where possible, we make the eTIMS-specific fields and buttons invisible unless the company has Kenya as fiscal country. Exceptions to this are: - the buttons on partner and user form views. We don't have a way of showing them only if the currently selected company is Kenyan. However, they are already visible only in debug mode, so this isn't too much of a problem. - the 'Custom Imports' menuitem - we don't have a way of making it conditionally visible. Forward-Port-Of: odoo/enterprise#6690
Original PR description
Where possible, we make the eTIMS-specific fields and buttons invisible unless the company has Kenya as fiscal country. Exceptions to this are: - the buttons on partner and user form views. We don't have a way of showing them only if the currently selected company is Kenyan. However, they are already visible only in debug mode, so this isn't too much of a problem. - the 'Custom Imports' menuitem - we don't have a way of making it conditionally visible. Forward-Port-Of: odoo/enterprise#66905
Issue ----- Trial report assumes the `comparison` key exists when generating report options. However, that won't be the case if `filter_period_comparison` (Period Comparison option) is false. Steps ----- - Go to Accounting -> Configuration -> Accounting Reports. - Choose Trial Balance then go to Options and disable 'Period Comparison'. - Now generate a trial balance report by going to Reporting -> Audio Reports -> Trial Balance. - A `KeyError` is thrown. opw-3991886 Forward-Po
Original PR description
Issue ----- Trial report assumes the `comparison` key exists when generating report options. However, that won't be the case if `filter_period_comparison` (Period Comparison option) is false. Steps ----- - Go to Accounting -> Configuration -> Accounting Reports. - Choose Trial Balance then go to Options and disable 'Period Comparison'. - Now generate a trial balance report by going to Reporting -> Audio Reports -> Trial Balance. - A `KeyError` is thrown. opw-3991886 Forward-Port-Of: odoo/enterprise#68000 Forward-Port-Of: odoo/enterprise#66049
1 change
Resolved issues and error corrections
This update fixes the "Add to Dashboard" dialog in the Spreadsheet Dashboard Documents feature by removing an unnecessary external link button. The change simplifies the dialog interface, making it cleaner and more focused on the primary action of adding content to dashboards.
Original PR description
The PR hides the M2O external button in the "Add to Dashboard" dialog by passing the 'no_open' option to the widget. Task: [4066519](https://www.odoo.com/odoo/project/2328/tasks/4066519?cids=2)