Thursday, November 7, 2024
38 changes · saas-17.4
Enhancements to existing features
Frequently used Odoo pages and services have been marked as read-only where they do not need to change data. This can improve reliability and performance by allowing these requests to be handled more efficiently, with no expected change in user workflows.
Original PR description
First pass on the most used controllers which can be flagged as read-only.
Tax report consistency checks now ignore lines where a tax amount exists but the related base amount is intentionally empty. This avoids misleading warnings in grouped tax reports and makes report review smoother for accounting teams.
Original PR description
We might have a tax amount without a base amount on the report. In that case, we don't need to check the consistency. An example of that case will be to do a `Group by: Tax > Account` in the tax report. The aggregation line will have a deliberate empty net amount.
Resolved issues and error corrections
A small formatting error in one of OdooBot's automated random replies has been corrected. This prevents the bot message from showing broken or unintended HTML text, improving the polish of chat interactions.
Original PR description
Wrong closed parentheses in html_escape causes one of the OdooBot random responses to be rendered incorrectly. 
Code cleanup and technical improvements
Odoo removed temporary badge printer customizations that were added for OXP 2024 and are no longer needed. This reduces event module complexity and keeps future event-specific requirements out of the standard product unless broadly useful.
Original PR description
In the lead-up to OXP 2024, some less-than-ideal hacks were introduced specifically for the needs of the OXP. These are not needed now, and so can be removed. If similar requirements are needed in the future they will be deployed internally and not merged. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
### 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…
This update adjusts an automated test so it works whether demo data is enabled or not. It prevents false build failures caused by the administrator account having a different display name in non-demo environments.
Original PR description
When we do not activate demo data, name of the administrator is Administrator and not Mitchell Admin. Because of that, test fails. This fix checks the username of administrator and generates assert texts based on that. [broken build errors](https://runbot.odoo.com/web#id=105350&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The tax report now avoids showing incorrect consistency warnings when grouped tax lines have no valid net value. This prevents false alerts for accounting users and keeps the report focused on real issues.
Original PR description
### Steps to reproduce: - Go in Accounting > Reporting > Tax Report - Select "Group By: Tax > Account" - A warning should appear on the tax lines ### Cause: In the consistency check the net value retrieved is an empty string so the calculation is done with a net_value of 0 and an error is detected. ### Solution: If the net_value retrieved is not valid, the consistency check is not done. opw-4263695
Duplicating a completed quality check no longer reuses the original check’s name or control date. This prevents duplicate identifiers and ensures each copied check receives the correct new sequence information.
Original PR description
The issue: When duplicating a quality check, the name and control_date fields were copied, resulting in duplicated values. How to reproduce the issue: -Create a quality check -Pass the quality check -Duplicate the quality check Explanation: The name and control_date fields were duplicated during the copy process, preventing the create method from assigning the next sequence number. opw-4197697
### 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:** - Go to events > Configuration > settings > Enable "Use Event Barcode" - Then go to events > Select any event - Click on the gear icon > Print > Badge example **The issue originates from the "sample id" used for printing the badge example. Since it lacks single quotes, the system interprets it as an integer rather than a string, resulting in a traceback error during the printing process.** opw-4253212 Forward-Port-Of: odoo/odoo#186243
Original PR description
**Steps to reproduce:** - Go to events > Configuration > settings > Enable "Use Event Barcode" - Then go to events > Select any event - Click on the gear icon > Print > Badge example **The issue originates from the "sample id" used for printing the badge example. Since it lacks single quotes, the system interprets it as an integer rather than a string, resulting in a traceback error during the printing process.** opw-4253212 Forward-Port-Of: odoo/odoo#186243
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#186446 Forward-Port-Of: odoo/odoo#180442
- 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
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#186501 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#186501 Forward-Port-Of: odoo/odoo#186467
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#186538 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#186538 Forward-Port-Of: odoo/odoo#185833
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
When you made a downpayment on an order that contained product with fixed amount taxes, the tax would be paid multiple times. Steps to reproduce: ------------------- * Create a tax T1 with a fixed amount of 10€ * Create a product P1 using the tax T1 * Make a sale order and add the product P1 to it * Open PoS and make a downpayment for the sale order (e.g 50%) * You will already pay the 10€ of tax * Now if you make a second downpayment (e.g. 10%) > Observation: You still have the 10€ t
Original PR description
When you made a downpayment on an order that contained product with fixed amount taxes, the tax would be paid multiple times. Steps to reproduce: ------------------- * Create a tax T1 with a fixed amount of 10€ * Create a product P1 using the tax T1 * Make a sale order and add the product P1 to it * Open PoS and make a downpayment for the sale order (e.g 50%) * You will already pay the 10€ of tax * Now if you make a second downpayment (e.g. 10%) > Observation: You still have the 10€ tax to pay Why the fix: ------------ We match the behavior of sales app, and ignore the fixed price taxes when creating the downpayment lines. opw-4163579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182480 Forward-Port-Of: odoo/odoo#182380
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 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
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
The regex used to extract the UID from `pos_reference` was too restrictive, failing when the session number exceeded 99999. This fix allows the UID extraction to handle references with larger session numbers. opw-4281163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185155
Original PR description
The regex used to extract the UID from `pos_reference` was too restrictive, failing when the session number exceeded 99999. This fix allows the UID extraction to handle references with larger session numbers. opw-4281163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185155
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
When in daily and weekly calendar views, the start time of events are shown twice in the event card, poluting the user interface. This commit removes the isolated start time for making the event card cleaner. task-4161302 Forward-Port-Of: odoo/odoo#186177 Forward-Port-Of: odoo/odoo#178984
Original PR description
When in daily and weekly calendar views, the start time of events are shown twice in the event card, poluting the user interface. This commit removes the isolated start time for making the event card cleaner. task-4161302 Forward-Port-Of: odoo/odoo#186177 Forward-Port-Of: odoo/odoo#178984
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#183861Currently, when a discount is applied on a specific pos order line, the receipt does not reflect the original price of the article. Steps to reproduce: ------------------- * Open shop session * Add any product to the order * Apply a discount on that order line * Validate and pay order > Observation: The original price of the order is not reflected Why the fix: ------------ We now show the original price, without the discount, on the receipt. opw-4179118 Before: ---------
Original PR description
Currently, when a discount is applied on a specific pos order line, the receipt does not reflect the original price of the article. Steps to reproduce: ------------------- * Open shop session * Add any product to the order * Apply a discount on that order line * Validate and pay order > Observation: The original price of the order is not reflected Why the fix: ------------ We now show the original price, without the discount, on the receipt. opw-4179118 Before: ---------  After: -------  Forward-Port-Of: odoo/odoo#186176 Forward-Port-Of: odoo/odoo#183506
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/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
Steps to reproduce: ==== - Create a promotion program - Rule: Condition --> Select combo product, Reward --> type - discount specific product - Combo product - Open POS and add combo product. - Click on reward button and select on available reward. Issue: === - Promotion is not applied if combo product is added. Fix: === - Previously, when a specific combo product was added as a loyalty reward, it wasn’t properly handled in promotions. This update ensures that combo products in
Original PR description
Steps to reproduce: ==== - Create a promotion program - Rule: Condition --> Select combo product, Reward --> type - discount specific product - Combo product - Open POS and add combo product. - Click on reward button and select on available reward. Issue: === - Promotion is not applied if combo product is added. Fix: === - Previously, when a specific combo product was added as a loyalty reward, it wasn’t properly handled in promotions. This update ensures that combo products included in loyalty rewards and promotion is applied. task-4285895 Forward-Port-Of: odoo/odoo#186181 Forward-Port-Of: odoo/odoo#185780
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 Forward-Port-Of: odoo/enterprise#73309
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 Forward-Port-Of: odoo/enterprise#73309
**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
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
### Steps to reproduce: - In the settings: enable "Multi-Step Routes" and "Rental Transfers" - Inventory > Configuration > Warehouse Management > Locations - Create an internal child location of WH: WH/Shed - Inventory > Configuration > Warehouse Management > Routes - Copy the Rental route and set as applicatble on Sales order lines - On that custom route add a custom pull rule to generate the delivery: - Pull rule, source: Partner/customer/Rental, destination: WH/Shed, make_to_stock,
Original PR description
### Steps to reproduce: - In the settings: enable "Multi-Step Routes" and "Rental Transfers" - Inventory > Configuration > Warehouse Management > Locations - Create an internal child location of WH:…
### Steps to reproduce: - In the settings: enable "Multi-Step Routes" and "Rental Transfers" - Inventory > Configuration > Warehouse Management > Locations - Create an internal child location of WH: WH/Shed - Inventory > Configuration > Warehouse Management > Routes - Copy the Rental route and set as applicatble on Sales order lines - On that custom route add a custom pull rule to generate the delivery: - Pull rule, source: Partner/customer/Rental, destination: WH/Shed, make_to_stock, delivery (should create a delivery from WH/Shed to Partner/customer/Rental if a need appears there.) - Create a rental order with one line: - 1 x a rentable product + set route to the custom rental route - Confirm the rental order #### > 2 pickings were created using the default rental route rather than the custom rental route set on the line. ### Cause of the issue: During the `action_confirm` of the rental `sale.order` the `action_launch_stock_rule` is trigged on the sale order lines of the order to create and run the procurements that will generate the associated pickings: https://github.com/odoo/odoo/blob/22d09b6f9463a803dcd862455207ef700dd74408/addons/sale_stock/models/sale_order.py#L150-L152 However, if the procurement is generated from a rental order line and the rental tranfer is enabled, the route used for the procurment will be harcoded here: https://github.com/odoo/enterprise/blob/bdfea75c986af2d0ed91aae4178a29f1f450c2ea/sale_stock_renting/models/sale_order_line.py#L337-L340 rather than using the values previously set by the line: https://github.com/odoo/odoo/blob/22d09b6f9463a803dcd862455207ef700dd74408/addons/sale_stock/models/sale_order_line.py#L243 opw-4268117 --- Forward-Port-Of: odoo/enterprise#73306
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
_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#73397Problem: When rental dates are changed in the cart, the update occurs via an API call, which doesn't trigger the `_onchange_rental_start_date` and `_onchange_rental_return_date` methods. Additionally, we cannot add `rental_return_date` and `rental_start_date` as dependencies for `_compute_name` as outlined in this [commit](https://github.com/odoo/enterprise/commit/de5f3c7521d839e7549f5d44c7832e610fad7f29). Solution: Recompute the description after changing the dates in `_cart_update_renting
Original PR description
Problem: When rental dates are changed in the cart, the update occurs via an API call, which doesn't trigger the `_onchange_rental_start_date` and `_onchange_rental_return_date` methods. Additionally, we cannot add `rental_return_date` and `rental_start_date` as dependencies for `_compute_name` as outlined in this [commit](https://github.com/odoo/enterprise/commit/de5f3c7521d839e7549f5d44c7832e610fad7f29). Solution: Recompute the description after changing the dates in `_cart_update_renting_period` Steps to reproduce: - Add any rental product to the cart. - On the cart page, modify the rental start and end dates. - The order description does not update to reflect the new dates. opw-4259443 Forward-Port-Of: odoo/enterprise#72201
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
after this [FIX](https://github.com/odoo/enterprise/commit/ffcc8c425b53df94d79ace17fb444504df8acd52), the access to answers of feedbacks is restricted to the manager of appraisals, but the officer should have access too. this commit fixes this issue. opw-4128638 Forward-Port-Of: odoo/enterprise#72357
Original PR description
after this [FIX](https://github.com/odoo/enterprise/commit/ffcc8c425b53df94d79ace17fb444504df8acd52), the access to answers of feedbacks is restricted to the manager of appraisals, but the officer should have access too. this commit fixes this issue. opw-4128638 Forward-Port-Of: odoo/enterprise#72357
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
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