Thursday, November 7, 2024
29 changes · saas-17.2
Enhancements to existing features
The Indian reporting module now checks credit notes from outside the fiscal year more efficiently. This improves performance for the warning process without changing the user-facing workflow or report results.
Original PR description
With this PR, `filtered` will be removed from `_get_out_of_fiscal_year_reversed_moves` method and added to the domain for improve performance. Previous PR: https://github.com/odoo/enterprise/pull/66824 task-3915664
Miscellaneous changes
This PR corrects incorrect documentation links in the Helpdesk Team form view. Steps to reproduce: 1) Install the Helpdesk module. 2) Open any Helpdesk Team or create a new one. 3) Check the documentation links in the following sections: - E-learning - Visibility - Email Alias - Community Forum 4) Notice the incorrect or broken links. **Note**: We do not need to update the .pot file. task-4266660 Forward-Port-Of: odoo/enterprise#72248
Original PR description
This PR corrects incorrect documentation links in the Helpdesk Team form view. Steps to reproduce: 1) Install the Helpdesk module. 2) Open any Helpdesk Team or create a new one. 3) Check the documentation links in the following sections: - E-learning - Visibility - Email Alias - Community Forum 4) Notice the incorrect or broken links. **Note**: We do not need to update the .pot file. task-4266660 Forward-Port-Of: odoo/enterprise#72248
**Steps to reproduce:** - Install l10n_es_reports and Sales - Create a SO for a Spanish customer - Create an invoice from the SO - Check "AEAT data" tab of the invoice **Issue:** "Type for mod 347" is not set. It should be set to "Regular operation" as it is done when creating an invoice manually. **Cause:** The default is handled by a function that depends on another field. However that other field is not set when computing the default value and the result is always False. **So
Original PR description
**Steps to reproduce:** - Install l10n_es_reports and Sales - Create a SO for a Spanish customer - Create an invoice from the SO - Check "AEAT data" tab of the invoice **Issue:** "Type for mod 347" is not set. It should be set to "Regular operation" as it is done when creating an invoice manually. **Cause:** The default is handled by a function that depends on another field. However that other field is not set when computing the default value and the result is always False. **Solution:** There were a function for the default (_default_mod_349_invoice_type) and an onchange on partner (_onchange_partner_id_set_347_invoice_type). Both of them were checking different conditions. The fix is merging these 2 methods by converting the field into a computed stored field where both conditions are handled. opw-4194030 Forward-Port-Of: odoo/enterprise#72958
Tax closing with fiscal positions was not working properly. 1. If the generic tax report doesn't have a specific country and the filter for fiscal position, it should take into account `all` fiscal positions. 3. The closing mechanism until version 18.0 does not work properly with the oss reports. It was not intended for the user to be able to do a closing there before version 18.0. opw-3974388 Forward-Port-Of: odoo/enterprise#66901
Original PR description
Tax closing with fiscal positions was not working properly. 1. If the generic tax report doesn't have a specific country and the filter for fiscal position, it should take into account `all` fiscal positions. 3. The closing mechanism until version 18.0 does not work properly with the oss reports. It was not intended for the user to be able to do a closing there before version 18.0. opw-3974388 Forward-Port-Of: odoo/enterprise#66901
This commit will add the ec sales list report for Slovenian localisation Community PR: odoo/odoo#166559 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/enterprise#65817
Original PR description
This commit will add the ec sales list report for Slovenian localisation Community PR: odoo/odoo#166559 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/enterprise#65817
The 'Requests to switch' filter is supposed to show slots that are unwanted and that are not in the past. Prior to this commit, some shifts that were in the future were not shown by the filter. That was because the planning.slot field end_datetime was encoded in UTC while the datetime.datetime.now() function in the filter's domain was returning the datetime in the client's timezone. Shifts in the time difference between the user's timezone and UTC would be mistakenly marked as "past shifts
Original PR description
The 'Requests to switch' filter is supposed to show slots that are unwanted and that are not in the past. Prior to this commit, some shifts that were in the future were not shown by the filter. That was because the planning.slot field end_datetime was encoded in UTC while the datetime.datetime.now() function in the filter's domain was returning the datetime in the client's timezone. Shifts in the time difference between the user's timezone and UTC would be mistakenly marked as "past shifts" while they might still be in the future. We fix this by using the 'to_utc()' function which should make the filter domain's comparisson between 2 UTC datetimes. Fix done in 17.0 task-4286161 Forward-Port-Of: odoo/enterprise#72820
Steps --- * Create a payslip for an Employee with a contract (e.g. Anita Oliver) (*Payroll > Payslips > All Payslips > New*) * From the *Edit Payslip Lines* action, try to add a new worked day line (first list) with a non 0 amount * *Validate Edition* => Traceback Cause --- When saving new worked days lines, we try to recompute the amount of the *Basic Salary* payslip line, but if the payslip is still a **draft** it was never computed, and so the action we are calling does not exist
Original PR description
Steps --- * Create a payslip for an Employee with a contract (e.g. Anita Oliver) (*Payroll > Payslips > All Payslips > New*) * From the *Edit Payslip Lines* action, try to add a new worked day line (first list) with a non 0 amount * *Validate Edition* => Traceback Cause --- When saving new worked days lines, we try to recompute the amount of the *Basic Salary* payslip line, but if the payslip is still a **draft** it was never computed, and so the action we are calling does not exist. task-4191349 Forward-Port-Of: odoo/enterprise#72031 Forward-Port-Of: odoo/enterprise#71373
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook to be run after the invoice posting, so that it can be run at the end of the cron, when all subscriptions have been handled. However, if _post_invoice_hook is called on an empty RecordSet, it will search for all subscriptions currently handled by the cron. This often resulted in a situation wher
Original PR description
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook…
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook to be run after the invoice posting, so that it can be run at the end of the cron, when all subscriptions have been handled.
However, if _post_invoice_hook is called on an empty RecordSet, it will search for all subscriptions currently handled by the cron.
This often resulted in a situation where only the first subscription was ready for the hook, while the others are not, resulting in only the first delivery created.
---
Test result before fix:
```
2024-11-06 15:41:52,210 35880 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_cron_product_multiple_delivery_creation
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 501, in test_cron_product_multiple_delivery_creation
self.assertTrue(bool(move_1))
AssertionError: False is not true
```
OPW-4166852
Forward-Port-Of: odoo/enterprise#73397To check that an amount is greater than another one, compare_amounts need to be bigger than 0 not 1 Forward-Port-Of: odoo/enterprise#73183 Forward-Port-Of: odoo/enterprise#73159
Original PR description
To check that an amount is greater than another one, compare_amounts need to be bigger than 0 not 1 Forward-Port-Of: odoo/enterprise#73183 Forward-Port-Of: odoo/enterprise#73159
**Steps to reproduce:** - Install account_3way_match - Go to "Invoicing / Vendors / Bills" - Create a bill - (Edit the view in order to display "release_to_pay" field) - (Make sure that "Force Status" (force_release_to_pay) is always checked) - Set "Should Be Paid" (release_to_pay_manual) to "Yes" => "release_to_pay" becomes "Yes" - Save the bill => "release_to_pay" stays "Yes" - Change "Should Be Paid" to "No" => "release_to_pay" becomes "No" - Save the bill => "release_to_pay" reverts
Original PR description
**Steps to reproduce:** - Install account_3way_match - Go to "Invoicing / Vendors / Bills" - Create a bill - (Edit the view in order to display "release_to_pay" field) - (Make sure that "Force Status" (force_release_to_pay) is always checked) - Set "Should Be Paid" (release_to_pay_manual) to "Yes" => "release_to_pay" becomes "Yes" - Save the bill => "release_to_pay" stays "Yes" - Change "Should Be Paid" to "No" => "release_to_pay" becomes "No" - Save the bill => "release_to_pay" reverts to "Yes" **Issue:** Upon save, "release_to_pay" reverts to "Yes", even if it has been correctly computed to "No" before saving. opw-4181752 Forward-Port-Of: odoo/enterprise#73289 Forward-Port-Of: odoo/enterprise#72190
Steps to reproduce: ------------------- 1. Install Planning app 2. Have an employee A with 40h/week working schedule and an employee B with 35h/week working schedule 3. Create a shift and assign it to employee A, the default allocated hours should be 8h 4. From the Gantt view, duplicate this shift and assign it to employee B (use drag and drop) 5. Problem: The allocated hours of the duplicated shift are not recomputed, they are equal to 8h instead of 7h Fix: ------------------- When d
Original PR description
Steps to reproduce: ------------------- 1. Install Planning app 2. Have an employee A with 40h/week working schedule and an employee B with 35h/week working schedule 3. Create a shift and assign it to employee A, the default allocated hours should be 8h 4. From the Gantt view, duplicate this shift and assign it to employee B (use drag and drop) 5. Problem: The allocated hours of the duplicated shift are not recomputed, they are equal to 8h instead of 7h Fix: ------------------- When duplicating a shift and assigning it to another resource, the copy() method is called with the resource_id of the target resource (an employee in this case). But _compute_allocated_hours() is not called so we have to call it explicitly in this case. version-17.0 task-3978590 Forward-Port-Of: odoo/enterprise#69828
### Current behavior before PR: When creating a Helpdesk team and the Timesheets option enabled and Time Billing disabled you will not get all non-billed projects in the dropdown menu. This is happening because the domain for project_id is checking the company_id to be the same as the company_id of the team. https://github.com/odoo/enterprise/blob/18.0/helpdesk_sale_timesheet/models/helpdesk_team.py#L10 Though since this commit https://github.com/odoo-dev/odoo/commit/16a07ed1bfd33a193b363f3e87
Original PR description
### Current behavior before PR: When creating a Helpdesk team and the Timesheets option enabled and Time Billing disabled you will not get all non-billed projects in the dropdown menu. This is…
### Current behavior before PR: When creating a Helpdesk team and the Timesheets option enabled and Time Billing disabled you will not get all non-billed projects in the dropdown menu. This is happening because the domain for project_id is checking the company_id to be the same as the company_id of the team. https://github.com/odoo/enterprise/blob/18.0/helpdesk_sale_timesheet/models/helpdesk_team.py#L10 Though since this commit https://github.com/odoo-dev/odoo/commit/16a07ed1bfd33a193b363f3e87aab3f9bd6f8bd0 company_id is not required for projects. Since the domain of the project_id field was introduced here https://github.com/odoo/enterprise/pull/4956/commits/c82b1b019cebd1f78749b9563e717fae88d7fae5 and the reason why we check the company_id is not the same anymore since the commit I mentioned above we should not use the same domain. Also in this PR we are solving another issue which is where you enable both Timesheets and Time Billing options and choose a project that has both options enabled too then you disable the Time Billing option for the team the project that we chose before will be kept and have both options enabled and you can save it. ### Desired behavior after PR is merged: We are now checking for the project of the team if the company_id is False or equal to the team's company_id. Also when disbaling the Time Billing option we set the project_id to False. opw-4275647 opw-4148207 Forward-Port-Of: odoo/enterprise#72935
During a major upgrade the registry my be `loaded` but not `ready`. https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/odoo/modules/registry.py#L159-L160 This causes unnecessary warnings during upgrades (blocking the CI). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186467
Original PR description
During a major upgrade the registry my be `loaded` but not `ready`. https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/odoo/modules/registry.py#L159-L160 This causes unnecessary warnings during upgrades (blocking the CI). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186467
Fixed issue introduced in this PR: https://github.com/odoo/odoo/pull/119154. In the above PR, the recurring setting was removed, but the recurring groups were not removed from the group configuration, which caused the group's string to still appear. This issue has now been fixed. Steps to Reproduce and Verify the Fix: 1) Install the Project App. 2) Go to the Project App. 3) Activate the Recurring Feature in the settings. 4) Open any project and verify
Original PR description
Fixed issue introduced in this PR: https://github.com/odoo/odoo/pull/119154.
In the above PR, the recurring setting was removed, but the recurring groups
were not removed from the group configuration, which caused the group's string
to still appear. This issue has now been fixed.
Steps to Reproduce and Verify the Fix:
1) Install the Project App.
2) Go to the Project App.
3) Activate the Recurring Feature in the settings.
4) Open any project and verify the settings.
task-4260042
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183861System shows Enterprise Widget on E-invoice module Although the module is available in community addons Steps to Reproduce : Run only community Install l10n_in module. Now Go to the Settings -> Invoicing. See the Enterprise Widget is on E-Invoice (Indian Integration). 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/submi
Original PR description
System shows Enterprise Widget on E-invoice module Although the module is available in community addons Steps to Reproduce : Run only community Install l10n_in module. Now Go to the Settings -> Invoicing. See the Enterprise Widget is on E-Invoice (Indian Integration). 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#186389
We can have a user that has enough rights to generate sales orders, but not enough right to check a BoM. When creating a new sale order for a kit, everything works fine. Before this commit, if we updated the quantity on the sale order line, the quantity on the moves would become incorrect. After this commit, the BoM is always found in order to correctly recompute the quantity on the moves. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwar
Original PR description
We can have a user that has enough rights to generate sales orders, but not enough right to check a BoM. When creating a new sale order for a kit, everything works fine. Before this commit, if we updated the quantity on the sale order line, the quantity on the moves would become incorrect. After this commit, the BoM is always found in order to correctly recompute the quantity on the moves. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180442
Description of the issue/feature this PR addresses: - Improve _get_report_lines performance Current behavior before PR: - A lag is seen when opening Manufacturing orders, because it goes to compute `components_availability`, calling https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/mrp/models/mrp_production.py#L344 function, which ends up calling https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/stock/report/stock_forecasted.
Original PR description
Description of the issue/feature this PR addresses: - Improve _get_report_lines performance Current behavior before PR: - A lag is seen when opening Manufacturing orders, because it goes to compute…
Description of the issue/feature this PR addresses: - Improve _get_report_lines performance Current behavior before PR: - A lag is seen when opening Manufacturing orders, because it goes to compute `components_availability`, calling https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/mrp/models/mrp_production.py#L344 function, which ends up calling https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/stock/report/stock_forecasted.py#L190 - currently, in `_get_report_lines` function, **transit_stock** https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/stock/report/stock_forecasted.py#L353 is calculated by summing quantities with list comprehension on the **currents** dictionary for each product. https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/stock/report/stock_forecasted.py#L327 - This becomes slow when handling huge number of products and large currents entries. due to O(n * m) complexity Desired behavior after PR is merged: - A dictionary of pre-computed product quantity, minimizes the time taken. ### Here are few benchmarks and stats. **At time of function call :** - As the test database is populated with 2 location ids `_get_report_lines` is called twice during testing, because of https://github.com/odoo/odoo/blob/6e9ace2df2dd3750472c227f818d3dc8d5ba5016/addons/stock/models/stock_move.py#L515-L517 - size of currents dict : 2539 + 2600 - No. of product : 2539 + 2412 ## Before  ## After  opw- 4285618 upg- 2179723 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186238
Before this PR, pressing `Escape` while renaming a thread in the chat window closed the entire chat window instead of simply exiting the rename mode. This PR ensures that pressing `Escape` only exits the rename action, keeping the chat window open. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185833
Original PR description
Before this PR, pressing `Escape` while renaming a thread in the chat window closed the entire chat window instead of simply exiting the rename mode. This PR ensures that pressing `Escape` only exits the rename action, keeping the chat window open. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185833
When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted. Steps to reproduce: - Send a message on a record, add a recipient with an incorrect email. - A red enveloppe is displayed next to the message and a notification is added in the messaging menu. - Delete this record. - Try to mark this failure as read. - Nothing happens. This occurs because the message deletion is only notified
Original PR description
When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted. Steps to reproduce: - Send a message on a record, add a recipient with an incorrect email. - A red enveloppe is displayed next to the message and a notification is added in the messaging menu. - Delete this record. - Try to mark this failure as read. - Nothing happens. This occurs because the message deletion is only notified to the recipients, not the author. This PR fixes the issue. opw-4272165 Forward-Port-Of: odoo/odoo#186000
When a user disconnects from a device, the server assumes he is disconnected until another device/browser says otherwise. However, this can lead to small flickers. This PR fixes the issue by debouncing the update of the im status field of the persona model. This way, there is no flickering. Steps to reproduce the issue: - Open two browser windows with mitchell admin in the discuss app (incognito + regular windows). - Go to the chat with your self, where the im status can be seen. - Re
Original PR description
When a user disconnects from a device, the server assumes he is disconnected until another device/browser says otherwise. However, this can lead to small flickers. This PR fixes the issue by debouncing the update of the im status field of the persona model. This way, there is no flickering. Steps to reproduce the issue: - Open two browser windows with mitchell admin in the discuss app (incognito + regular windows). - Go to the chat with your self, where the im status can be seen. - Reload one tab several times: you can sometimes see a flicker from online to offline. task-4236550 Forward-Port-Of: odoo/odoo#184825
**Current behavior:** Manually adjusting a FIFO/AVCO product's cost creates a journal items with non-zero quantity, despite there not being a logical quantity associated with this entry. **Expected behavior:** AMLs generated for this move have 0 quantity. **Steps to reproduce:** *Having accounting, purchase_stock* 1. Create a storable product with `average` costing 2. Create a purchase order for some of the product with some arbitrary price unit, receive the product 3. In
Original PR description
**Current behavior:** Manually adjusting a FIFO/AVCO product's cost creates a journal items with non-zero quantity, despite there not being a logical quantity associated with this entry. **Expected…
**Current behavior:**
Manually adjusting a FIFO/AVCO product's cost creates a journal
items with non-zero quantity, despite there not being a logical
quantity associated with this entry.
**Expected behavior:**
AMLs generated for this move have 0 quantity.
**Steps to reproduce:**
*Having accounting, purchase_stock*
1. Create a storable product with `average` costing
2. Create a purchase order for some of the product with some
arbitrary price unit, receive the product
3. In the product form, change the cost to a smaller value
4. In the journal items pivot view, select the `quantity` field
from the 'Measures' dropdown in the top left, expand the
stock valuation journal on the left axis, observe that the
change in cost has created 2 balancing AMLs, each with
quantity == 1
**Cause of the issue:**
This case was not handled and quantity is always set to 1 if
falsy.
**Fix:**
Create the AMLs created in the cost change handle with
quantity=0. While it does risk being overwritten to 1 if the
`display_type` of the line changes, the diff is minimal and
use-case is non-critical- which makes it the best solution here.
opw-4090620
Forward-Port-Of: odoo/odoo#186304
Forward-Port-Of: odoo/odoo#180998Before this commit, when the accrual cron was running and there was a leave in the future to account for, it would calculate the number of days by processing a fake allocation and invalidating it afterwards. However, the cache invalidation was too aggressive and would also invalidate any changes that were made to existing accrual allocations that were not yet flushed. This commit fixes this behavior by invalidating the recordset so as to only invalidate the fake allocations. opw-4200067 F
Original PR description
Before this commit, when the accrual cron was running and there was a leave in the future to account for, it would calculate the number of days by processing a fake allocation and invalidating it afterwards. However, the cache invalidation was too aggressive and would also invalidate any changes that were made to existing accrual allocations that were not yet flushed. This commit fixes this behavior by invalidating the recordset so as to only invalidate the fake allocations. opw-4200067 Forward-Port-Of: odoo/odoo#185957
Blacklist Odoo in your browser from having access to the local and session storages (security parameters). Before this commit, there were unrecoverable crashes because even doing `window.[localStorage|sessionStorage]` is forbidden. After this commit, we catch those exceptions and make a RamStorage instead. opw-4226366 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
Original PR description
Blacklist Odoo in your browser from having access to the local and session storages (security parameters). Before this commit, there were unrecoverable crashes because even doing `window.[localStorage|sessionStorage]` is forbidden. After this commit, we catch those exceptions and make a RamStorage instead. opw-4226366 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#186294 Forward-Port-Of: odoo/odoo#185811
- Update CoA - Update taxes - Update tax groups - Update reports - Update fiscal positions Courtesy of `Editor.si` for providing data in order to update the files. Enterprise PR: odoo/enterprise#65817 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/odoo#166559
Original PR description
- Update CoA - Update taxes - Update tax groups - Update reports - Update fiscal positions Courtesy of `Editor.si` for providing data in order to update the files. Enterprise PR: odoo/enterprise#65817 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/odoo#166559
Use loops with clear input/expected structure to ease changes and debugging. Add few tests while passing by. Task-3943087 Forward-Port-Of: odoo/odoo#186468
Original PR description
Use loops with clear input/expected structure to ease changes and debugging. Add few tests while passing by. Task-3943087 Forward-Port-Of: odoo/odoo#186468
When trying to sign in (for a new user) after making a purchase (existing token), we can choose a password of less than the minimum length allowed in the configuration. The _check_password_policy method prevents the save of the password to the user but arrives too late in the flow as the initiation of the user creation is half done leading to an Invalid token issue at the next attempt (no partner found for the existing token with _signup_retrieve_partner). By adding the minlength attribute
Original PR description
When trying to sign in (for a new user) after making a purchase (existing token), we can choose a password of less than the minimum length allowed in the configuration. The _check_password_policy method prevents the save of the password to the user but arrives too late in the flow as the initiation of the user creation is half done leading to an Invalid token issue at the next attempt (no partner found for the existing token with _signup_retrieve_partner). By adding the minlength attribute in the form of the sign up, we force the respect of the password policy minimum length in the front end and minimize the risk to encounter the issue. opw-4182543 Forward-Port-Of: odoo/odoo#185139
**Steps to reproduce the bug:** - Create two storable products, “P1” and “P2”. - Set “P1” to be tracked by Serial Number - Update P1 with SN1. - Create a repair order: - Set P1 with SN1. - Save. - Edit and update the product to P2. - Save. - Print the order. **Problem:** The “lot_id” is not cleared and appears in the report because the “lot_id” field becomes invisible and read-only under the same condition. Since it is read-only and not force-saved, the value of “lot_id” is no
Original PR description
**Steps to reproduce the bug:** - Create two storable products, “P1” and “P2”. - Set “P1” to be tracked by Serial Number - Update P1 with SN1. - Create a repair order: - Set P1 with SN1. - Save. - Edit and update the product to P2. - Save. - Print the order. **Problem:** The “lot_id” is not cleared and appears in the report because the “lot_id” field becomes invisible and read-only under the same condition. Since it is read-only and not force-saved, the value of “lot_id” is not considered in the write of the repair order, even though the `onchange` sets the “lot_id” field to False: https://github.com/odoo/odoo/blob/16.0/addons/repair/models/repair.py#L208-L212 **opw-4281176** Forward-Port-Of: odoo/odoo#185906 Forward-Port-Of: odoo/odoo#185552
### Analysis Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation rule wasn't supposed to run - which, on the functional side, is a behavior we can argue on. Moreover, this triggers a write on the records which is not necessary if the automation rule is not run and can increase the delay of the operation. ### Solution In this commit, we update the `date_auto
Original PR description
### Analysis Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation…
### Analysis Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation rule wasn't supposed to run - which, on the functional side, is a behavior we can argue on. Moreover, this triggers a write on the records which is not necessary if the automation rule is not run and can increase the delay of the operation. ### Solution In this commit, we update the `date_automation_last` after filtering the records by checking the `trigger_field_ids`. ## Benchmarks Measuring `web_save` when updating the stage of a lead in the Kanban view of CRM: | # `crm.lead ` | # `automation.rule` on crm.lead | Before | After | % | -------------------- | -----| -- | ---------- | -------- | 970 records| 6 | 1.5s | 0.3 s | - ~80% ### References opw-4263443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186487
Steps to reproduce: - In edit mode, drop a "Text-Image" snippet. - In the text column, add 4 columns with the powerbox (type "/" then "columns"). - In each column, add an image. => The two outer columns image have the same size, which is bigger than the inner ones. This happens because in commit [1], in order for the columns to be well aligned with the rest of the content, the left padding of the first column and the right padding of the last one have been forced to 0px. This resulted in
Original PR description
Steps to reproduce: - In edit mode, drop a "Text-Image" snippet. - In the text column, add 4 columns with the powerbox (type "/" then "columns"). - In each column, add an image. => The two outer…
Steps to reproduce: - In edit mode, drop a "Text-Image" snippet. - In the text column, add 4 columns with the powerbox (type "/" then "columns"). - In each column, add an image. => The two outer columns image have the same size, which is bigger than the inner ones. This happens because in commit [1], in order for the columns to be well aligned with the rest of the content, the left padding of the first column and the right padding of the last one have been forced to 0px. This resulted in the columns content having different sizes depending on their position. Moreover, this was not a good solution because if we added more columns (by duplicating them) such that they go on multiple lines, the last one of the first line would not be correctly aligned to the content, because it is not the last column so it would keep its right padding. This would also result in the columns being shifted compared to the first line. This commit fixes that by removing the rules added by commit [1], as the columns were already aligned without them. The row margins are then set so they compensate the grid item padding, for the case when we are in grid mode, to avoid overflow. Note that if the padding is under 15px, the columns are not aligned anymore, but this is the compromise to have identical columns. [1]: https://github.com/odoo/odoo/commit/fb55f688f6be2211ebeea4ba431a06230c40fb6b opw-4172256 Forward-Port-Of: odoo/odoo#186613 Forward-Port-Of: odoo/odoo#182951