Thursday, September 19, 2024
11 changes · 17.0
Enhancements to existing features
The Journal Items list no longer offers direct creation options for Tax Grids. This reduces accidental setup changes and keeps users focused on selecting existing tax grid records in accounting workflows.
Original PR description
Remove "Create" and "Create and Edit" of Tax Grids in the list view of Journal Items. task: 4179612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes the "Create" and "Create and Edit" options from the Tax Grids list view within Journal Items. This streamlines the user interface by preventing accidental creation of tax grids from this view, ensuring tax grid management follows a more controlled workflow.
Original PR description
Remove "Create" and "Create and Edit" of Tax Grids in the list view of Journal Items. task: 4179612
Resolved issues and error corrections
Creating a field service task from the calendar now works correctly when the selected customer has no zip code. This prevents an error caused by calling the wrong underlying process, improving reliability for field service scheduling.
Original PR description
Steps to reproduce:
- Install the FSM module.
- Open FSM and navigate to the calendar view.
- Create a task with a customer (without a zip code).
Issue:
The wrong method is being called. Currently, the code uses super.onWillStart();, but this is
incorrect as the method does not exist in the calendar model.
Fix:
We corrected the super method call.
task-3617833Miscellaneous changes
Version: 16.0+ Issue: A vendor bill paid with an existing check remains paid although the check has been removed. This is because the vendor payment is made with the check and the payment is still reconciled with the vendor bill. This will lead to inconsistent/erroneous display of the payment status of the vendor bill. Purpose of this PR: Prevent the check payments with other operations from being reset to draft or removed. Instead raise an error to notify the user that the payment is us
Original PR description
Version: 16.0+ Issue: A vendor bill paid with an existing check remains paid although the check has been removed. This is because the vendor payment is made with the check and the payment is still reconciled with the vendor bill. This will lead to inconsistent/erroneous display of the payment status of the vendor bill. Purpose of this PR: Prevent the check payments with other operations from being reset to draft or removed. Instead raise an error to notify the user that the payment is used for other account moves. Steps to reproduce in runbot: 1) set up latam checks in database 2) make an invoice and use a check as payment 3) make a bill and use the existing check to pay for the bill 4) go back to the invoice and reset the payment to draft and delete the payment 5) the vendor payment will remain and be marked as paid/partial paid opw-4189731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180522
This fix prevents Argentina demo data from failing during setup when loaded after database creation. Demo products are now tied to the correct company, avoiding duplicate default taxes that could block demo invoice installation.
Original PR description
### Steps to reproduce: - Create a db with `l10n_ar` but without demo data - In dev move at the bottom of the settings page: Load Demo data #### > UserError > load aborted. ### Cause of the issue:…
### Steps to reproduce: - Create a db with `l10n_ar` but without demo data - In dev move at the bottom of the settings page: Load Demo data #### > UserError > load aborted. ### Cause of the issue: Since commit 051d43dbef390de171307fe0e493d651c9ad7b4b (17.0), during the create of products, if the product is not associated to a given company, we add a default tax for each company that is not in the context (and hence should not have defined a tax yet): https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/account/models/product.py#L138-L146 However, if you were to create a DB without demo data and if you were loading the demo data from the UI, you will create demo datas product for companies that had already set a tax for that product (e.g. `company_ri` on the product `product_product_telefonia`) and since the current company is in the context the override of the create will add a second tax on these products for that companies. As such, if the product is later used in account moves it will raise a user error: https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/l10n_ar/models/account_move.py#L141-L144 and the installation of the all the demo datas will then be aborted. ### Fix: Since the demo data's products used in the account moves raising user errors are only expected to be used in the the company for which we have associated a tax eg: https://github.com/odoo/odoo/blob/b32fc0f715e41f6795972f2f8a2c3e4826357aa1/addons/l10n_ar/demo/account_supplier_invoice_demo.xml#L136 we simply add a company_id on these products. Note that the test datas had to be updated in somewhat a similar way in commit 051d43dbef390de171307fe0e493d651c9ad7b4b. ### Note: Since commit 7d9b791 (saas-17.2), the reference of the company has changed from `l10n_ar.company_ri` to `base.company_ri` so that the diff has to be adapted in foraward ports. opw-4180872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures an existing automated test file is properly included when the sale-purchase-stock module test suite runs. It helps prevent related scheduling and lead time issues from slipping through future updates, with no direct change to day-to-day user workflows.
Original PR description
This commit add the missing test file in `__init__.py` 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
Fixed a PDF formatting issue in the General Ledger where the communication and partner columns could overlap for medium-length text. This makes printed accounting reports easier to read and helps avoid confusion when reviewing ledger details.
Original PR description
When printing a PDF report of the General Ledger, the columns for "communication" and "partner" overlap if the "communication" column's length is between 40 and 65 characters. This issue occurs because we only apply o_overflow_value for lengths greater than 65 characters. **To reproduce in Runbot, follow these steps:** 1) Navigate to Accounting > Reporting > General Ledger. 2) Print the report in PDF format (you will find some columns are overlapping). - **OPW: 4113571** - **UPG: 1782821** **Runbot snap before Fix:**  **Runbot snap after Fix:** 
You should not be able to archive a journal used in a payment method. Steps to reproduce: ------------------- * Go on any journal used in a payment method (e.g. Cash) * Archive the journal > Observation: You are still able to use the payment method without the journal being active Note: --------------- Similar fix was done for the point of sale here : https://github.com/odoo/odoo/pull/177751 opw-4070620 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo
Original PR description
You should not be able to archive a journal used in a payment method. Steps to reproduce: ------------------- * Go on any journal used in a payment method (e.g. Cash) * Archive the journal > Observation: You are still able to use the payment method without the journal being active Note: --------------- Similar fix was done for the point of sale here : https://github.com/odoo/odoo/pull/177751 opw-4070620 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180487
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180639
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180639
This error occurs when attempting to add a payment using the ``Quick Add`` feature in the Kanban view. Steps to reproduce: - Install the ``pos_online_payment`` module - Point of Sale > Orders > Payments > Go to Kanban view - Click on the ``Quick Add`` button and ``Add`` Traceback: ``KeyError: 'payment_method_id'`` The error in [1] occurred because the ``payment_method_id`` was not found in the vals. This commit will fix the above error by removing the Kanban view from payments be
Original PR description
This error occurs when attempting to add a payment using the ``Quick Add`` feature in the Kanban view. Steps to reproduce: - Install the ``pos_online_payment`` module - Point of Sale > Orders > Payments > Go to Kanban view - Click on the ``Quick Add`` button and ``Add`` Traceback: ``KeyError: 'payment_method_id'`` The error in [1] occurred because the ``payment_method_id`` was not found in the vals. This commit will fix the above error by removing the Kanban view from payments because we never allow payment creation. [1]- https://github.com/odoo/odoo/blob/42ab53925b140508e2aa837ce09c914b8f243b21/addons/pos_online_payment/models/pos_payment.py#L20 sentry-5750182450 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180557
In Factur-X, it is sometimes required to specify the SIRET (using the node `SpecifiedLegalOrganization`). The SIRET is a field appearing when l10n_fr is installed. In addition, in 17.0, it only appears if the current company has the French CoA installed. Hence, it is not possible to specify a SIRET on a French partner if the company is Belgian, for instance. To fix this, we also use the company_registry to fill the SIRET node in the xml. In master, we intend to remove the SIRET field, as w
Original PR description
In Factur-X, it is sometimes required to specify the SIRET (using the node `SpecifiedLegalOrganization`). The SIRET is a field appearing when l10n_fr is installed. In addition, in 17.0, it only appears if the current company has the French CoA installed. Hence, it is not possible to specify a SIRET on a French partner if the company is Belgian, for instance. To fix this, we also use the company_registry to fill the SIRET node in the xml. In master, we intend to remove the SIRET field, as we should have used the company_registry from the beginning instead. opw-4174309 Forward-Port-Of: odoo/odoo#180321