Monday, June 3, 2024
60 changes · saas-17.3
Resolved issues and error corrections
This fix stops the tour recorder from failing when the same tour is run more than once. It checks whether a tour is already registered before adding it again, making repeated test or demo runs more reliable.
Original PR description
Before this commit, if you run the same tour twice, you get a traceback because the tour_recorder was trying to re-add the tour in the registry of the tours, even if he was already registered. After this commit, the tour_recorder register the tour only if the tour is not in the registry of the tours. task-id: 3961677 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Translation exports now download with the expected file name instead of showing the file size as the name. This makes exported translation files easier to identify and use, avoiding confusion for users who manage translations.
Original PR description
This recent [commit] removed all uncommented invisible fields from views. This lead to the Translation Export Wizard having the exported file name missing (defaulting to the file size as file name). Instead of e.g. downloading a file `base.pot`, you would get `1375 kB`. This commit fixes that by re-adding the invisible `name` field to the view of the Translation Export Wizard, so the download file name is correct again. [commit]: https://github.com/odoo/odoo/commit/5639ed865c5a3b82bab25b0ecac28c68c02e9306 Backport of https://github.com/odoo/odoo/commit/b684069f18483293ffc78d34e90556ff348d675a
Documentation links across Odoo were adjusted to point to the saas-17.3 documentation instead of another version. This helps users and support teams reach the correct guidance for the product version they are using.
Original PR description
See also: - https://github.com/odoo/enterprise/pull/63703
This fixes an internal issue where scheduled job tests could incorrectly trigger system change signals before the system registry was fully ready. The change helps prevent missed update notifications during setup and makes automated testing more reliable without affecting normal business workflows.
Original PR description
The test_cron_process_job test will signal_changes, while the registry is considered not ready and invalidated because this is an at install test. Also, the signal_changes safeguard is base on test mode, only during HttpCase or if explicitly entered. This commit fixes the issue but using a patch to make the signal_changes behavior different during tests, and also forbidding to signal_changes if the registry is not ready. This could be an issue if a registry is being loaded, a signal_changes changed is triggered in the middle before committing for a random reason, and the registry_invalidated signal is lost. It looks reasonable to avoid this corner case, forcing to explicitly disable the patch if needed.
The mail interface now shows the attachment popout button only when there is an attachment preview area and actual attachments to open. This avoids showing an irrelevant control, reducing confusion for users working in chatter views.
Original PR description
It is needed when: * the attachment previewer is in the view (`.o_attachment_preview`) * there are attachments (missing `.length`)
The forum post voting buttons now use reduced padding so their borders no longer appear overly wide. This improves the visual polish and readability of forum discussions without changing how voting works.
Original PR description
Fix the wide voting button borders on the post by reducing the buttons padding. Task-3929741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation links were corrected so they point to the saas-17.3 version instead of another release. This helps users and teams reach the right guidance for the version they are using.
Original PR description
See also: - https://github.com/odoo/odoo/pull/167722
Miscellaneous changes
## Issue: - When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available. - Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping. ## Steps To Reproduce: - Install UPS US on your db and publish it. - unpublish the other shipping methods. - Go to /shop and purchase any product a
Original PR description
## Issue: - When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping…
## Issue:
- When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available.
- Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping.
## Steps To Reproduce:
- Install UPS US on your db and publish it.
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, add an address that has more than 35 characters
- Notice you'll be allowed to pay and your order will be confirmed.
In an other scenario:
- Install Fedex US on your db and publish it.
- Set Fedex service type to STANDARD_OVERNIGHT
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, set Hawaii in state/Povince
- Notice you'll be allowed to pay and your order will be confirmed even though Hawaii doesn't support STANDARD_OVERNIGHT shipping.
## Explanation and Solution:
- The first issue arises when there is only one shipping provider available; it gets selected by default. After this selection, the `start` method of `websiteSaleDelivery` is triggered, which attempts to force-click the already checked shipping carrier. Consequently, it returns without completing the logic because the click event handler `_onCarrierClick` dismisses with the following condition:
`if (radio.checked && !this._shouldDisplayPickupLocations(ev)) {return;}`
- The second problem occurs because the `start` method is triggered as soon as the `websiteSaleDelivery` public widget is rendered, which does not allow enough time for the `PaymentButton` to be rendered. This delay causes the `_disablePayButton` method to fail.
- To address the first issue, I added a flag `refreshclick` to indicate that the shipping carrier was set by default.
- To address the second issue, I modified the `_enableButton` method to actively disable the button if the status is false. This change ensures that the `PaymentButton` widget has sufficient time to render since `_enableButton` is called within `_handleCarrierUpdateResult` after awaiting the response from an RPC call.
opw-3844214
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#166450
Forward-Port-Of: odoo/odoo#161704Go to Accounting > Configuration > Journals Delete the EXCH journal Go to Settings > Companies, open the main company Try to create a new branch Traceback comes up: "ValueError: External ID not found in the system: account.2_exch" This occurs because when setting up the new company we are looking for the ref 'exch'. The system will look for the xmlid `account.<company_id>_exch` but the journal has been deleted so it will not be found. A solution is to avoid blocking the company c
Original PR description
Go to Accounting > Configuration > Journals Delete the EXCH journal Go to Settings > Companies, open the main company Try to create a new branch Traceback comes up: "ValueError: External ID not found in the system: account.2_exch" This occurs because when setting up the new company we are looking for the ref 'exch'. The system will look for the xmlid `account.<company_id>_exch` but the journal has been deleted so it will not be found. A solution is to avoid blocking the company creation, the user will need to create the missing journal afterward opw-3932849 Forward-Port-Of: odoo/odoo#167407
Enterprise: https://github.com/odoo/enterprise/pull/63726
Original PR description
Enterprise: https://github.com/odoo/enterprise/pull/63726
Before PR: --- If the invoice has already been sent to the government, then it's allowed to change in sequence. After PR: --- The sequence can't be changed once the invoice is created and sent to the government. task ID :- 3254322 Forward-Port-Of: odoo/odoo#167691 Forward-Port-Of: odoo/odoo#123899
Original PR description
Before PR: --- If the invoice has already been sent to the government, then it's allowed to change in sequence. After PR: --- The sequence can't be changed once the invoice is created and sent to the government. task ID :- 3254322 Forward-Port-Of: odoo/odoo#167691 Forward-Port-Of: odoo/odoo#123899
Problem: In a multi-company environment, deselecting a company on the sales order throws a traceback error that no company can be found. Purpose: No traceback error should occur. Instead, a ValidationError should display requiring the user to set a company. Steps to Reproduce on Runbot: 1. Install Sales and Invoice 2. Create a sale orders with a company and save. 3. Deselect the company to be empty and try to save 4. Traceback error occurs opw-3915943 --- I confirm I have
Original PR description
Problem: In a multi-company environment, deselecting a company on the sales order throws a traceback error that no company can be found. Purpose: No traceback error should occur. Instead, a ValidationError should display requiring the user to set a company. Steps to Reproduce on Runbot: 1. Install Sales and Invoice 2. Create a sale orders with a company and save. 3. Deselect the company to be empty and try to save 4. Traceback error occurs opw-3915943 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165534
Current behavior: When an iot device is linked to the PoS and invoice report, you had an error because action service and iot_websocket service where not available. Steps to reproduce: - Install pos_iot - Set an iot_device printer on the pos session - Set an iot_device on the report of the invoice - Open session, make an order and invoice it - You get an error opw-3792576 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo
Original PR description
Current behavior: When an iot device is linked to the PoS and invoice report, you had an error because action service and iot_websocket service where not available. Steps to reproduce: - Install pos_iot - Set an iot_device printer on the pos session - Set an iot_device on the report of the invoice - Open session, make an order and invoice it - You get an error opw-3792576 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166871 Forward-Port-Of: odoo/odoo#165798
Shut down the server to simulate a connection lost when being in a multi record view. Click on a record to open it in form view. As the server is down, the web_read rpc will fail. The error will be caught by the onError in the action service, which will try to restore the previous controller (the multi record view). The server being down, requests for that controller will fail as well, and we'll end up again in the same onError callback. Since [1], we'll indefinitely try to reload the multi r
Original PR description
Shut down the server to simulate a connection lost when being in a multi record view. Click on a record to open it in form view. As the server is down, the web_read rpc will fail. The error will be…
Shut down the server to simulate a connection lost when being in a multi record view. Click on a record to open it in form view. As the server is down, the web_read rpc will fail. The error will be caught by the onError in the action service, which will try to restore the previous controller (the multi record view). The server being down, requests for that controller will fail as well, and we'll end up again in the same onError callback. Since [1], we'll indefinitely try to reload the multi record view, because we removed the check detecting that the error occurs in the controller that is already in the DOM. If that controller fails, there's no point trying to restore it again, instead, we just show the error. This commit simply restores that part of the code as it was before [1]. [1] odoo/odoo@9c954de94148ab6f3b8d02e6a4713a87fe233a28 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#167484 Forward-Port-Of: odoo/odoo#166295
- Before this commit: The system is sending E invoice requests for the Nil, Zero, Exempt, Non GST supply. which is not required by the government, cause of which E-way bill creation for Bill of Supply is not becoming possible. - After this commit: Fix this issue by filtering out invoices that only use Nil, Zero, Exempt, Non GST as their taxes. task - 3957555 Forward-Port-Of: odoo/odoo#167647 Forward-Port-Of: odoo/odoo#167337
Original PR description
- Before this commit: The system is sending E invoice requests for the Nil, Zero, Exempt, Non GST supply. which is not required by the government, cause of which E-way bill creation for Bill of Supply is not becoming possible. - After this commit: Fix this issue by filtering out invoices that only use Nil, Zero, Exempt, Non GST as their taxes. task - 3957555 Forward-Port-Of: odoo/odoo#167647 Forward-Port-Of: odoo/odoo#167337
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,…
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#167418 Forward-Port-Of: odoo/odoo#166388
Problem --- In sales, when variants are disabled from the settings, the variant grid entry / variant configurator is disabled as well. In purchase, it is not. Fix --- Adapt the onchanges from the sale module to get consistent behavior, ie: * variants disabled -> grid disabled * grid enabled -> variants enabled Note: the onchanges are adapted from their equivalent for sales in `product/models/res_config_settings.py`: https://github.com/odoo/odoo/blob/11bd6708111f9063e8927be2ee5ea26a8b
Original PR description
Problem --- In sales, when variants are disabled from the settings, the variant grid entry / variant configurator is disabled as well. In purchase, it is not. Fix --- Adapt the onchanges from the sale module to get consistent behavior, ie: * variants disabled -> grid disabled * grid enabled -> variants enabled Note: the onchanges are adapted from their equivalent for sales in `product/models/res_config_settings.py`: https://github.com/odoo/odoo/blob/11bd6708111f9063e8927be2ee5ea26a8b816398/addons/product/models/res_config_settings.py#L37-L52 opw-3884106 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163740
[FIX] Correcting the address format for Sweden. The format should be like this: %(street)s %(street2)s %(zip)s %(city)s %(country_name)s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167479
Original PR description
[FIX] Correcting the address format for Sweden. The format should be like this: %(street)s %(street2)s %(zip)s %(city)s %(country_name)s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167479
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#167363 Forward-Port-Of: odoo/odoo#161506
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#167264 Forward-Port-Of: odoo/odoo#166013
**Current behavior:** Using the Delivery smart button in a rental order and then clicking on a picking listed causes a traceback in some flows. **Expected behavior:** The picking form opens. **Steps to reproduce:** *Install sale_stock_renting* 1. Create a new rental order with some rental product and at least 2 storable products 2. Confirm the order and go to the Schedule overview 3. Click on the new order and then on the stock picking smart button (Delivery) 4. Click on any o
Original PR description
**Current behavior:** Using the Delivery smart button in a rental order and then clicking on a picking listed causes a traceback in some flows. **Expected behavior:** The picking form opens. **Steps to reproduce:** *Install sale_stock_renting* 1. Create a new rental order with some rental product and at least 2 storable products 2. Confirm the order and go to the Schedule overview 3. Click on the new order and then on the stock picking smart button (Delivery) 4. Click on any of the pickings listed in the tree view -> Traceback **Cause of the issue:** We load the rental order from the Schedule view with some "form_view_ref" context. We still have this context once we navigate to the picking tree view and it results in the incorrect view being loaded and model fields being accessed which don't exist. **Fix:** Clean the context in the action before serving the new view. opw-3813524 Forward-Port-Of: odoo/odoo#166963
__Description of the issue:__ The way that accrual works now is that future leaves are not taken into account for the balance both for the dashboard display and upon taking leaves. It is then possible to create situation that would lead to issues by taking leaves in a certain order; those issue are avoided with a cron that automatically cancels those issuing leaves. However, if leaves are causing issues and might be cancelled by the cron, a warning should appear on the dashboard of the employe
Original PR description
__Description of the issue:__ The way that accrual works now is that future leaves are not taken into account for the balance both for the dashboard display and upon taking leaves. It is then…
__Description of the issue:__ The way that accrual works now is that future leaves are not taken into account for the balance both for the dashboard display and upon taking leaves. It is then possible to create situation that would lead to issues by taking leaves in a certain order; those issue are avoided with a cron that automatically cancels those issuing leaves. However, if leaves are causing issues and might be cancelled by the cron, a warning should appear on the dashboard of the employee to indicate that issue. To reproduce the issue: - Have any kind of accrual plan; the demo seniority for example - Have a time off type that requires allocation - Create an allocation for any employee for that accrual plan starting now and manually grant 1 day - Go on that employee's dashboard - Create a leave in a few days: it should be possible because one day is available for the employee - Create another one the day before: the system allows it but it is a discrepancy in the balance - Look on the balance for the time off type: no warning is displayed __Expected behaviour:__ There should be a warning after the creation of the second __Description of the bugfix:__ This commit fixes the way the excess is detected to make it accurate. Additionally, the different warning messages were previously made incompatible with one another though they're not linked; this commit allows multiple warning messages if multiple are to be displayed. task-3859558 Forward-Port-Of: odoo/odoo#167388 Forward-Port-Of: odoo/odoo#161107
-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
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
## 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
Before this fix, when a spreadsheet contained any odoo link (to an action, a menu or a XML Id), when a public user opened the spreadsheet and clicked on the link, he had a nonsensical page because the parser and resolver of the link is never loaded for the public user (he would not have access to the menu data anyway). After this fix, we replace the odoo links by their label, so the link itself is removed. Task: 3925333 --- I confirm I have signed the CLA and read the PR guid
Original PR description
Before this fix, when a spreadsheet contained any odoo link (to an action, a menu or a XML Id), when a public user opened the spreadsheet and clicked on the link, he had a nonsensical page because the parser and resolver of the link is never loaded for the public user (he would not have access to the menu data anyway). After this fix, we replace the odoo links by their label, so the link itself is removed. Task: 3925333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167352 Forward-Port-Of: odoo/odoo#166843
To handle some advanced taxes setups, we changed the behavior of the 'Update taxes' so that it would recompute the prices before recomputing the taxes, but some business do not expect that recomputation, despite modifying the taxes. The businesses needing the prices recomputation will have to trigger it manually, and shouldn't rely on the Update Taxes button for that. Introduced by 537df32897494f94962637bd2b45d2618ff83e7c opw-3953806 --- I confirm I have signed the CLA and read th
Original PR description
To handle some advanced taxes setups, we changed the behavior of the 'Update taxes' so that it would recompute the prices before recomputing the taxes, but some business do not expect that recomputation, despite modifying the taxes. The businesses needing the prices recomputation will have to trigger it manually, and shouldn't rely on the Update Taxes button for that. Introduced by 537df32897494f94962637bd2b45d2618ff83e7c opw-3953806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167321
Make the pricelist dropdown for events tickets visible on smaller screens, if not, users will be stuck with the default pricelist and won't be able to change to the one they need to use. ## Steps to reproduce: 1. Create an event with selling tickets. 2. Make sure you have more than 1 pricelist available. 3. Go to order a ticket, and in the dialog, make sure our screen size is below 992px. 4. The dropdown to select pricelist is no longer visible. opw-3889376 Forward-Port-Of: odoo/odo
Original PR description
Make the pricelist dropdown for events tickets visible on smaller screens, if not, users will be stuck with the default pricelist and won't be able to change to the one they need to use. ## Steps to reproduce: 1. Create an event with selling tickets. 2. Make sure you have more than 1 pricelist available. 3. Go to order a ticket, and in the dialog, make sure our screen size is below 992px. 4. The dropdown to select pricelist is no longer visible. opw-3889376 Forward-Port-Of: odoo/odoo#164605
Steps to reproduce: - Have two companies selected (i.e. San Francisco & Chicago) - Have 'Storage Locations' option enabled - Create a product then 'Update Quantity' - Create a quant and try to select the stock of the other company Issue: Only the locations in the first company will be shown. Moreover, in the case of tracked products, if the last quant created was one to a 'transit' location without company (e.g. 'Inter-company transit'), then only internal/transit location without compan
Original PR description
Steps to reproduce: - Have two companies selected (i.e. San Francisco & Chicago) - Have 'Storage Locations' option enabled - Create a product then 'Update Quantity' - Create a quant and try to select…
Steps to reproduce: - Have two companies selected (i.e. San Francisco & Chicago) - Have 'Storage Locations' option enabled - Create a product then 'Update Quantity' - Create a quant and try to select the stock of the other company Issue: Only the locations in the first company will be shown. Moreover, in the case of tracked products, if the last quant created was one to a 'transit' location without company (e.g. 'Inter-company transit'), then only internal/transit location without companies will be shown. The issue comes from the `check_company` clause on the `location_id` field. This will make a check against the `company_id` of the record, which itself is a related field from the location This doesn't make much sense, as for checking if the company of a location is correct, we check if the company of the location is within the company of the location. This also introduces the issue mentionned above, as `check_company` will enforce to have ONLY that company & no-company, or just no-company depending on the company of the default location found. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167233
Removed odoo domain from blacklist, so that emails from odoo.com can be used for enrichment for demo/testing purposes. Task-3939876 Forward-Port-Of: odoo/odoo#166239
Original PR description
Removed odoo domain from blacklist, so that emails from odoo.com can be used for enrichment for demo/testing purposes. Task-3939876 Forward-Port-Of: odoo/odoo#166239
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-3888878 Forward-Port-Of: odoo/odoo#163924
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-3888878
Forward-Port-Of: odoo/odoo#163924The goal of this PR is to simply disable the "Text Animation" button from the editor's toolbar in translate mode. An adaptation of code in stable `17.0` will be added to allow the use of text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors if the target is a text option snippet. opw-3686777 Forward-Port-Of: odoo/odoo#158378 Forward-Port-Of: odoo/odoo#157087
Original PR description
The goal of this PR is to simply disable the "Text Animation" button from the editor's toolbar in translate mode. An adaptation of code in stable `17.0` will be added to allow the use of text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors if the target is a text option snippet. opw-3686777 Forward-Port-Of: odoo/odoo#158378 Forward-Port-Of: odoo/odoo#157087
 -According to DECREE 123/2020/ND-CP https://thuvienphapluat.vn/van-ban/Ke-toan-Kiem-toan/Nghi-dinh-123-2020-ND-CP-quy-dinh-hoa-don-chung-tu-445980.aspx (English version required paid to see) the content of invoice need to have amount in word (Article 10 , section D) -> So this commit is to enable it for vn COA by default Description of the issue/feature this PR addresses: Current
