Thursday, May 30, 2024
25 changes · saas-17.1
Resolved issues and error corrections
The portal task view now shows timesheet progress as a rounded number instead of displaying excessive decimal places. This makes project task information cleaner and easier for customers and portal users to read.
Original PR description
Steps to reproduce:
- Install the hr_timesheet module.
- Create a Project with timesheets selected.
- Create a Task and set the allocated time to 5.
- Add a timesheet entry with hours set to 23.
- Open the task in the portal view.
Currently, the progress field value is not rounded, and a large number of decimal places are
displayed in the portal view. We have fixed this issue by adding the float widget.
task-3888878Debit notes in India GSTR-1 reports are now shown with positive values in the relevant spreadsheet sections. This improves report accuracy and adds test coverage to help prevent the issue from returning.
Original PR description
**Before this PR:** - The test case for a debit note in GSTR-1 was missing. - Values for debit notes in the CDNR and CDNUR categories in the GSTR-1 spreadsheet were negative. **After this PR:** - Added the test case for a debit note in GSTR-1. - Corrected the GSTR-1 JSON to display positive values for debit notes in the CDNR and CDNUR categories in the GSTR-1 spreadsheet. **task**-3892512
Miscellaneous changes
0a0c931 and https://github.com/odoo/enterprise/commit/58f4287a171df1b13f80e7b23675bcec6a5b2a6c added the key 'lot_id' to all `_get_invoiced_lot_values` methods. But point_of_sale uses a different model (`pos.pack.operation.lot`) than stock does (`stock.lot`). Using the same key for two different model is confusing, hence we use another key for the `pos.pack.operation.lot`. opw-3847889 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-p
Original PR description
0a0c931 and https://github.com/odoo/enterprise/commit/58f4287a171df1b13f80e7b23675bcec6a5b2a6c added the key 'lot_id' to all `_get_invoiced_lot_values` methods.
But point_of_sale uses a different model (`pos.pack.operation.lot`) than stock does (`stock.lot`).
Using the same key for two different model is confusing, hence we use another key for the `pos.pack.operation.lot`.
opw-3847889
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#167123Before this commit: Whenever an user creates Stock E-waybill with Document Type as `Delivery Challan (Sub-Type: Others)` and clicks on the Generate E-waybill button we get the following error: `(377) Sub Supply Type mentioned as Others the description for that is mandatory` The problem was that we did not send the `type_description` field value in the json when the Sub Supply Type is Others After this commit: We send the `type_description` field value to the ewaybill json when the Sub Su
Original PR description
Before this commit: Whenever an user creates Stock E-waybill with Document Type as `Delivery Challan (Sub-Type: Others)` and clicks on the Generate E-waybill button we get the following error: `(377) Sub Supply Type mentioned as Others the description for that is mandatory` The problem was that we did not send the `type_description` field value in the json when the Sub Supply Type is Others After this commit: We send the `type_description` field value to the ewaybill json when the Sub Supply Type is Others which resolves the above error task-3956811 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167196
With an Uganda company setup Create an invoice to Uganda customer Try to register a payment Error "You can't register payments for both inbound and outbound moves at the same time" This occurs because the Taxes payable account type is set to Liability Payable, so the tax line will be detected as possible receivable by the payment wizard creating the issue opw-3944574 Forward-Port-Of: odoo/odoo#166556
Original PR description
With an Uganda company setup Create an invoice to Uganda customer Try to register a payment Error "You can't register payments for both inbound and outbound moves at the same time" This occurs because the Taxes payable account type is set to Liability Payable, so the tax line will be detected as possible receivable by the payment wizard creating the issue opw-3944574 Forward-Port-Of: odoo/odoo#166556
Bug: Invoices created for sales orders generated by a repair order didn't show SN/lot number for products that are tracked when activating "Display Lots & Serial Numbers on Invoices" setting. This was because the method generating the lots for the report only included stock move lines that had `customer` in its source or destination location usage, which is not the case in the move lines of a repair order. Fix: Exclude repair move lines from this check. Task-3848611 --- I confirm I h
Original PR description
Bug: Invoices created for sales orders generated by a repair order didn't show SN/lot number for products that are tracked when activating "Display Lots & Serial Numbers on Invoices" setting. This was because the method generating the lots for the report only included stock move lines that had `customer` in its source or destination location usage, which is not the case in the move lines of a repair order. Fix: Exclude repair move lines from this check. Task-3848611 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167187 Forward-Port-Of: odoo/odoo#166979
Description of the issue/feature this PR addresses: If the user has two invoices/bills selected where one falls within the parameters of a discounted payment and the other does not, the calculated payment total and payment difference will be wrong. Current behavior before PR: If I have two Bills, both for $25.00 where one falls within the parameters of a discount for 2% in 10 Days and the other doesn't, and I select both of them and click register payment, and the select "Group Payments" (g
Original PR description
Description of the issue/feature this PR addresses: If the user has two invoices/bills selected where one falls within the parameters of a discounted payment and the other does not, the calculated…
Description of the issue/feature this PR addresses: If the user has two invoices/bills selected where one falls within the parameters of a discounted payment and the other does not, the calculated payment total and payment difference will be wrong. Current behavior before PR: If I have two Bills, both for $25.00 where one falls within the parameters of a discount for 2% in 10 Days and the other doesn't, and I select both of them and click register payment, and the select "Group Payments" (group_payment), the "Amount" (amount) will be $0.50 and the Payment Difference (payment_difference) will be $49.50. Desired behavior after PR is merged: In the same scenario, I would expect the "Amount" to be $49.50 and the "Payment Difference" to be $0.50 To Reproduce: - Create Payment Term "2% 10, Net 30" this payment term should be configured to have a discount of 2% if paid in the first 10 days, and then 100% of the bill is due in 30 Days. - Create two Purchase Orders (doesn't matter which products you purchase), receive products, and create bills. Make sure one has the new payment term you created and its bill date puts it within the discount parameters. The other bill should either have a different payment term that doesn't have a discount or the same term but not be within the parameters to have the discount apply (bill is older than 10 days in this case) - Go to Accounting --> Vendors --> Bills and select both of these new bills and click "Register Payment" - In the wizard, click "Group Payments" and you will see the amount and payment difference are incorrect. **This process can also be done with sale orders instead, you will get the same result with two invoices for customers. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165539
Steps to reproduce: 1- For the "Google Map" Block: - Go to a website page (in "edit" mode) > Drop a "Google Map" block. - Set the Google project API key and click on "Save" > The dialog is still visible with the "Save" button disabled > We have to reload the page manually to be able to add the snippet. - Add a dynamic snippet (product block, event, etc) right after the map. - Save > Traceback shown and we cannot edit the page anymore. 2- For the "Tab" block: - Go to a webs
Original PR description
Steps to reproduce: 1- For the "Google Map" Block: - Go to a website page (in "edit" mode) > Drop a "Google Map" block. - Set the Google project API key and click on "Save" > The dialog is still…
Steps to reproduce: 1- For the "Google Map" Block: - Go to a website page (in "edit" mode) > Drop a "Google Map" block. - Set the Google project API key and click on "Save" > The dialog is still visible with the "Save" button disabled > We have to reload the page manually to be able to add the snippet. - Add a dynamic snippet (product block, event, etc) right after the map. - Save > Traceback shown and we cannot edit the page anymore. 2- For the "Tab" block: - Go to a website page (in "edit" mode) > Drop a "Tabs" block. - Set its Style to "Tabs" > Insert a dynamic content products block inside each of the tabs block. - When trying to add a new tab to the tabs block, there is an uncaught promise error. Technical explanation: On "Google Maps" block: [A]: The Google Maps script has an `odoo_gmap_api_post_load()` function as a callback when the library is loaded. This function will automatically call `_startWidgets()` for all widgets in the DOM (which is a very strange behaviour). [B]: If one of the blocks in the DOM is a dynamic snippet, the `DynamicSnippet` public widget that handles the block will set a "resize" handler on `start()` and remove it on `destroy()`. But with the behaviour from [A], the external `_startWidgets()` will destroy the widget even if its `start()` process is not fully completed, and the code will try to call a "resize listener removal" function that is not initialized yet. Which explains the traceback. On "Tabs" block: [C]: The fix from [1] was added to restore the handling of event for cloned snippets that were lost after moving the event handling to the `wysiwyg_adapter`. One of these listeners notifies stops the public widgets inside the snippet that is about to be cloned. This behaviour triggers the same issue as [B] when the block contains a dynamic snippet. On Google Maps API key dialog: [D]: After [2], website legacy dialogs (including `s_google_map_modal`) were replaced with OWL dialogs… In this new code, the dialog needs to be closed when the API key is valid to prevent the blocked UI and allow the dialog promise to be resolved when setting the Google Maps key. The goal of this commit is to prevent the behaviour from [B] & [C] by only restarting the map widgets when the Gmap library is loaded (an extra check was added on the `DynamicSnippet` to prevent triggering the same behaviour by another external `_startWidgets()`). Also, the `GoogleMapAPIKeyDialog` will be closed in `onClickSave()` to fix the behaviour from [D]. [1]: https://github.com/odoo/odoo/commit/24ca4ae3fbe9b25eb502e0a293a3dcab31ce8857 [2]: https://github.com/odoo/odoo/commit/57ed8bc0bf9d1ae2b7542d677a4d7e8fd1899ea2 opw-3879971 opw-3895730 Forward-Port-Of: odoo/odoo#165297
When you have many UTM values (campaign, medium, source), the link tracker screen was simply not possible to use: 1. The page loading is slow, indeed we loaded all the values during the page load, even after javascript lazy loading. 2. The select2 lib (that we are currently getting rid of) simply cannot handle searches in pre-loaded large dataset. It probably creates many DOM elements which make the screen freeze. 3. If you search for "Roadshow" as an UTM campaign but you have many camp
Original PR description
When you have many UTM values (campaign, medium, source), the link tracker screen was simply not possible to use: 1. The page loading is slow, indeed we loaded all the values during the page load, even after javascript lazy loading. 2. The select2 lib (that we are currently getting rid of) simply cannot handle searches in pre-loaded large dataset. It probably creates many DOM elements which make the screen freeze. 3. If you search for "Roadshow" as an UTM campaign but you have many campaigns called "Roadshow XXX", it is impossible to find the exact match "Roadshow" if it was created after. To solve all of that: 1. We do not preload anything. 2. We query the database after each user search, with a small enough (still big though) limit. 3. We order results by size and with "results that start with the search term" first, basically making any exact match first, followed by closest matches. task-3933262 Forward-Port-Of: odoo/odoo#166388
How to reproduce the issue: - create a leave type that allows negative amounts - create an accrual plan (demo seniority plan works) - create an accrual allocation for an employee on the leave type - set the number of days to 1 - go on the employee dashboard for time off - create a leave in the near future (in the current month) - create a second leave in the same period - ensure with the balance on the day of the latest leave that the balance is negative - run the cron "Time Off: Cance
Original PR description
How to reproduce the issue: - create a leave type that allows negative amounts - create an accrual plan (demo seniority plan works) - create an accrual allocation for an employee on the leave type - set the number of days to 1 - go on the employee dashboard for time off - create a leave in the near future (in the current month) - create a second leave in the same period - ensure with the balance on the day of the latest leave that the balance is negative - run the cron "Time Off: Cancel invalid leaves" Behaviour prior to this commit: The latest leave is cancelled. Intended behaviour: Since the leave is valid according to the leave type configuration, it should not have been cancelled. The leave cancelled should only be made in the case of an excess over the limit in negatives. task-3879156 Forward-Port-Of: odoo/odoo#162643
VIDEO TO REPRODUCE ON RUNBOT: https://github.com/odoo/odoo/assets/56789189/2b89d8c6-627c-4b93-8d96-e9ca5d662450 STEP TO REPRODUCE: -Install DB with demo data -Go to see my tasks of Michell Admin and 13 tasks available -Then go to user profile and hit action 'Assiged Task' -> No tasks for Michell Admin SOLUTION is remove the 'search_default' use domain instead Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is mer
Original PR description
VIDEO TO REPRODUCE ON RUNBOT: https://github.com/odoo/odoo/assets/56789189/2b89d8c6-627c-4b93-8d96-e9ca5d662450 STEP TO REPRODUCE: -Install DB with demo data -Go to see my tasks of Michell Admin and 13 tasks available -Then go to user profile and hit action 'Assiged Task' -> No tasks for Michell Admin SOLUTION is remove the 'search_default' use domain instead 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#165142 Forward-Port-Of: odoo/odoo#164267
Current behavior: When confirming a leave that required 2 approvals, the confirmation mail was not sent correctly to the user that asked the leave. Steps to reproduce: - Login as demo, and create a paid leave (make sure it's using the 2 approvals) - Login as admin, validate the leave - No email is sent to the user to notify him that the leave was accepted To fix the issue we now send the message when the leave is validated in `_validate_leave_request` opw-3719345 --- I confirm I h
Original PR description
Current behavior: When confirming a leave that required 2 approvals, the confirmation mail was not sent correctly to the user that asked the leave. Steps to reproduce: - Login as demo, and create a paid leave (make sure it's using the 2 approvals) - Login as admin, validate the leave - No email is sent to the user to notify him that the leave was accepted To fix the issue we now send the message when the leave is validated in `_validate_leave_request` opw-3719345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166013
Issue: ------ With a user who does not belong to the `hr_holidays.group_hr_holidays_user` group, it is not possible to search for a leave according to the description. Cause: ------ Since commit eb0ba7f79b8a5c099a6f039af770c54169abe584, we check the groups for the fields used in the search domain. We place the `private_name` field in the domain which has a group attribute with the value `hr_holidays.group_hr_holidays_user`. Solution: --------- Use `sudo` (the return value will onl
Original PR description
Issue: ------ With a user who does not belong to the `hr_holidays.group_hr_holidays_user` group, it is not possible to search for a leave according to the description. Cause: ------ Since commit eb0ba7f79b8a5c099a6f039af770c54169abe584, we check the groups for the fields used in the search domain. We place the `private_name` field in the domain which has a group attribute with the value `hr_holidays.group_hr_holidays_user`. Solution: --------- Use `sudo` (the return value will only contain the ids and the domain filtered according to `user_id` if we don't have the group). opw-3907517 Forward-Port-Of: odoo/odoo#166992
Before this commit, the notification settings in discuss app that is used to mute channels was not showing items properly in some languages like vietnamese. This happens because the width is hard-coded to 150px as to keep the dropdown menu small. This commit fixes the issue by putting a max-width of 250px for dropdown menu and sub-menu, so that it keeps right positioning of submenu. If text is too long, it know wraps.  Forward-Port-Of: odoo/odoo#167017
The context menu (and clickable cell) `use_global_filter` should take the value of the underlying pivot formula, and apply it to the matching global filters. This works, but was supposed to work only for `ODOO.PIVOT.HEADER` formulas, and not simple `ODOO.PIVOT` formulas. This commit fixes the visibility of the `use_global_filter` option in the context menu, so that it is only visible for `ODOO.PIVOT.HEADER`. Also removed/changed tests that were testing that the menu was visible for positio
Original PR description
The context menu (and clickable cell) `use_global_filter` should take the value of the underlying pivot formula, and apply it to the matching global filters. This works, but was supposed to work only for `ODOO.PIVOT.HEADER` formulas, and not simple `ODOO.PIVOT` formulas. This commit fixes the visibility of the `use_global_filter` option in the context menu, so that it is only visible for `ODOO.PIVOT.HEADER`. Also removed/changed tests that were testing that the menu was visible for positional `ODOO.PIVOT` formulas. Task: [3714696](https://www.odoo.com/web#id=3714696&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#166971
Steps to reproduce: - Navigate to Product Variants list view in the Inventory module - Search for a warehouse e.g. "My Company" in the list view - Click on any storable product e.g. DESK0005 - In the product form view click on the "Forecasted" button This gives a traceback because the 'warehouse' in the context is the name and not the id. Fixes #165330 Forward-Port-Of: odoo/odoo#165934
Original PR description
Steps to reproduce: - Navigate to Product Variants list view in the Inventory module - Search for a warehouse e.g. "My Company" in the list view - Click on any storable product e.g. DESK0005 - In the product form view click on the "Forecasted" button This gives a traceback because the 'warehouse' in the context is the name and not the id. Fixes #165330 Forward-Port-Of: odoo/odoo#165934
Since https://github.com/odoo/odoo/pull/143852 and the backport https://github.com/odoo/odoo/pull/163564 , we have added a lot of index for account.move, but still there are some missing left, so this commit is to add the index btree_not_null for those one. 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:
Original PR description
Since https://github.com/odoo/odoo/pull/143852 and the backport https://github.com/odoo/odoo/pull/163564 , we have added a lot of index for account.move, but still there are some missing left, so this commit is to add the index btree_not_null for those one. 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#166887
Description of the issue/feature this PR addresses: Avoid IndexError when selecting default_dest_location in `_get_default_dest_location` when: - Adding a new line (stock.move.line) inside a Batch - User has _stock.group_stock_storage_categories_ group https://www.loom.com/share/fbe5d532cab94080b4ea3384ebaeb7c0?sid=e3115127-7153-42a5-9caf-69e871077c1a Current behavior before PR: IndexError Desired behavior after PR is merged: Allow to add an empty line without error --- OP
Original PR description
Description of the issue/feature this PR addresses: Avoid IndexError when selecting default_dest_location in `_get_default_dest_location` when: - Adding a new line (stock.move.line) inside a Batch - User has _stock.group_stock_storage_categories_ group https://www.loom.com/share/fbe5d532cab94080b4ea3384ebaeb7c0?sid=e3115127-7153-42a5-9caf-69e871077c1a Current behavior before PR: IndexError Desired behavior after PR is merged: Allow to add an empty line without error --- OPW-3916135 MT-5971 @moduon @rafaelbn @yajo @EmilioPascual --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165753
- Before this commit One using an Input Method Editor (i.e. for writing hiraganas) could potentially trigger an hotkey, which does not make any sense. - After this commit While an IME is still composing, the hotkey service will ignore. opw-3633735 Forward-Port-Of: odoo/odoo#165229
Original PR description
- Before this commit One using an Input Method Editor (i.e. for writing hiraganas) could potentially trigger an hotkey, which does not make any sense. - After this commit While an IME is still composing, the hotkey service will ignore. opw-3633735 Forward-Port-Of: odoo/odoo#165229
Before this commit: =================== Duplicate down payment lines were being generated multiple times upon clicking the order button after importing the Quotation/Order. Steps To Reproduced: ===================== - Step 1: Create order in Sales and save it - Step 2: Open POS Restaurant and click on Quotation/Order - Step 3: Select order and Settle order as Down-payment - Step 4: Once added into cart click on the order button multiple times. - Step 5: Go to back-end and open Sa
Original PR description
Before this commit: =================== Duplicate down payment lines were being generated multiple times upon clicking the order button after importing the Quotation/Order. Steps To Reproduced: ===================== - Step 1: Create order in Sales and save it - Step 2: Open POS Restaurant and click on Quotation/Order - Step 3: Select order and Settle order as Down-payment - Step 4: Once added into cart click on the order button multiple times. - Step 5: Go to back-end and open Sales order You'll see multiple down-payment entries corresponding to each click on the order button. After this commit: =================== The creation of duplicate down payment lines is prevented. task - 3877380 Forward-Port-Of: odoo/odoo#162772
This reverts commit 819ed2a64d0f11f33190af0c804955e380242968. opw-3955626 but there are many others Forward-Port-Of: odoo/enterprise#63484
Original PR description
This reverts commit 819ed2a64d0f11f33190af0c804955e380242968. opw-3955626 but there are many others Forward-Port-Of: odoo/enterprise#63484
Removing the VAT numbers grouping from the Dutch ICP report opw-3944815 Forward-Port-Of: odoo/enterprise#63357 Forward-Port-Of: odoo/enterprise#63186
Original PR description
Removing the VAT numbers grouping from the Dutch ICP report opw-3944815 Forward-Port-Of: odoo/enterprise#63357 Forward-Port-Of: odoo/enterprise#63186
German grammar is tricky Forward-Port-Of: odoo/enterprise#63334 Forward-Port-Of: odoo/enterprise#63317
Original PR description
German grammar is tricky Forward-Port-Of: odoo/enterprise#63334 Forward-Port-Of: odoo/enterprise#63317
The context menu (and clickable cell) `use_global_filter` should take the value of the underlying pivot formula, and apply it to the matching global filters. This works, but was supposed to work only for `ODOO.PIVOT.HEADER` formulas, and not simple `ODOO.PIVOT` formulas. This commit fixes the visibility of the `use_global_filter` option in the context menu, so that it is only visible for `ODOO.PIVOT.HEADER`. Also removed/changed tests that were testing that the menu was visible for positio
Original PR description
The context menu (and clickable cell) `use_global_filter` should take the value of the underlying pivot formula, and apply it to the matching global filters. This works, but was supposed to work only for `ODOO.PIVOT.HEADER` formulas, and not simple `ODOO.PIVOT` formulas. This commit fixes the visibility of the `use_global_filter` option in the context menu, so that it is only visible for `ODOO.PIVOT.HEADER`. Also removed/changed tests that were testing that the menu was visible for positional `ODOO.PIVOT` formulas. Task: [3714696](https://www.odoo.com/odoo/2328/tasks/3714696?cids=1) Forward-Port-Of: odoo/enterprise#63316
Use the same condition for the modal and button to ensure both are always rendered at the same time and the button cannot be rendered if the modal is not. Forward-Port-Of: odoo/enterprise#63253
Original PR description
Use the same condition for the modal and button to ensure both are always rendered at the same time and the button cannot be rendered if the modal is not. Forward-Port-Of: odoo/enterprise#63253