Daily updates from Odoo
Thursday, September 19, 2024
7 changes
1 change
Resolved issues and error corrections
This fixes an issue where loading Argentine localization demo data after database setup could fail because some sample products received duplicate default taxes. The affected demo products are now tied to the correct company, preventing errors when sample invoices or accounting entries are created.
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. opw-4180872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
6 changes
Resolved issues and error corrections
Tax closing entries will no longer automatically receive default taxes from accounts marked for tax closing. This prevents validation errors in special accounting setups and helps tax closing proceed reliably.
Original PR description
Some special cases may require to have an account set as "used in tax closing" and at the same time having a default tax to improve usability. This would cause issues as the tax would be set on the line and trigger the _check_taxes_on_closing_entries constrains. This fix aim to mitigate that by ensure that _compute_tax_ids is not done on tax closing lines. task id # 3903331
Marketing automation activity relationships now display correctly in hierarchy views. This restores needed parent relationship information so users can understand how campaign activities connect to each other.
Original PR description
Since [1] the hierarchy kanban is missing the necessary parent data to be able to properly display hierarchies We add it back with a comment specifying it needs to remain task-4195978 1: d07574d2a286543c22072fa4ea338ff756242f21
This fix prevents errors when multiple attachments are processed together for Indian GSTR reporting. It improves reliability in setups that use Indian localization alongside accounting features, helping reports and related PDF attachments work as expected.
Original PR description
The method `_unwrap_edi_attachments` previously failed when `self` contained more than one record. This caused issues, particularly in the test `test_extend_with_attachments_multi_pdf` when both `l10n_in` and `account_accountant` modules were installed. The issue has been fixed by adding a loop to process each record in `self` individually and checking the `res_model` for each attachment within the file data. Fixes: https://runbot.odoo.com/web/#id=98056&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form
This fixes an error that could occur when Monster recruitment integration credentials are missing. Users will no longer be blocked by a data comparison issue in that situation, making the recruitment posting flow more reliable.
Original PR description
consteq needs to compare the same type of data so bool and str can't be compared FIX convert the bool to str before comparing task-4196102
The Knowledge app’s automated cover selection test was corrected after it checked for a button that was no longer relevant. This helps keep quality checks stable and makes future issues in this area easier to diagnose.
Original PR description
In this commit, we fix the knowledge_cover_selector_tour tour.
Actually, the step 41 makes no sense.
{
// Make the add cover button visible
trigger: '.o_knowledge_edit_cover_buttons',
},
We check for edit cover buttons but the cover was removed in previous
steps.
we take advantage of the commit to transform the comments into "content"
to make it easier to debug the tour.
We take advantage of this commit to lint the file.The Knowledge permission panel was updated so it no longer depends on jQuery, which may not always be available. This prevents errors when managing permissions and helps keep the feature compatible with newer platform standards.
Original PR description
This commit removes the soon-to-be deprecated JQuery from the PermissionPanel component. JQuery triggered errors inside the permission panel when it is not loaded, which can happen. This commit replaces all JQuery calls to a standard JS alternative. task-4193620