Original PR description
 -According to DECREE 123/2020/ND-CP https://thuvienphapluat.vn/van-ban/Ke-toan-Kiem-toan/Nghi-dinh-123-2020-ND-CP-quy-dinh-hoa-don-chung-tu-445980.aspx (English version required paid to see) the content of invoice need to have amount in word (Article 10 , section D) -> So this commit is to enable it for vn COA by default 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#167155
Currently, when trying to merge a PDF generated from Google sheet in the PDF quote builder, a traceback happens due to a known problem in older versions of pypdf2. This was fixed in pypdf2 2.4.2 (see: https://github.com/py-pdf/pypdf/commit/02c601c86819578d9796479a1b8953accefea92b ) It doesn't seem to happen with other editors, and google sheet doesn't allow the use of form fields anyway. Forward-Port-Of: odoo/odoo#166901
Original PR description
Currently, when trying to merge a PDF generated from Google sheet in the PDF quote builder, a traceback happens due to a known problem in older versions of pypdf2. This was fixed in pypdf2 2.4.2 (see: https://github.com/py-pdf/pypdf/commit/02c601c86819578d9796479a1b8953accefea92b ) It doesn't seem to happen with other editors, and google sheet doesn't allow the use of form fields anyway. Forward-Port-Of: odoo/odoo#166901
After version >= `16.4` module **repair** is **[using](https://github.com/odoo/odoo/blob/c002aad906bef390d6d7fd5c795a8e6baa5fd31d/addons/repair/models/repair.py#L571-L578)** attribute `_get_default_warehouse_id` which is **[defined](https://github.com/odoo/odoo/blob/c002aad906bef390d6d7fd5c795a8e6baa5fd31d/addons/sale_stock/models/res_users.py#L12-L17)** in module `sale_stock`. There is no dependency between that 2 modules. But as the module `sale_stock` is **autoinstall=1** and its all depen
Original PR description
After version >= `16.4` module **repair** is **[using](https://github.com/odoo/odoo/blob/c002aad906bef390d6d7fd5c795a8e6baa5fd31d/addons/repair/models/repair.py#L571-L578)** attribute…
After version >= `16.4` module **repair** is **[using](https://github.com/odoo/odoo/blob/c002aad906bef390d6d7fd5c795a8e6baa5fd31d/addons/repair/models/repair.py#L571-L578)** attribute `_get_default_warehouse_id` which is **[defined](https://github.com/odoo/odoo/blob/c002aad906bef390d6d7fd5c795a8e6baa5fd31d/addons/sale_stock/models/res_users.py#L12-L17)** in module `sale_stock`. There is no dependency between that 2 modules.
But as the module `sale_stock` is **autoinstall=1** and its all dependencies are being installed when we install `repair` the module **sale_stock** is also being installed automatically. That is why when we install **repair** we will not have any problem on using that attribute. If we uninstall that `sale_stock` we will have problem because `repair` module will not be able to find the attribute `_get_default_warehouse_id`.
For fixing the issue I added that attribute in module `stock` as it is dependent for both of `repair` and `sale_stock`, and also I use the inheritence in module `sale_stock`
**Steps to reproduce:**
1. Install `repair` on `16.0`
2. Uninstall `sale_stock`
3. Try to upgrade to `17.0`
You will error similar to this:
```
File "/home/odoo/src/odoo/17.0/addons/repair/models/repair.py", line 28, in _default_picking_type_id
return self._get_picking_type().get((self.env.company, self.env.user))
File "/home/odoo/src/odoo/17.0/addons/repair/models/repair.py", line 563, in _get_picking_type
default_warehouse = self.env.user.with_company(companies.id)._get_default_warehouse_id()
AttributeError: 'res.users' object has no attribute '_get_default_warehouse_id'
```
upg-1565705
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#166006Description 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
Ubuntu 24.04 Noble ships werkzeug==3.0.1[^1], that version dropped some Py2/Py3 code compatibility to only support Py3. This is the case for the `iri_to_uri` function that since 3.0.0 doesn't support bytes anymore[^2]. Since Odoo 13 only supports Py3 too, it is fine to always decode the query string (which was what `iri_to_uri` was doing anyway). [^1]: https://packages.ubuntu.com/noble/python3-werkzeug [^2]: https://werkzeug.palletsprojects.com/en/3.0.x/urls/ Forward-Port-Of: odoo/odoo#1668
Original PR description
Ubuntu 24.04 Noble ships werkzeug==3.0.1[^1], that version dropped some Py2/Py3 code compatibility to only support Py3. This is the case for the `iri_to_uri` function that since 3.0.0 doesn't support bytes anymore[^2]. Since Odoo 13 only supports Py3 too, it is fine to always decode the query string (which was what `iri_to_uri` was doing anyway). [^1]: https://packages.ubuntu.com/noble/python3-werkzeug [^2]: https://werkzeug.palletsprojects.com/en/3.0.x/urls/ Forward-Port-Of: odoo/odoo#166854 Forward-Port-Of: odoo/odoo#166814
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
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
Since python 3.11, the patch.dict method changed [0] to use pkgutil to resolve names. This new method is not able to patch our `odoo.tools.config.options`. Fixed by using the object instead of a string literal. [0]: python/cpython@ab7fcc8fbdc11091370deeb000a787fb02f9b13d Forward-Port-Of: odoo/odoo#167306
Original PR description
Since python 3.11, the patch.dict method changed [0] to use pkgutil to resolve names. This new method is not able to patch our `odoo.tools.config.options`. Fixed by using the object instead of a string literal. [0]: python/cpython@ab7fcc8fbdc11091370deeb000a787fb02f9b13d Forward-Port-Of: odoo/odoo#167306
Issue: ====== Currently you can delete content inside contenteditable=false elements Steps to reproduce the issue: ============================= - Go to website, edit mode, drag a text block - Add `contenteditable="false"` to a `p` element - Select a word in that `p` element and press on any character, it will be deleted Origin of the issue: ==================== Theres is no check if the element is inside a contenteditable=false or not. Solution: ========= We need to check
Original PR description
Issue: ====== Currently you can delete content inside contenteditable=false elements Steps to reproduce the issue: ============================= - Go to website, edit mode, drag a text block - Add `contenteditable="false"` to a `p` element - Select a word in that `p` element and press on any character, it will be deleted Origin of the issue: ==================== Theres is no check if the element is inside a contenteditable=false or not. Solution: ========= We need to check if the selection is in editable or not to be able to apply commands. task-3605829 Forward-Port-Of: odoo/odoo#167016 Forward-Port-Of: odoo/odoo#155758
Since lxml 5.2 (https://github.com/lxml/lxml/commit/73778681f14359fe6d16644e69aaca276eba525a) lxml_html_clean is in another package We can adapt the requirements after python 3.12 (based on ubuntu 24.04) We can use | operator in debian/control We may need to adapt documentation since the current sed script will fail This pr proposes an alternative script to avoid to use a sed Current sed: `sed -n -e '/^Depends:/,/^Pre/ s/ python3-\(.*\),/python3-\1/p' debian/control` This sed wi
Original PR description
Since lxml 5.2 (https://github.com/lxml/lxml/commit/73778681f14359fe6d16644e69aaca276eba525a) lxml_html_clean is in another package We can adapt the requirements after python 3.12 (based on ubuntu 24.04) We can use | operator in debian/control We may need to adapt documentation since the current sed script will fail This pr proposes an alternative script to avoid to use a sed Current sed: `sed -n -e '/^Depends:/,/^Pre/ s/ python3-\(.*\),/python3-\1/p' debian/control` This sed will fail and give the result `python3-lxml-html-clean | python3-lxml` for the lxml line, we need to remove the spaces Forward-Port-Of: odoo/odoo#167350 Forward-Port-Of: odoo/odoo#163788
**Description of the issue/feature this PR addresses:** Go to Blacklist Click create --> Impossible to save --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#128230
Original PR description
**Description of the issue/feature this PR addresses:** Go to Blacklist Click create --> Impossible to save --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#128230
- 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
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
Community: https://github.com/odoo/odoo/pull/167767
Original PR description
Community: https://github.com/odoo/odoo/pull/167767
Purpose of this PR: To Convert the qunit testcases to hoot. Part of: [3818666](https://www.odoo.com/web#id=3818666&cids=2&menu_id=4720&action=333&active_id=1519&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#62831
Original PR description
Purpose of this PR: To Convert the qunit testcases to hoot. Part of: [3818666](https://www.odoo.com/web#id=3818666&cids=2&menu_id=4720&action=333&active_id=1519&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#62831
Current behavior: When an iot device is linked to the PoS and invoice report, you had an error because action service and iot_websocket service where not available. Steps to reproduce: - Install pos_iot - Set an iot_device printer on the pos session - Set an iot_device on the report of the invoice - Open session, make an order and invoice it - You get an error opw-3792576 Forward-Port-Of: odoo/enterprise#63280 Forward-Port-Of: odoo/enterprise#61697
Original PR description
Current behavior: When an iot device is linked to the PoS and invoice report, you had an error because action service and iot_websocket service where not available. Steps to reproduce: - Install pos_iot - Set an iot_device printer on the pos session - Set an iot_device on the report of the invoice - Open session, make an order and invoice it - You get an error opw-3792576 Forward-Port-Of: odoo/enterprise#63280 Forward-Port-Of: odoo/enterprise#61697
Previously, Gantt, Pivot, and Graph views were listed before Kanban and List views. In this commit, we've reordered based on priority. Upgrade script: No upgrade script is required as we've updated records added in this version task-3902382 Forward-Port-Of: odoo/enterprise#61834
Original PR description
Previously, Gantt, Pivot, and Graph views were listed before Kanban and List views. In this commit, we've reordered based on priority. Upgrade script: No upgrade script is required as we've updated records added in this version task-3902382 Forward-Port-Of: odoo/enterprise#61834
Steps --- * create a subscription sale order (monthly recurrence, at least one product) * confirm > create invoice * add a line to the invoice with a start and end date (invisible by default) * confirm invoice, we get a traceback. Cause --- This happens because, when `_post`ing account moves, we try to apply the subscription specific logic to all the move lines, even if there is no associated sale-order/subscription. In particular the traceback is thrown when we try to access the `nex
Original PR description
Steps --- * create a subscription sale order (monthly recurrence, at least one product) * confirm > create invoice * add a line to the invoice with a start and end date (invisible by default) * confirm invoice, we get a traceback. Cause --- This happens because, when `_post`ing account moves, we try to apply the subscription specific logic to all the move lines, even if there is no associated sale-order/subscription. In particular the traceback is thrown when we try to access the `next_invoice_date` field from a `False` subscription/sale-order. https://github.com/odoo/enterprise/blob/a9ad8b5e62481fc31dffb723af4d1578ada501e7/sale_subscription/models/account_move.py#L38 opw-3940682 Forward-Port-Of: odoo/enterprise#63512 Forward-Port-Of: odoo/enterprise#63258
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 Forward-Port-Of: odoo/enterprise#63521
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 Forward-Port-Of: odoo/enterprise#63521
Create a new journal entry Post it Reset to draft Delete the name Go to General Ledger Export PDF Error TypeError: object of type 'NoneType' has no len() This occurs because when the name field is blanked, it is set to False opw-3925088 Forward-Port-Of: odoo/enterprise#63161
Original PR description
Create a new journal entry Post it Reset to draft Delete the name Go to General Ledger Export PDF Error TypeError: object of type 'NoneType' has no len() This occurs because when the name field is blanked, it is set to False opw-3925088 Forward-Port-Of: odoo/enterprise#63161
Original bug: 1) Create an invoice of 2000 for partner A 2) Create a misc operation with a line of -500 on the receivable account used in 1) 3) Reconcile the receivable lines of 1) and 2). 4) Open the Partner Ledger for A; filter with A's name in the search bar. 5) Print the pdf ====> The misc operation appears under A in the UI, but not in the pdf. The pdf should behave as the UI. The bug came from the fact the domain enforced when filtering and printing was too simple ; it needs t
Original PR description
Original bug: 1) Create an invoice of 2000 for partner A 2) Create a misc operation with a line of -500 on the receivable account used in 1) 3) Reconcile the receivable lines of 1) and 2). 4) Open the Partner Ledger for A; filter with A's name in the search bar. 5) Print the pdf ====> The misc operation appears under A in the UI, but not in the pdf. The pdf should behave as the UI. The bug came from the fact the domain enforced when filtering and printing was too simple ; it needs to consider the move lines reconciled with a move line made for the matching partners as well. Manual forward-port of https://github.com/odoo/enterprise/pull/63347 opw-3915724 Forward-Port-Of: odoo/enterprise#63449
- Make an invoice with analytic distribution divided in Projects and Departments - Post the invoice - Open General Ledger - Filter by analytic account used in invoice Issue: No result is found Occurs after dee8286524eb1ba2eff6360a5f376565da50f723 The old SQL condition to filter analytic account was not removed and it is used together with the new one opw-3930017 Forward-Port-Of: odoo/enterprise#63485
Original PR description
- Make an invoice with analytic distribution divided in Projects and Departments - Post the invoice - Open General Ledger - Filter by analytic account used in invoice Issue: No result is found Occurs after dee8286524eb1ba2eff6360a5f376565da50f723 The old SQL condition to filter analytic account was not removed and it is used together with the new one opw-3930017 Forward-Port-Of: odoo/enterprise#63485
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 ================== - Create a new model with studio - Go to the contaxt form view - Add a new many2one field linked to the newly created model - Exit studio - Create a new contact - Type something in the many2one field - Click on Create an Edit => The name should be kept Cause of the issue ================== Studio models uses x_name as the _rec_name opw-3919262 Forward-Port-Of: odoo/enterprise#63362 Forward-Port-Of: odoo/enterprise#62424
Original PR description
Steps to reproduce ================== - Create a new model with studio - Go to the contaxt form view - Add a new many2one field linked to the newly created model - Exit studio - Create a new contact - Type something in the many2one field - Click on Create an Edit => The name should be kept Cause of the issue ================== Studio models uses x_name as the _rec_name opw-3919262 Forward-Port-Of: odoo/enterprise#63362 Forward-Port-Of: odoo/enterprise#62424
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 int
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 Forward-Port-Of: odoo/enterprise#62975
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
Steps: - Create a database on SaaS - Activate debug mode - Load demo data if not enabled - Install l10n_be_hr_contract_salary Actual result: - Module l10n_be_hr_contract_salary installed - Demo data not loaded properly, traceback Expected result - Module l10n_be_hr_contract_salary installed - Demo data loaded opw-3930487 Forward-Port-Of: odoo/enterprise#63522 Forward-Port-Of: odoo/enterprise#63328
Original PR description
Steps: - Create a database on SaaS - Activate debug mode - Load demo data if not enabled - Install l10n_be_hr_contract_salary Actual result: - Module l10n_be_hr_contract_salary installed - Demo data not loaded properly, traceback Expected result - Module l10n_be_hr_contract_salary installed - Demo data loaded opw-3930487 Forward-Port-Of: odoo/enterprise#63522 Forward-Port-Of: odoo/enterprise#63328
**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#63502 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#63502 Forward-Port-Of: odoo/enterprise#63349