Friday, May 31, 2024
40 changes · saas-17.2
Enhancements to existing features
The website generator now records the database URL when scraper results are retrieved. This makes it easier for support or operations teams to manually inspect generated website results when needed, while avoiding unreliable URLs during early trial setup.
Original PR description
In order to inspect the result manually when necessary, we save the url of the db that received the result of the website scraper. We do this only when fetching the result because the saas trials cannot garantee its web.base.url when it is first making the request to the website scraper. Linked to: https://github.com/odoo/iap-apps/pull/808
This update improves Odoo's internal unit testing setup for Hoot by aligning mock server tests with newer helper conventions and removing unused test exports. It helps keep automated tests consistent and easier to maintain without changing customer-facing features.
Original PR description
## Pull Request HOOT (PROOT) - part 16 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PROOT) - part 16 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Community: https://github.com/odoo/odoo/pull/166311 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes Odoo's web navigation system easier to adapt for specialized experiences such as the Knowledge portal. It allows custom web clients to define how page state is represented in URLs, improving flexibility without changing standard behavior.
Original PR description
To facilitate the usage of the router in custom webclients like the Knowledge portal, `url-state` conversion functions are attached to the router object to allow patching them, in order to handle a custom router state. task-3743416
This update strengthens Odoo's internal unit testing framework, especially around Hoot, mock servers, timing behavior, and memory cleanup. It helps developers catch issues more reliably while keeping the changes limited to tests and minimizing risk to everyday product use.
Original PR description
## Pull Request HOOT (PRHOOT) - part 16 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 16 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Enterprise: https://github.com/odoo/enterprise/pull/62998 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Knowledge editor toolbar now stays properly above article content on mobile devices. This prevents separators, embedded views, and other article elements from being hidden or visually overlapping while users scroll and edit.
Original PR description
This commit fixes an issue with the editor toolbar in mobile mode. The toolbar overlaps some elements inside a knowledge article, e.g. separators and embedded views. This is because in mobile the toolbar has a z-index auto which means that it has the same z-index as the editor which can be lower than some elements with an index set. Before it wasn't an issue as the toolbar wasn't sticky so it disappeared when you scrolled on mobile. But the `position: sticky;` forces us to take the z-index into account. To fix this, the css rule is removed so that the toolbar uses its original index which places it back on top of the other blocks. task-3939911
Miscellaneous changes
also modified: test_marketing_automation Previously, campaign templates could not be used by non-admin users. This commit allows non-admin users with access to the marketing_automation app to create campaigns from templates as expected. task-3603400 Backport of: odoo@8fcdb85f0c4279c6a16c26aa669496cf456f0631 Forward-Port-Of: odoo/enterprise#63155
Original PR description
also modified: test_marketing_automation Previously, campaign templates could not be used by non-admin users. This commit allows non-admin users with access to the marketing_automation app to create campaigns from templates as expected. task-3603400 Backport of: odoo@8fcdb85f0c4279c6a16c26aa669496cf456f0631 Forward-Port-Of: odoo/enterprise#63155
This change fixes an intermittent automated test failure in Odoo Live Chat by ensuring the chat channel is properly saved before testing that it can be closed. It helps keep the quality checks stable so future updates can be validated with fewer false failures.
Original PR description
Before this commit, the "open/close persisted channel" test was sometimes failing. The test checks that a persisted channel can be closed. The issue occurs because the test does not make sure that the channel is persisted before closing the chat window. This PR fixes the issue. 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
Portal users can now see the correct total time on shared tasks when time is logged on both a main task and its subtasks. This fixes a display issue caused by the portal page checking the wrong condition, helping customers and collaborators track work more accurately.
Original PR description
Steps to reproduce: - Open project and create a task with some allocated time - Create a sub task and log some time sheets in both main task and sub-task - Share the main task to portal user - Open show the portal view and open the task Issue: - You can see that total time is missing. Cause: - Non existent constraint in the condition Solution: - Removing the constraint and changing with the correct constraint - The constraint is changed in the PR - https://github.com/odoo/odoo/pull/128407 - from timesheets_by_subtask to task.subtask_effective_hours task-3862095 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
This fix ensures certain automatically created Austrian accounting accounts receive the correct reporting tags. It helps keep financial reports properly categorized for suspense, outstanding, and transfer accounts.
Original PR description
Since #152894, newly-created accounts are automatically assigned the account tags of their closest preceding account in the CoA. Unfortunately, the tags that get automatically assigned to the transfer, suspense and outstanding accounts are incorrect: * Suspense account and outstanding accounts get tags (ABIV, 2780), but should have tags (ABIV, 2300). * Transfer account gets tags (ABII4, 2885) but should have tags (ABIV, 2885). As such, we need to set the tags to the correct ones. Taskid: 3060790
This will add tracking to some employee field that have an impact on withholding taxes. Task: 3879035 Forward-Port-Of: odoo/enterprise#61315
Original PR description
This will add tracking to some employee field that have an impact on withholding taxes. Task: 3879035 Forward-Port-Of: odoo/enterprise#61315
Steps to reproduce: - Install `website_helpdesk` - Edit the help form to add a field of type 'Email CC' - Fill the form and for the 'Email CC' put a random mail Issues: The ticket is created but doesn't have any subscribers. The reason is that since the supplied mail in `mail_cc` is not related to any internal user test we will hit the continue in the `create` method. https://github.com/odoo/enterprise/blob/ee506c2ab3e7b39831aed0af2142f8f7e4ba02ba/helpdesk/models/helpdesk_ticket.py#
Original PR description
Steps to reproduce: - Install `website_helpdesk` - Edit the help form to add a field of type 'Email CC' - Fill the form and for the 'Email CC' put a random mail Issues: The ticket is created but doesn't have any subscribers. The reason is that since the supplied mail in `mail_cc` is not related to any internal user test we will hit the continue in the `create` method. https://github.com/odoo/enterprise/blob/ee506c2ab3e7b39831aed0af2142f8f7e4ba02ba/helpdesk/models/helpdesk_ticket.py#L508-L509 Because of this continue we will skip the code in charge of subscribing the partner to the ticket. https://github.com/odoo/enterprise/blob/ee506c2ab3e7b39831aed0af2142f8f7e4ba02ba/helpdesk/models/helpdesk_ticket.py#L512-L513 opw-3922047 Forward-Port-Of: odoo/enterprise#62875
**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 Forward-Port-Of: odoo/enterprise#63349
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 Forward-Port-Of: odoo/enterprise#63349
Steps to reproduce: - Install sign - Add two document to sign for the Marc Demo - Sign in as Marc Demo - Go to the sign app and sign both documents Issues: There's no button to close the dialog box, you are forced to close the window. opw-3847269 Forward-Port-Of: odoo/enterprise#63208 Forward-Port-Of: odoo/enterprise#61380
Original PR description
Steps to reproduce: - Install sign - Add two document to sign for the Marc Demo - Sign in as Marc Demo - Go to the sign app and sign both documents Issues: There's no button to close the dialog box, you are forced to close the window. opw-3847269 Forward-Port-Of: odoo/enterprise#63208 Forward-Port-Of: odoo/enterprise#61380
The problem is that the message ``` This invoice will be paid using direct debit and is only sent for informative purposes. sent for informative purposes ``` is displayed even in invoices that doesn't use Direct Debit after a studio change. Steps: - install `account_sepa_direct_debit` - install `web_studio` - Edit `Invoices` report on studio - Save - Try to print an invoice report - SDD (Sepa Direct Debit) message will be displayed even if this invo
Original PR description
The problem is that the message ``` This invoice will be paid using direct debit and is only sent for informative purposes. sent for informative purposes ``` is displayed even in invoices that…
The problem is that the message
```
This invoice will be paid using direct debit and is only sent for
informative purposes. sent for informative purposes
```
is displayed even in invoices that doesn't use Direct Debit after a studio change.
Steps:
- install `account_sepa_direct_debit`
- install `web_studio`
- Edit `Invoices` report on studio
- Save
- Try to print an invoice report
- SDD (Sepa Direct Debit) message will be displayed
even if this invoice doesn't use SDD
This inconsistency was due to two errors in the report generated by SDD
```xml
<p t-if="o.sdd_mandate_id">
<span>
<p>
This invoice will be paid using direct debit and is only
sent for informative purposes.
</p>
<p>
Please do not pay it manually, the payment will be asked to your bank to be processed
automatically.
</p>
</span>
</p>
```
A `<p>`/`<span>` can't contains another `<p>`
as defined here https://html.spec.whatwg.org/#the-p-element or https://html.spec.whatwg.org/#the-span-element `<P>`/`<span>` can only contains "Phrasing content" (https://html.spec.whatwg.org/#phrasing-content-2) `<div>` and `<p>` for example are not phrasing content
opw-3908411
Forward-Port-Of: odoo/enterprise#63345**Current behavior:** If we have a picking batch with some pickings all for the same product, while enforcing mandatory scans on source location, products, and destination location, there is some unexpected behavior if a different destination barcode is scanned after the similar-product pickings have all been scanned. **Expected behavior:** With this specific configuration, pickings with the same product should all be changed when a different destination is scanned. **Steps to reproduce:
Original PR description
**Current behavior:** If we have a picking batch with some pickings all for the same product, while enforcing mandatory scans on source location, products, and destination location, there is some…
**Current behavior:**
If we have a picking batch with some pickings all for the same product, while enforcing mandatory scans on source location, products, and destination location, there is some unexpected behavior if a different destination barcode is scanned after the similar-product pickings have all been scanned.
**Expected behavior:**
With this specific configuration, pickings with the same product should all be changed when a different destination is scanned.
**Steps to reproduce:**
1. In the Internal Transfers picking type, configure the barcode settings like so:
`Source Location: Mandatory Scan`
`Product: True`
`Destination Location: After each product`
2. Create some new internal location (e.g., .../Stock/shelf)
3. Create a new batch picking with 2 internal transfer pickings for the same product
4. Go to the batch operation barcode menu, select the created batch picking
5. Scan the source location, scan the first product code and then manually add the second picking quantity with the add quantity button, scan the newly created internal location
6. Observe that the last picking destination location has changed and the first has not- furthermore trying to change the second's destination location via scan does not work (manual changes via the edit button/form still possible)
**Cause of the issue:**
The method of changing destination does not account for this setup, so there is no specific handling for it. Only the selected line will be modified by a new destination scan.
**Fix:**
Extract the line modification code into a new function and override it in the batch_picking module to change the entire current batch of lines that have been scanned (that all have the same product).
opw-3733870
Forward-Port-Of: odoo/enterprise#62201This 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
This PR fixes two issues with the portal web client of Knowledge: - When a portal user opens an article, the URL switches to the internal pathname scheme using `/odoo` as a prefix instead of `/knowledge/article`, because the `router.js` was not designed to handle custom webclients. - When a portal user reloads an article, he is redirected to `/my`, the portal home, since the server reads the `/odoo` route as an internal view access attempt. After this PR, accessing and reloading Knowledge
Original PR description
This PR fixes two issues with the portal web client of Knowledge:
- When a portal user opens an article, the URL switches to the internal pathname scheme using `/odoo` as a prefix instead of `/knowledge/article`, because the `router.js` was not designed to handle custom webclients.
- When a portal user reloads an article, he is redirected to `/my`, the portal home, since the server reads the `/odoo` route as an internal view access attempt.
After this PR, accessing and reloading Knowledge portal pages will behave appropriately and use the correct URL scheme (`/knowledge/article/{id}`).
task-3743416
Forward-Port-Of: odoo/enterprise#63013
Forward-Port-Of: odoo/enterprise#60845VIDEO 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
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
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
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#167123Forward-port of the test from https://github.com/odoo/odoo/commit/5d5752e87a09602d9cb05d5f7ded324499fdce63 Add a test in case we try to generate a link preview and we don't get a 'Content-Type' in the headers of the response. This potential issue was addressed by https://github.com/odoo/odoo/commit/bc202e0a0294e5a0c90118a8fa43ba54838e66b3, we now also add a test. Forward-Port-Of: odoo/odoo#165723 Forward-Port-Of: odoo/odoo#162398
Original PR description
Forward-port of the test from https://github.com/odoo/odoo/commit/5d5752e87a09602d9cb05d5f7ded324499fdce63 Add a test in case we try to generate a link preview and we don't get a 'Content-Type' in the headers of the response. This potential issue was addressed by https://github.com/odoo/odoo/commit/bc202e0a0294e5a0c90118a8fa43ba54838e66b3, we now also add a test. Forward-Port-Of: odoo/odoo#165723 Forward-Port-Of: odoo/odoo#162398
Description of the issue/feature this PR addresses: Fix the way that product_id, and set_qty parameters are handled. Because of the way `website_sale_loyalty` handles base arguments in it's `_cart_update` override, all overrides of that method, that earlier, need to pass arguments to super by key instead of position. Otherwise, an error is raised, because the override in question, receives those parameters in args, instead of kwargs, producing a KeyError. This should not be something a commun
Original PR description
Description of the issue/feature this PR addresses: Fix the way that product_id, and set_qty parameters are handled. Because of the way `website_sale_loyalty` handles base arguments in it's…
Description of the issue/feature this PR addresses: Fix the way that product_id, and set_qty parameters are handled. Because of the way `website_sale_loyalty` handles base arguments in it's `_cart_update` override, all overrides of that method, that earlier, need to pass arguments to super by key instead of position. Otherwise, an error is raised, because the override in question, receives those parameters in args, instead of kwargs, producing a KeyError. This should not be something a community plugin should need to worry about. This commit makes it so, the override is declared with explicitly stated base arguments, instead of using `*args`, and `**kwargs`. This not only fixes the issue, but also simplifies the method. Current behavior before PR: If any potential `_cart_update` overrides call `super` with position based arguments, a KeyError is raised. Desired behavior after PR is merged: `super` may be called with either key and position based arguments in `_cart_update` overrides. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165033
Problem: In kiosk, when a person has a command with a price of 0.00, he doesn't have an order number Steps to reproduce: - Install "Point of Sale" app - In POS settings, create a kiosk shop and set "Self Ordering" to "Kiosk" - Go to product and set a price of 0.00 to a product - Open the kiosk session and order the product with the price of 0.00 - Click on "Pay" and you'll be back to the reception page without having your order number opw-3877596 --- I confirm I have signed t
Original PR description
Problem: In kiosk, when a person has a command with a price of 0.00, he doesn't have an order number Steps to reproduce: - Install "Point of Sale" app - In POS settings, create a kiosk shop and set "Self Ordering" to "Kiosk" - Go to product and set a price of 0.00 to a product - Open the kiosk session and order the product with the price of 0.00 - Click on "Pay" and you'll be back to the reception page without having your order number opw-3877596 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165556
-Sinve the removal of 'address_home_id' in https://github.com/odoo/odoo/commit/e8c48f824e078d643a3385fb910707d5525e927d we should adapt the scaffold code for payroll too. 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#166651
Original PR description
-Sinve the removal of 'address_home_id' in https://github.com/odoo/odoo/commit/e8c48f824e078d643a3385fb910707d5525e927d we should adapt the scaffold code for payroll too. 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#166651
Before this commit, there was a race condition in the way kanban progressbar were handled: when the kanban view was reloaded, two (sequences of) rpcs were done: 1) by the model, to load the data (e.g. 1 web_read_group followed by n web_search_read) 2) by the progress bar hook, to load progressbar data. 1 and 2 weren't synchronized, and if 2 returned after 1, the view wasn't re-rendered to reflect the new progressbar data. This issue was caused by a misuse of owl reactivity: in th
Original PR description
Before this commit, there was a race condition in the way kanban progressbar were handled: when the kanban view was reloaded, two (sequences of) rpcs were done: 1) by the model, to load the data…
Before this commit, there was a race condition in the way kanban
progressbar were handled: when the kanban view was reloaded, two
(sequences of) rpcs were done:
1) by the model, to load the data (e.g. 1 web_read_group followed
by n web_search_read)
2) by the progress bar hook, to load progressbar data.
1 and 2 weren't synchronized, and if 2 returned after 1, the view
wasn't re-rendered to reflect the new progressbar data. This issue
was caused by a misuse of owl reactivity: in the progressbar hook,
in onWillUpdateProps, we didn't call loadProgressBar on the reactive
version of the progressbar state, so changes in that state didn't
trigger a rendering.
Fixing this highlighted a bunch of other issues, all of them kind
of related to the fact that the model and the progressbar don't
synchronize when fetching their data. In particular, scenarios
where the progressbar data was loaded before the kanban data failed,
because the rendering triggered by the progressbar state mutation
(now that it is reactive) altered its caches (see `getGroupInfo`)
or even the groups (see `applyFilter`), with almost outdated
datapoints that were about to be replaced (as soon as the new root
would be loaded).
Properly fixing this isn't possible in stable versions as it might
require an in-depth rework of the way the progressbar interacts
with the model. This will be done in master.
For stable, we found a workaround that seems to be enough: instead
of hooking on `onWillUpdateProps` to reload the progressbar (i.e.
in parallel of the model), we hook on `onWillRender` (i.e. once
the model has loaded the data), and we only load the progressbar
data when the root changed (i.e. as often as before). But by doing
that sequentially, we ensure that the data are always loaded first,
and that the rendering produced by the mutations done on the
progressbar state is done with the correct datapoints.
Master task-3928143
opw-3634027
Forward-Port-Of: odoo/odoo#167081
Forward-Port-Of: odoo/odoo#149626Issue: ------ 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
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
Current behavior: When using a loyalty program that grant 1 free product for each product bought the wrong product was added. This only hapens when the reward product is a tag. For example if you buy product A you get one product A free and if you buy one product B you also get a product A free when you should get a product B free. Steps to reproduce: - Create tag T that should includes product A and B - Create a loyalty program : . grant 1 point per unit paid among tag T products . get 1
Original PR description
Current behavior: When using a loyalty program that grant 1 free product for each product bought the wrong product was added. This only hapens when the reward product is a tag. For example if you buy…
Current behavior: When using a loyalty program that grant 1 free product for each product bought the wrong product was added. This only hapens when the reward product is a tag. For example if you buy product A you get one product A free and if you buy one product B you also get a product A free when you should get a product B free. Steps to reproduce: - Create tag T that should includes product A and B - Create a loyalty program : . grant 1 point per unit paid among tag T products . get 1 free product among tag T products for 1 point - Open PoS session, and add 2 product A, you get one product A free - Add 2 product B, you also get one product A free Note: When adding the second B product it's actually adding the correct product, but when recomputing the rewards it's adding two products A. opw-3836634 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#166931 Forward-Port-Of: odoo/odoo#165617
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
To reproduce: ============= - enable creating ticket in helpdesk with mail alias - having to stages in helpdesk **New** and **In Progress** - create an automated action that is triggered with `on_message_sent` that will move a ticket from **New** to **In Progress** - send an email to the mail alias from an email that doesn't have a contact in the database -> the automated action will be triggered whereas it shouldn't Problem: ======== To know if the email is from a customer and set the
Original PR description
To reproduce: ============= - enable creating ticket in helpdesk with mail alias - having to stages in helpdesk **New** and **In Progress** - create an automated action that is triggered with `on_message_sent` that will move a ticket from **New** to **In Progress** - send an email to the mail alias from an email that doesn't have a contact in the database -> the automated action will be triggered whereas it shouldn't Problem: ======== To know if the email is from a customer and set the `mail_trigger` to `on_message_received` we were checking if the `author_id` of the message, which is `False` if the email is from an unknown contact. Solution: ========= if the `author_id` is `False`, it means that the email is from outside, so the `mail_trigger` should be `on_message_received` opw-3833857 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162805
Description of the issue/feature this PR addresses: Add DUA exempt tax and its mapping Current behavior before PR: Only one way to manage DUA Desired behavior after PR is merged: Added an alternative to manage DUA with an innocuous tax and its mapping --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165912
Original PR description
Description of the issue/feature this PR addresses: Add DUA exempt tax and its mapping Current behavior before PR: Only one way to manage DUA Desired behavior after PR is merged: Added an alternative to manage DUA with an innocuous tax and its mapping --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165912
When connecting to a remote server using the "certificate" authentication method, both a x509 PEM certificate and a PEM public key are required. Forward-Port-Of: odoo/odoo#166870 Forward-Port-Of: odoo/odoo#163584
Original PR description
When connecting to a remote server using the "certificate" authentication method, both a x509 PEM certificate and a PEM public key are required. Forward-Port-Of: odoo/odoo#166870 Forward-Port-Of: odoo/odoo#163584
When a "we-list" button, like the "add item" button, is clicked while a list input is focused, the click event doesn't trigger. Steps to reproduce the bug: - Drag and drop a "Form" snippet onto the page. - Click on the "+ Field" in the options. - Select "Multiple Checkboxes" for the "Type" option of the field. - Rename "Option 1" to "ABC" in the Checkbox list. - Click directly on the "Add new Checkbox" button. - Bug: nothing happens. The new checkbox is not added to the list. This
Original PR description
When a "we-list" button, like the "add item" button, is clicked while a list input is focused, the click event doesn't trigger. Steps to reproduce the bug: - Drag and drop a "Form" snippet onto the page. - Click on the "+ Field" in the options. - Select "Multiple Checkboxes" for the "Type" option of the field. - Rename "Option 1" to "ABC" in the Checkbox list. - Click directly on the "Add new Checkbox" button. - Bug: nothing happens. The new checkbox is not added to the list. This bug arises because when clicking the button, the "change" event of the input is triggered first before the "click" event of the button. Since the "change" event refreshes the widget, the "click" event is lost. This commit adds a "setTimeout" in the "change" event handler to prioritize "click" events within the "we-list". task-3859207 Forward-Port-Of: odoo/odoo#163952 Forward-Port-Of: odoo/odoo#161506
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 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
Due to change in 17.0 qty_done become picked on the stock.move 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#167295
Original PR description
Due to change in 17.0 qty_done become picked on the stock.move 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#167295
Mailing Trace are available to every base.group_user but it is too wide. No current use case justify it. task-3906727 Forward-Port-Of: odoo/odoo#165803
Original PR description
Mailing Trace are available to every base.group_user but it is too wide. No current use case justify it. task-3906727 Forward-Port-Of: odoo/odoo#165803
Backport of https://github.com/odoo/odoo/commit/225d52559e693728f72ca1f00302f69c7901361e \+ add Test. Previously, when following those steps: - create SO with one line with a tax - create a down payment for 30% - remove tax on invoice line - post invoice - create new down payment for 30% A line with 0 amount and no tax was created in addition of other lines. This because, during the calculation of the down payment lines, and the ventilation between all taxes, it would take the line w
Original PR description
Backport of https://github.com/odoo/odoo/commit/225d52559e693728f72ca1f00302f69c7901361e \+ add Test. Previously, when following those steps: - create SO with one line with a tax - create a down payment for 30% - remove tax on invoice line - post invoice - create new down payment for 30% A line with 0 amount and no tax was created in addition of other lines. This because, during the calculation of the down payment lines, and the ventilation between all taxes, it would take the line with no tax into account. Note in this example we remove the tax from the invoice, but it would be the same if we changed the tax for another one. This is done by excluding the down payment lines. This should already have been the case before, but had no real effect because their quantity & price_subtotal = 0. Forward-Port-Of: odoo/odoo#166688 Forward-Port-Of: odoo/odoo#166520
## Description On firefox, when posting a message from the full composer with a template with some modifs, the browser falls into an infinite loop of processing events `selectionchange` in a loop ad-infinitum. When processing the `_onSelectionChange` handle, `_fixSelectionOnEditableRoot` has an assertion that the cursor would be placed on another place than the editable root. But after inlining, the cursor is collapsed in the beginning of the composer, and when normalizing the selection via `g
Original PR description
## Description On firefox, when posting a message from the full composer with a template with some modifs, the browser falls into an infinite loop of processing events `selectionchange` in a loop…
## Description On firefox, when posting a message from the full composer with a template with some modifs, the browser falls into an infinite loop of processing events `selectionchange` in a loop ad-infinitum. When processing the `_onSelectionChange` handle, `_fixSelectionOnEditableRoot` has an assertion that the cursor would be placed on another place than the editable root. But after inlining, the cursor is collapsed in the beginning of the composer, and when normalizing the selection via `getNormalizedCursorPosition` in `setSelection`, the cursor is back in the editable root because it is not editable anymore, which violate the previous assertion. Instead of fixing `setSelection`, as it's too risky for a stable patch, we enforce the assertion of `_fixSelectionOnEditableRoot` to return early if we are not on the editable root. ## Reference opw-3950957 PS: special thanks to (nby) and (dmo) for the help :) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167226