Wednesday, November 6, 2024
17 changes · 17.0
Enhancements to existing features
The phone and mobile search tests were reorganized to make scenarios easier to understand, update, and debug. A few additional checks were added, improving confidence in contact search behavior without changing business workflows.
Original PR description
Use loops with clear input/expected structure to ease changes and debugging. Add few tests while passing by. Task-3943087
Resolved issues and error corrections
This fix ensures the accounting upgrade process waits for the system registry to be fully ready before proceeding. It prevents unnecessary warning messages that could interrupt automated checks, helping upgrades run more smoothly.
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
Miscellaneous changes
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#185811
The Project app no longer shows an empty Task Management section when none of its options are active. This avoids confusing users with leftover setting labels from a previously removed recurring task option.
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-prPrinting a sample event badge now works correctly when event barcodes are enabled. This prevents users from seeing an error when previewing or printing badge examples from an event.
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
The India localization settings no longer show an Enterprise-only prompt for e-invoicing when using the Community edition. This avoids confusion for users because the Indian e-invoicing module is available in Community addons.
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
Xendit payment failures now show the actual reason a payment attempt failed instead of a generic or incorrectly built status message. This helps staff and customers understand payment issues faster and reduces follow-up needed to diagnose failed transactions.
Original PR description
This commit is to fix the built status message when an error occured during payment. The fix is to display the actual reason behind failed payment attempt --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoice-based appointment payments now use the invoice ID in their payment reference instead of a placeholder slash. This makes transactions easier to identify before the invoice is officially posted and reduces confusion during payment reconciliation.
Original PR description
For appointments based on invoices (using the invoice transaction route, when ecommerce is not installed).
Adding a reference_prefix in order to avoid the "/" as prefix in transaction name for all transactions.
The "/" is the name of the invoice which is not defined yet at this stage as the invoice is not posted.
Using the id of the invoice to generate a transaction name as less confusing: INV{invoice_id}.
opw-4163413This update fixes an issue where duplicated shifts didn't correctly calculate allocated hours for different employees. Previously, duplicated shifts would incorrectly show 8 hours instead of the expected hours based on the employee's working schedule. This ensures accurate shift planning and time tracking.
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
This update resolves a bug where the 'release_to_pay' field in invoices was incorrectly reverting to 'Yes' after saving, even when set to 'No'. This issue prevented accurate payment processing. The fix ensures the field's value is correctly saved based on user selections.
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#72190
**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#180998When an exception occurred during a request to IAP, there was no way of knowing which one it was exactly. This log should help understand what went wrong. Related ticket for which this would have been helpful: #4276907 Forward-Port-Of: odoo/odoo#185535
Original PR description
When an exception occurred during a request to IAP, there was no way of knowing which one it was exactly. This log should help understand what went wrong. Related ticket for which this would have been helpful: #4276907 Forward-Port-Of: odoo/odoo#185535
Steps: - Create a loyalty program with reward_type product - add a tag in product_tag field which is linked to multiple products Issue: - Description is not updated Cause: - The compute_reward_description is not called when tag is updated Fix: - added product_tag in depends for the _compute_reward_description opw-4039914 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174135
Original PR description
Steps: - Create a loyalty program with reward_type product - add a tag in product_tag field which is linked to multiple products Issue: - Description is not updated Cause: - The compute_reward_description is not called when tag is updated Fix: - added product_tag in depends for the _compute_reward_description opw-4039914 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174135
After this commit 784f1511 , The `float_round()` functionality is changed. Before this commit, If the `qty_available` is 0.57: ``` In [2]: float_round(0.57,2) Out[2]: 0.5700000000000001 After this commit: In [2]: float_round(0.57,2) Out[2]: 0.57 ``` Now, while executing this line of code https://github.com/odoo/odoo/blob/baea953d248471e8aef60e02c1216f77941f1951/addons/mrp/models/product.py#L244 ``` Before: In [3]: 0.5700000000000001*100//1 Out[3]: 57.0 After: In [3]: 0.57*
Original PR description
After this commit 784f1511 , The `float_round()` functionality is changed. Before this commit, If the `qty_available` is 0.57: ``` In [2]: float_round(0.57,2) Out[2]: 0.5700000000000001 After this…
After this commit 784f1511 , The `float_round()` functionality is changed. Before this commit, If the `qty_available` is 0.57: ``` In [2]: float_round(0.57,2) Out[2]: 0.5700000000000001 After this commit: In [2]: float_round(0.57,2) Out[2]: 0.57 ``` Now, while executing this line of code https://github.com/odoo/odoo/blob/baea953d248471e8aef60e02c1216f77941f1951/addons/mrp/models/product.py#L244 ``` Before: In [3]: 0.5700000000000001*100//1 Out[3]: 57.0 After: In [3]: 0.57*100//1 Out[3]: 56.0 ``` These differences leads to blocking the upgrade process. ``` Traceback (most recent call last): File "/tmp/tmpft9eq3rf/migrations/testing.py", line 212, in test_check self.check(value) File "/tmp/tmpft9eq3rf/migrations/stock/tests/test_on_hand_quantity.py", line 90, in check self.assertEqual(before_results, self.convert_check(after_results), self.message) AssertionError: Lists differ: [[12,[7979 chars]6, '57'], [20249, '17.06'], [20250, '1705'], [[12354 chars]'1']] != [[12,[7979 chars]6, '56'], [20249, '17.06'], [20250, '1705'], [[12354 chars]'1']] First differing element 529: [20246, '57'] [20246, '56'] ``` upg-2096343 opw-4224012 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#183289
The YearPicker component globally sets MinViewModeNumber, which forces all DatePicker components on the same page to share the same selection granularity (e.g., years only). As a result, if a YearPicker is present, it becomes impossible to configure other DatePicker instances to select days or months. This commit is a backport of tempusdominus/core@8c119b86721691d659d4a6fcd8e94d6c16173d89 Reported in https://github.com/odoo/odoo/issues/183226 --- I confirm I have signed the CLA a
Original PR description
The YearPicker component globally sets MinViewModeNumber, which forces all DatePicker components on the same page to share the same selection granularity (e.g., years only). As a result, if a YearPicker is present, it becomes impossible to configure other DatePicker instances to select days or months. This commit is a backport of tempusdominus/core@8c119b86721691d659d4a6fcd8e94d6c16173d89 Reported in https://github.com/odoo/odoo/issues/183226 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186339
Description of the issue/feature this PR addresses: Described in #184497 Current behavior before PR: Error when selecting a template that contains field you don't have access to Desired behavior after PR is merged: No error occurs --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184943
Original PR description
Description of the issue/feature this PR addresses: Described in #184497 Current behavior before PR: Error when selecting a template that contains field you don't have access to Desired behavior after PR is merged: No error occurs --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184943
This error occurs when we are creating a new operation type in transfer. Steps to reproduce: --- - Install ``l10n_it_stock_ddt`` module - Switch company to ``IT Company`` - Go to transfer and create any new operation type Traceback: --- ``KeyError: 'code'`` At [1], we are facing this error because we are attempting to retrieve ``code`` from the ``vals``, but when we create a new operation type, we only receive ``name`` in the ``vals``. [1]- https://github.com/odoo/odoo/blob/248
Original PR description
This error occurs when we are creating a new operation type in transfer. Steps to reproduce: --- - Install ``l10n_it_stock_ddt`` module - Switch company to ``IT Company`` - Go to transfer and create any new operation type Traceback: --- ``KeyError: 'code'`` At [1], we are facing this error because we are attempting to retrieve ``code`` from the ``vals``, but when we create a new operation type, we only receive ``name`` in the ``vals``. [1]- https://github.com/odoo/odoo/blob/2489a4c4a5aae829bb7dafe24d93529767ce07db/addons/l10n_it_stock_ddt/models/stock_picking.py#L76 sentry-6037671568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186127