Wednesday, November 6, 2024
8 changes · 17.0
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
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