Monday, December 23, 2024
13 changes · 17.0
Enhancements to existing features
This update adds a commonly needed installation helper so it is installed automatically with the project requirements. It reduces manual setup steps for people preparing the system and may make new installations smoother.
Original PR description
Description of the issue/feature this PR addresses: I got tired of installing wheel manually, so i added wheel at the top of requirements.txt to be installed automatically Current behavior before PR: Had to manually install wheel Desired behavior after PR is merged: Wheel gets to be installed automatically --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The website checkout payment page now displays long terms and conditions text without covering other page content. This improves the customer checkout experience by keeping the page readable and easier to complete.
Original PR description
This PR fixes an issues about the terms & conditions overlapping the rest of the content on the `website_sale` payment page. Prior to this PR, the terms & conditions was positioned using a `position-absolute` with a `bottom-0`, resulting in the element extending to the topside if its content is very long. This led to some overlapping issues with the others elements of the view. To prevent this issue to happen, we position the element with a `top-100` and remove the `<div>` that aimed to handle the spacing at the bottom. We now manage this spacing with a utility class. opw-4373853 | 17.0 | This PR | |--------|--------| | <img width="472" alt="image" src="https://github.com/user-attachments/assets/6b4b768f-9764-45aa-84b8-94fcab059f30" /> | <img width="461" alt="image" src="https://github.com/user-attachments/assets/5cd8548e-9b8f-4036-84dd-3f224779af27" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The domain for inverses is not always correct and may crash for computed fields. Resolve the `get_depends` using the `get_domain_list` whenever possible. task-4380712 odoo/enterprise#75965 *FIX for master* in https://github.com/odoo/odoo/pull/191351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191319
Original PR description
The domain for inverses is not always correct and may crash for computed fields. Resolve the `get_depends` using the `get_domain_list` whenever possible. task-4380712 odoo/enterprise#75965 *FIX for master* in https://github.com/odoo/odoo/pull/191351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191319
Chart scale labels in spreadsheets now respect the user’s localization settings, such as number formatting conventions. This makes chart values easier to read and interpret correctly for users in different regions.
Original PR description
## Description Previously, the scale ticks in Odoo charts did not respect localization settings. This PR resolves the issue by leveraging the formatValue method within the scale tick callback function. Task: [4273769](https://www.odoo.com/odoo/project/2328/tasks/4273769) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an accounting issue that could cause an invoice-related test to fail when the accounting add-on was installed. It improves reliability around tracking whether invoices are being sent, helping prevent inconsistent behavior in accounting workflows.
Original PR description
Description of the issue/feature this PR addresses: The unit test "test_invoice_multi" from account fails when the account_accountant module is installed. Current behavior before PR: 1. Install account_accountant 2. Running the unit test test_invoice_multi and the you will see that causes a failure. Desired behavior after PR is merged: The unit test test_invoice_multi passes successfully, even with the account_accountant module installed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
OCR updates on expenses and invoices now consistently show OdooBot as the note author, keeping activity history clear and trustworthy. Receipt filenames containing dots are also handled correctly, so OCR processing is not skipped unexpectedly.
Original PR description
Before this commit, when the content of the expense is updated by OCR, the author might not be "OdooBot". This happened because while filling the document with results (in hr_expense._predict_product) there is a savepoint that removes the author. This commit sets the OCR note author after filling the document with results, which makes sure that the correct author (i.e., OdooBot) is always set. Moreover, if the expense receipt has a dot in its name, the _predict_product was never visited. So, the attachment name extraction is fixed to make sure that only file extension was removed. This commit also adds unit tests to expense and invoice OCR extract to make sure that their notes are authored by OdooBot. The test was not introduced in hr.applicant, however, since OCR does not change any tracked fields (i.e., OCR never logs a note on the chatter). task-4197413
This update resolves a problem where two Datev export files had the same name, causing confusion and inefficiency. The change ensures distinct file names for each export, streamlining the process and improving data organization. This fix ensures accurate and reliable Datev reporting.
Original PR description
The 2 exports have the same name, which is impractical. Let's differentiate them task-4414223 Forward-Port-Of: odoo/enterprise#75907
This update corrects a minor issue where some labels were missing in English for the Mexican reports module. Specifically, the `l10n_mx_nationality` and `l10n_mx_type_of_operation` fields now have accurate English translations. This ensures proper reporting functionality for users in Mexico.
Original PR description
Add missing english labels for the `l10n_mx_nationality` and `l10n_mx_type_of_operation`fields.  task-no Forward-Port-Of: odoo/enterprise#76038
This update fixes a bug in the account reconciliation process. Previously, the system only flagged discrepancies when the ending balance didn't match the transaction sum. Now, it also identifies issues when the starting balance doesn't align with the previous statement's ending balance, ensuring more accurate reconciliation reports.
Original PR description
### Before The 'Invalid Statements' filter only considered the case of the Ending Balance not matching the Starting Balance + the sum of its transactions. We were not considering the case of the Starting Balance of the statement not matching the previous statement's Ending Balance. ### Now Fixed the condition of the filter to account for the second case. task-4397412
This update corrects a bug that prevented users from accessing CRM leads during testing. The fix ensures proper permission controls are enforced, preventing unauthorized access. This improves the reliability of our CRM test environment.
Original PR description
Fixing permission access error in the test (user does not have access to crm.lead). task-4380712 odoo/odoo#191319 Forward-Port-Of: odoo/enterprise#75965
For an expense report paid by an employee, the bank account set on the employee form should be used to create the Journal Entry and as a default bank account in Register Payment Wizard. task-4379148 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189967
Original PR description
For an expense report paid by an employee, the bank account set on the employee form should be used to create the Journal Entry and as a default bank account in Register Payment Wizard. task-4379148 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189967
**Issue:** When printing a Purchase Order or Quotation in a company using the Indonesian tax chart, a tax code (Indonesian tax description) appears instead of the tax percentage. **Steps to Reproduce:** 1- Ensure the company uses the Indonesian chart of accounts. - Install the l10n_id module. - Go to Settings > Taxes and set the Fiscal Country to Indonesia. 2- Navigate to Purchase and create a Purchase Order. 3- Add a product line and select an Indonesian tax (ex: 11%). 4- Print the
Original PR description
**Issue:** When printing a Purchase Order or Quotation in a company using the Indonesian tax chart, a tax code (Indonesian tax description) appears instead of the tax percentage. **Steps to…
**Issue:** When printing a Purchase Order or Quotation in a company using the Indonesian tax chart, a tax code (Indonesian tax description) appears instead of the tax percentage. **Steps to Reproduce:** 1- Ensure the company uses the Indonesian chart of accounts. - Install the l10n_id module. - Go to Settings > Taxes and set the Fiscal Country to Indonesia. 2- Navigate to Purchase and create a Purchase Order. 3- Add a product line and select an Indonesian tax (ex: 11%). 4- Print the Purchase Order. The printed Purchase Order displays the tax code (description) instead of the tax percentage. The same behavior occurs in the Sales module regarding quotation printing (see screenshots attached) <img src ="https://github.com/user-attachments/assets/08dd6940-e07e-4e44-9f03-85f8ae2e8914" width=300 /> <img src ="https://github.com/user-attachments/assets/a8d16f6c-c6a0-441f-8c3f-3546387fb4e6" width=300 /> opw-4333143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187703
Users may give gift cards to their customers. Acting like a payment method, gift cards will lower the total amount of a sale order up to 0. Currently, in case of fixed tax applied in the order, the tax amount cannot be covered with the card balance Steps to reproduce - Generate a Gift Card of 100$ - Create a Sale Order with a product having: - price: 90$ - quantity: 1 - A fixed tax of 10$ - Add the gift card to the order Issue: Fixed tax amount will be left uncovered. This
Original PR description
Users may give gift cards to their customers. Acting like a payment method, gift cards will lower the total amount of a sale order up to 0. Currently, in case of fixed tax applied in the order, the tax amount cannot be covered with the card balance Steps to reproduce - Generate a Gift Card of 100$ - Create a Sale Order with a product having: - price: 90$ - quantity: 1 - A fixed tax of 10$ - Add the gift card to the order Issue: Fixed tax amount will be left uncovered. This is an issue because when using the gift card (or anyhow having the total 0), it means the fixed tax cost is supported by the merchant so it should be covered by the gift card opw-4422678 Forward-Port-Of: odoo/odoo#191321