Friday, September 20, 2024
43 changes · saas-17.4
Resolved issues and error corrections
This update fixes a community-only issue in Italian electronic invoicing tests caused by different payment status values between community and enterprise setups. It now relies on matching document numbers instead of payment status and avoids unnecessary processing for non-Italian companies.
Original PR description
The test "test_account_move_payment_method" was failing in community only because the payment_state is paid if only l10n_it is installed but is in_payment if the enterprise module is installed. We decided to totally remove the if statement on the payment_state. The matching numbers are enough. Also adding some early returns in the compute to make sure we don't do the search on account.move.line for nothing or compute the document type for non italian companies. fw-port of: https://github.com/odoo/odoo/pull/178235 no task-id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale category menu now keeps child categories in a consistent order when staff navigate between them. This avoids confusing changes in the sales interface and helps cashiers find products more reliably.
Original PR description
Problem:
When clicking on a category with child categories in PoS, the order of the child categories changes unpredictably, leading to inconsistencies.
Steps to reproduce:
- Create PoS categories:
> Parent A category > Child1 A category > Child2 B category
> Parent B category > Child1 B category > Child2 A category
- Open PoS and navigate between categories.
- You'll notice inconsistent ordering when selecting child categories and their subcategories.
opw-4184020
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCanned reply suggestions now keep more of the reply name visible when both the name and description are too long. This makes it easier for users to identify and choose the right saved response in the chat composer.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/180438 PR above fixes an issue where the canned reponse was overflowing in chat window when its name is longer than composer width. The fix however introduced problem where description was truncating the name of canned response heavily. The description is usually very long while the name is short, and people tend to find the canned response based on name, so this makes canned response less practical. This commit fixes the issue by forcing description to take up to 20% width when both the name and description overflow. opw-4196113 Before / After <img width="322" alt="Screenshot 2024-09-19 at 17 04 01" src="https://github.com/user-attachments/assets/f74bdd9f-b94e-4887-a033-8eec2cf22aae"> <img width="320" alt="Screenshot 2024-09-19 at 17 04 17" src="https://github.com/user-attachments/assets/0d243371-f6b7-40cd-9d89-97d18d387ab8">
This fix prevents a crash when users try the sample vendor bill flow for a newly created company without the required accounting journal setup. Instead of showing a technical error, Odoo now handles the missing setup consistently and shows a clearer business-facing message.
Original PR description
The error occurs when we click on the button ``try our sample`` by creating a new company. Steps to reproduce: - Install the ``account`` module(without demo data) - Create a new ``Company`` - Go to a newly created company - Invoicing > Vendors > Bills - Click on ``try our sample`` Traceback: ``AttributeError: 'bool' object has no attribute 'id'`` This error occurs at [1], where we are receiving ``default_expense_account`` as False. This commit will resolve the above error by raising an error if no journal exists in that particular company. [1]- https://github.com/odoo/odoo/blob/f80f1a27152c5fc38253fa59d7a24206d5774a6b/addons/account/models/account_journal_dashboard.py#L878 sentry-5722721931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now save Batch Transfers after removing the Dock Location without encountering an error. This improves reliability for inventory operations using fleet-related stock workflows.
Original PR description
This error occurs when attempting to save a ``Batch Transfer`` without specifying a ``Dock Location``. Steps to reproduce: - Install the ``stock_fleet`` module - Activate ``Storage Locations`` in Configuration of Inventory - Now go to ``Batch Transfers`` in Operations and Create new - Now add ``Dock Location`` and save - Now Remove ``Dock Location`` and save Traceback: ``AttributeError: 'stock.picking.batch' object has no attribute 'location_dest_id'`` The error in [1] occurred because the ``location_dest_id`` field is not part of the ``stock.picking.batch`` model but belongs to the ``stock.picking`` model. This commit resolves the error by adding ``picking_ids``, allowing us to retrieve the ``location_dest_id``. [1]- https://github.com/odoo/odoo/blob/45e75693e8ee4f8cf9af842cd2facd4f2f6356d8/addons/stock_fleet/models/stock_picking_batch.py#L81 sentry-5825702049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures accounting tests for duplicate payments remain reliable when they run across midnight. It prevents timing-related false failures in automated checks, helping maintain confidence in payment duplicate detection without changing user-facing behavior.
Original PR description
If the payments created in the setUpClass happen Monday at 23:59, and the actual test create duplicate on the following day (at 0:00), it won't be recognized as duplicate. runbot-97948 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale setup flow now skips missing product categories instead of crashing when users open the Clothes onboarding scenario. This helps stores continue configuration even if a default category was previously removed.
Original PR description
Currently, an error occurs when trying to load onboarding clothes. Step to produce: - Install the 'point_of_sale' module. - Go to the point of Sale / Configuration / Products / Pos Product…
Currently, an error occurs when trying to load onboarding clothes.
Step to produce:
- Install the 'point_of_sale' module.
- Go to the point of Sale / Configuration / Products / Pos Product Categories, and Delete the record name 'Upper body'.
- Go to 'Dashboard' to archive all sessions, Click on the 'Clothes' scenario card.
Stack Trace:
```
KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7fe08b6ffd80>, 'point_of_sale.pos_category_upper')
File "odoo/tools/cache.py", line 103, in lookup
r = d[key]
File "decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "odoo/tools/func.py", line 84, in locked
return func(inst, *args, **kwargs)
File "odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
ValueError: External ID not found in the system: point_of_sale.pos_category_upper
File "odoo/http.py", line 2373, in __call__
response = request._serve_db()
File "odoo/http.py", line 1903, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1966, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1933, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/point_of_sale/models/pos_config.py", line 924, in load_onboarding_clothes_scenario
self.env.ref('point_of_sale.pos_category_upper').id,
File "odoo/api.py", line 584, in ref
res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
File "odoo/addons/base/models/ir_model.py", line 2229, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)
File "decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "odoo/tools/cache.py", line 110, in lookup
value = d[key] = self.method(*args, **kwargs)
File "odoo/addons/base/models/ir_model.py", line 2222, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
```
An error occurs when the system tries to retrieve an external ID 'point_of_sale.pos_category_upper' at [1] when opening a 'Clothes' scenario card in POS, but it is not available.
link [1]: https://github.com/odoo/odoo/blob/475459d06dfb81031812fd0d1813d13eb865451f/addons/point_of_sale/models/pos_config.py#L923-L927
To handle this issue, add a method in the pos.config model that filters out unavailable external IDs.
Sentry-5667341424
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSpanish Facturae e-invoice files now include the product sales description in item descriptions, not just the product name. This restores expected behavior from earlier versions and helps customers send more complete invoice details to recipients.
Original PR description
Steps to reproduce: - Switch to ES company - Products > Sales tab > Add sales description - Invoice that product > Confirm - Send & Print > Tick 'Generate Facturae edi file' - Download the xml facturae file - ItemDescription only contains the product name We expect the ItemDescription to contain the product's sale description as well, which is the behavior of versions 17.2 and prior. The change was introduced in 4f325ef620263c27e095eb49026a677ac617a0ee. opw-4181520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Corrects an issue in the German reports module where a recently changed database query could return incorrect or unreliable results. This helps ensure DATEV-related partner/reporting data is processed accurately for German accounting workflows.
Original PR description
Fixup of a bad query introduced in https://github.com/odoo/enterprise/commit/63d4ec0e7f57aa8e93f31436e9ac91465c8d1f69 opw-4163804
Miscellaneous changes
Versions -------- - 16.0+ Steps ----- 1. Try to import a malformed OFX file into a bank journal; 2. close traceback; 3. try to import a valid OFX or CSV file. Issue ----- Same traceback as first upload. Cause ----- There's no error handling on the RPC call. If the file is successfully imported, the `attachmentIdsToProcess` gets clear, but if there's an error, the bad file remains in the queue until leaving the view. Solution -------- Put the RPC call in a `try` block, and
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Try to import a malformed OFX file into a bank journal; 2. close traceback; 3. try to import a valid OFX or CSV file. Issue ----- Same traceback as first upload. Cause ----- There's no error handling on the RPC call. If the file is successfully imported, the `attachmentIdsToProcess` gets clear, but if there's an error, the bad file remains in the queue until leaving the view. Solution -------- Put the RPC call in a `try` block, and clear the `attachmentIdsToProcess` in `finally` to ensure this happens regardless of outcome. opw-4113740 Forward-Port-Of: odoo/odoo#180845
Updated imports for `zeep.wsse` components to explicitly import modules. This change is required because zeep 4.2.0 introduced an `__all__` declaration in `zeep.wsse`: ``` __all__ = [ "Compose", "BinarySignature", "MemorySignature", "Signature", "UsernameToken", ] ``` The __all__ prevents using wildcard imports for all wsse submodules as we did before. Steps to Reproduce: - Install the l10n_nl_reports_sbr module. - Navigate to Accounting > Report > Tax Rep
Original PR description
Updated imports for `zeep.wsse` components to explicitly import modules.
This change is required because zeep 4.2.0 introduced an `__all__` declaration in `zeep.wsse`:
```
__all__ = [
"Compose",
"BinarySignature",
"MemorySignature",
"Signature",
"UsernameToken",
]
```
The __all__ prevents using wildcard imports for all wsse submodules as we did before.
Steps to Reproduce:
- Install the l10n_nl_reports_sbr module.
- Navigate to Accounting > Report > Tax Report.
- Select XBRL from the dropdown menu on the PDF button in the top left corner.
- Attempt to send the document.
- An error will occur:
```
Copy code
File "/home/odoo/src/enterprise/saas-17.4/l10n_nl_reports_sbr/wizard/l10n_nl_reports_sbr_tax_report_wizard.py", line 168, in __init__
wsse.signature.MemorySignature.__init__(
^^^^^^^^^^^^^^
AttributeError: module 'odoo.tools.zeep.wsse' has no attribute 'signature'
````
opw-4181876
Forward-Port-Of: odoo/odoo#180857Create a company: - Name: Any - Country: Argentina - AFIP Responsibility Type: IVA Responsable Inscripto Save Issue: Company AFIP Type will be set back to Responsable Monotributo This occurs because when company is created the system will try to load the coa. The COA to load is currently determined only by the country of the new company, and the default for new Argentina companies is 'Responsable Monotributo' Then, the AFIP Type is changed to match the CoA In order to take into
Original PR description
Create a company: - Name: Any - Country: Argentina - AFIP Responsibility Type: IVA Responsable Inscripto Save Issue: Company AFIP Type will be set back to Responsable Monotributo This occurs because when company is created the system will try to load the coa. The COA to load is currently determined only by the country of the new company, and the default for new Argentina companies is 'Responsable Monotributo' Then, the AFIP Type is changed to match the CoA In order to take into account the company settings when loading the CoA we check via context if we are operating on a company and load the template matching the AFIP Type opw-4175351 Forward-Port-Of: odoo/odoo#180356
- Have a x2many on your view; - Edit another field that through a onChange modify the x2many; - Discard the changes. Before this commit, the x2many didn't come back to its initial state. Now, the x2many will came back to its initial state. Note that this commit is a fix up of [1] which already address part of this issue. [1] https://github.com/odoo/odoo/commit/e450d03a5f4fc80198837cccf10fa349ecc205a9 Forward-Port-Of: odoo/odoo#180829
Original PR description
- Have a x2many on your view; - Edit another field that through a onChange modify the x2many; - Discard the changes. Before this commit, the x2many didn't come back to its initial state. Now, the x2many will came back to its initial state. Note that this commit is a fix up of [1] which already address part of this issue. [1] https://github.com/odoo/odoo/commit/e450d03a5f4fc80198837cccf10fa349ecc205a9 Forward-Port-Of: odoo/odoo#180829
- Install `l10n_in` - create a branch for the Indian company - install `l10n_in_withholding` - traceback If there an Indian company has a branch, installing `l10n_in_withholding` raises an RPC error on the branch company, because the TDS group is not set on it. Since branches use the COA of the parent company, we don't need to load further. Task [link](https://www.odoo.com/odoo/project/967/tasks/4143223) task-4143223 Forward-Port-Of: odoo/odoo#178305
Original PR description
- Install `l10n_in` - create a branch for the Indian company - install `l10n_in_withholding` - traceback If there an Indian company has a branch, installing `l10n_in_withholding` raises an RPC error on the branch company, because the TDS group is not set on it. Since branches use the COA of the parent company, we don't need to load further. Task [link](https://www.odoo.com/odoo/project/967/tasks/4143223) task-4143223 Forward-Port-Of: odoo/odoo#178305
* PROPBLEM: In form view we try to use m2o.field_name which is 'l10n_vn_edi_replacement_origin_id.l10n_vn_edi_invoice_number', odoo doesn't support that so it will not work at least in form view * SOLUTION: this commit make the invisible condition more simpler and create a non-store field to fix the issue 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
Original PR description
* PROPBLEM: In form view we try to use m2o.field_name which is 'l10n_vn_edi_replacement_origin_id.l10n_vn_edi_invoice_number', odoo doesn't support that so it will not work at least in form view * SOLUTION: this commit make the invisible condition more simpler and create a non-store field to fix the issue 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#180818
Before this commit, entering a payment amount with cash rounding higher than one (e.g., 10) incorrectly triggered an error popup every time. opw-4124332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179298 Forward-Port-Of: odoo/odoo#177547
Original PR description
Before this commit, entering a payment amount with cash rounding higher than one (e.g., 10) incorrectly triggered an error popup every time. opw-4124332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179298 Forward-Port-Of: odoo/odoo#177547
In a Spanish company if you don't have a certificate set on the company, the PoS would generate a proforma invoice instead of a normal invoice. Steps to reproduce: ------------------- * Install l10n_es_pos * Remove the l10n_es_edi_facturae_certificate_id from the company * Open PoS * Make an order and invoice it > Observation: The invoice generated is a proforma invoice instead of a normal invoice Why the fix: ------------ When generating the invoice data in `_generate_pdf_and_sen
Original PR description
In a Spanish company if you don't have a certificate set on the company, the PoS would generate a proforma invoice instead of a normal invoice. Steps to reproduce: ------------------- * Install l10n_es_pos * Remove the l10n_es_edi_facturae_certificate_id from the company * Open PoS * Make an order and invoice it > Observation: The invoice generated is a proforma invoice instead of a normal invoice Why the fix: ------------ When generating the invoice data in `_generate_pdf_and_send_invoice` the wizard would have `l10n_es_edi_facturae_checkbox_xml` checked by default This leads to the generation of a specific invoice that will fail because there are no certificate setup on the company. This will then fallback to the proforma invoice. opw-4074779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179107
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…
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#180788 Forward-Port-Of: odoo/odoo#180522
Following #156437, the new default setup for multi-step deliveries is through the new push rules. This means that when you trigger a delivery to a customer, it will first create the PICK before creating the delivery. This means that now we need to check on the `location_final_id` if it exists before checking the `location_dest_id`, as it holds the real destination of the move to consider it as an 'out' move or not. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo
Original PR description
Following #156437, the new default setup for multi-step deliveries is through the new push rules. This means that when you trigger a delivery to a customer, it will first create the PICK before creating the delivery. This means that now we need to check on the `location_final_id` if it exists before checking the `location_dest_id`, as it holds the real destination of the move to consider it as an 'out' move or not. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180657
Currently if there is any automation rule set to trigger on save on res.users, an error will be thrown any time there is a change made to the groups on a user. This is due to the changed field being a sel_groups... field which does not actually exist on the res.users model. To circumvent this, logic has been added to identify when a field is a selection group field, and pull the correct existing group from the groups_id field on the record using set logic. OPW: 4152636 --- I confirm I hav
Original PR description
Currently if there is any automation rule set to trigger on save on res.users, an error will be thrown any time there is a change made to the groups on a user. This is due to the changed field being a sel_groups... field which does not actually exist on the res.users model. To circumvent this, logic has been added to identify when a field is a selection group field, and pull the correct existing group from the groups_id field on the record using set logic. OPW: 4152636 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180367
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 Forward-Port-Of: odoo/odoo#178377
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 Forward-Port-Of: odoo/odoo#178377
With the old pull rules, pickings were created up to the last step before reception (i.e. Input in multi-step reception) which would be all in the procurement group. Then, once the purchase order is validated, then reception move would be the orig of that last step move. In this case, the link would work properly. However, with the new push rules, the move that trigget the creation of the purchase order is no longer Input -> Stock, but the first step of delivery. This still works correctly un
Original PR description
With the old pull rules, pickings were created up to the last step before reception (i.e. Input in multi-step reception) which would be all in the procurement group. Then, once the purchase order is validated, then reception move would be the orig of that last step move. In this case, the link would work properly. However, with the new push rules, the move that trigget the creation of the purchase order is no longer Input -> Stock, but the first step of delivery. This still works correctly until the first reception step is completed, but then the move_orig of the Stock -> Output is no longer Vendor -> Input, but Input -> Stock, which doesn't contain the link to the purchase order. This means we have to rollup the orig of the move to get to the actual purchase order, regardless of the number of extra steps in between. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179964
* STEP TO REPRODUCE: go to configuration -> project -> switch to list view -> can't change sequence of project * REASON: in project.view_project_config we use invisible instead of column_invisible and the default_order in tree are "is_favorite desc, sequence, name, id" not like in v16 are "sequence, name, id" * SOLUTION: Change invisible -> column_invisible and change default_order of project config view to "sequence, name, id" Close https://github.com/odoo/odoo/issues/176961 Forward-Port-
Original PR description
* STEP TO REPRODUCE: go to configuration -> project -> switch to list view -> can't change sequence of project * REASON: in project.view_project_config we use invisible instead of column_invisible and the default_order in tree are "is_favorite desc, sequence, name, id" not like in v16 are "sequence, name, id" * SOLUTION: Change invisible -> column_invisible and change default_order of project config view to "sequence, name, id" Close https://github.com/odoo/odoo/issues/176961 Forward-Port-Of: odoo/odoo#180403
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 Forward-Port-Of: odoo/odoo#179930
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 Forward-Port-Of: odoo/odoo#179930
Before this commit, since the design changes, the form with html expander no longer works. This commit adapts the code to expand the html field as before to take the remaining height unused by the form view when we first load the form view of `project`. task-3258533 Forward-Port-Of: odoo/odoo#168812
Original PR description
Before this commit, since the design changes, the form with html expander no longer works. This commit adapts the code to expand the html field as before to take the remaining height unused by the form view when we first load the form view of `project`. task-3258533 Forward-Port-Of: odoo/odoo#168812
### 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/bl
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 Forward-Port-Of: odoo/odoo#180420
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-3617833 Forward-Port-Of: odoo/odoo#180724
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-3617833
Forward-Port-Of: odoo/odoo#180724Currently, An error is generated while a user is trying to open the 'Profit and Loss' report when balance sheet report is not available Steps to reproduce: - Install an ```account_reports``` module. - Turn on debugger mode (from SAAS-17.2 no need this). - Navigate to Accounting / Configuration / Management / Accounting Reports, Delete the 'Balance Sheet' report - And Open 'Profit and Loss' report(In Accounting Reports). ```ValueError: External ID not found in the system: account_rep
Original PR description
Currently, An error is generated while a user is trying to open the 'Profit and Loss' report when balance sheet report is not available Steps to reproduce: - Install an ```account_reports``` module.…
Currently, An error is generated while a user is trying to open the 'Profit and Loss' report when balance sheet report is not available Steps to reproduce: - Install an ```account_reports``` module. - Turn on debugger mode (from SAAS-17.2 no need this). - Navigate to Accounting / Configuration / Management / Accounting Reports, Delete the 'Balance Sheet' report - And Open 'Profit and Loss' report(In Accounting Reports). ```ValueError: External ID not found in the system: account_reports.balance_sheet``` An error occurs when the system tries to retrieve an external id of balance sheet report 'account_reports.balance_sheet' at [1], but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/9d185d78813f776249a4de0469d659723a94d026/account_reports/models/account_report.py#L5401 To handle this issue, add 'raise_if_not_found=False' in ref() so that when balance sheet report is not available it will return a None value instead of traceback. Sentry-5836075163 Forward-Port-Of: odoo/enterprise#69989
Steps to reproduce traceback: 1. Create an overseas invoice with `IGST 0` 2. Post the Invoice 3. Create GSTR Report for the following month 4. Click on Generate Button traceback: ```py Traceback (most recent call last): File "/home/odoo/odoo/enterprise/l10n_in_reports_gstr/tests/test_gstr1_report.py", line 233, in test_gstr1_export_with_igst_zero gstr1_json = gstr1_report._get_gstr1_json() File "/home/odoo/odoo/enterprise/l10n_in_reports_gstr/models/gst_return_period.py", line 1
Original PR description
Steps to reproduce traceback: 1. Create an overseas invoice with `IGST 0` 2. Post the Invoice 3. Create GSTR Report for the following month 4. Click on Generate Button traceback: ```py Traceback…
Steps to reproduce traceback:
1. Create an overseas invoice with `IGST 0`
2. Post the Invoice
3. Create GSTR Report for the following month
4. Click on Generate Button traceback:
```py
Traceback (most recent call last):
File "/home/odoo/odoo/enterprise/l10n_in_reports_gstr/tests/test_gstr1_report.py", line 233, in test_gstr1_export_with_igst_zero
gstr1_json = gstr1_report._get_gstr1_json()
File "/home/odoo/odoo/enterprise/l10n_in_reports_gstr/models/gst_return_period.py", line 1114, in _get_gstr1_json
'exp': _get_exp_json(AccountMoveLine.search(self._get_section_domain('exp'))),
File "/home/odoo/odoo/enterprise/l10n_in_reports_gstr/models/gst_return_period.py", line 932, in _get_exp_json
for line_tax_details in tax_details.values():
AttributeError: 'NoneType' object has no attribute 'values'
```
After this commit-
We fix the above traceback and on further investigation it was found that `hsn`, `b2b` and `cdnr` were
missing `zero_rated` base tag in their domain
which we fix in this commit
task-4195917
Forward-Port-Of: odoo/enterprise#70279Steps to reproduce: ------- - install field service app - Go to the Field Service app and create a new task. - Assign a partner (customer) to the task. - Notice that the address of the assigned partner is not displayed immediately. - The address only appears after the record is saved. cause: -------- - context 'show_address' was not passed to _compute_display_name Technical: --------- In a previous [pull request](https://github.com/odoo/enterprise/pull/56179/commits/676e6c34a990
Original PR description
Steps to reproduce: ------- - install field service app - Go to the Field Service app and create a new task. - Assign a partner (customer) to the task. - Notice that the address of the assigned…
Steps to reproduce: ------- - install field service app - Go to the Field Service app and create a new task. - Assign a partner (customer) to the task. - Notice that the address of the assigned partner is not displayed immediately. - The address only appears after the record is saved. cause: -------- - context 'show_address' was not passed to _compute_display_name Technical: --------- In a previous [pull request](https://github.com/odoo/enterprise/pull/56179/commits/676e6c34a9901d4fe7f68859e1b526dfc2090413), the show_address context was removed. As a result, the _compute_display_name method was not able to correctly display the partner's address when a partner was assigned to a task.The address would only appear after the task was saved. Solution: The show_address context should be reintroduced and passed to the `_compute_display_name` method during the task creation or update process. This will allow the address to be displayed immediately when the partner is selected. task-4038335 Forward-Port-Of: odoo/enterprise#68198
**Steps to reproduce:** - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Usage: General expenses * CFDI to public: [checked] - Confirm the invoice - Generate CFDI and the invoice via "Send & Print" button **Issue:** On the invoice, "Usage" has an incorrect value: "S01 - General expenses" which is a mix of "S01 - Without fiscal effects" and "G03 - General expenses".
Original PR description
**Steps to reproduce:** - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Usage: General expenses * CFDI to public: [checked] - Confirm the invoice - Generate CFDI and the invoice via "Send & Print" button **Issue:** On the invoice, "Usage" has an incorrect value: "S01 - General expenses" which is a mix of "S01 - Without fiscal effects" and "G03 - General expenses". The description should be the one linked to the code. opw-4118647 Forward-Port-Of: odoo/enterprise#70274
Issue: ===== Changes of asset are not saved. Steps to reproduce the issue: ============================= - Create a new asset - Add some accounts in the accounting section - Confirm it - Click on modify depreciation - Select re-evaluate - Change the accounts and click modify - The changes are not applied Origin of the issue: ==================== We are not including the values of accounts in the `asset_vals` dict that we use to update the asset. Solution: ========= Added t
Original PR description
Issue: ===== Changes of asset are not saved. Steps to reproduce the issue: ============================= - Create a new asset - Add some accounts in the accounting section - Confirm it - Click on modify depreciation - Select re-evaluate - Change the accounts and click modify - The changes are not applied Origin of the issue: ==================== We are not including the values of accounts in the `asset_vals` dict that we use to update the asset. Solution: ========= Added the fields of the accounts to `asset_vals` dict. opw-4100185 Forward-Port-Of: odoo/enterprise#70172
For on premise instances, when the database expire and user renew its subscription, the update is not immediate; on the expiration panel there is a already a button to forcefully refresh the subscription status and unblock the database, but it's not really visible (its not clear that the 'refresh' icon right next to "Renew your subscription" / "Upgrade your subscription" buttons is just to refresh the subscription status and not to re-do that action again). This commit now shows the 'Refre
Original PR description
For on premise instances, when the database expire and user renew its subscription, the update is not immediate; on the expiration panel there is a already a button to forcefully refresh the…
For on premise instances, when the database expire and user renew its subscription, the update is not immediate; on the expiration panel there is a already a button to forcefully refresh the subscription status and unblock the database, but it's not really visible (its not clear that the 'refresh' icon right next to "Renew your subscription" / "Upgrade your subscription" buttons is just to refresh the subscription status and not to re-do that action again). This commit now shows the 'Refresh subscription status' action as a textual button to make it more visible to users. [opw-3942907](https://www.odoo.com/odoo/project.task/3942907) Note: the goal is to introduce a slight [wording change](https://github.com/odoo/enterprise/compare/16.0...odoo-dev:enterprise:16.0-opw-3942907-exp-panel-increase-sub-refresh-act-visibility-xal#diff-915475ae004db6256f7efc2757edfead13697a1581ee8c609251b1bafdcf9d06R24) (cf ticket) in 16.0 and later forward port, we're not doing it for 15.0 as the translation is still loaded in db Forward-Port-Of: odoo/enterprise#70324 Forward-Port-Of: odoo/enterprise#65768
The issue: When we have entries that are linked to a bank statement with a balance of 0, this will lead to a division by zero error when generating a reconciliation report The Fix: check for the suspense balance value, if it is zero, then there is no need to compute the rate since zero divided by anything = 0 opw-3990116 Forward-Port-Of: odoo/enterprise#68300 Forward-Port-Of: odoo/enterprise#65095
Original PR description
The issue: When we have entries that are linked to a bank statement with a balance of 0, this will lead to a division by zero error when generating a reconciliation report The Fix: check for the suspense balance value, if it is zero, then there is no need to compute the rate since zero divided by anything = 0 opw-3990116 Forward-Port-Of: odoo/enterprise#68300 Forward-Port-Of: odoo/enterprise#65095
payment_method_id is readonly in account.batch.payment's form view when there is at least one payment on the batch. So, it cannot easily be changed in standard in order to break the constraint. It could however happen in custom views or when generating records directly from the code. Forward-Port-Of: odoo/enterprise#70230
Original PR description
payment_method_id is readonly in account.batch.payment's form view when there is at least one payment on the batch. So, it cannot easily be changed in standard in order to break the constraint. It could however happen in custom views or when generating records directly from the code. Forward-Port-Of: odoo/enterprise#70230
options['journals'] contains a list of dictionaries. In the typical case, they each will correspond to a selectable account.journal. Though, they can also contain journal groups, and in multicompany, some of them may serve as dividers between companies (for ease of rendering in the template). Those latter elements will then have 'divider' under their 'id' key, instead of a model id. The Journal Report, when being opened for the first time unfolds the first available journal, by default, takin
Original PR description
options['journals'] contains a list of dictionaries. In the typical case, they each will correspond to a selectable account.journal. Though, they can also contain journal groups, and in multicompany,…
options['journals'] contains a list of dictionaries. In the typical case, they each will correspond to a selectable account.journal. Though, they can also contain journal groups, and in multicompany, some of them may serve as dividers between companies (for ease of rendering in the template). Those latter elements will then have 'divider' under their 'id' key, instead of a model id. The Journal Report, when being opened for the first time unfolds the first available journal, by default, taking therefore the first element from options['journals'], generating a report line id from it, and adding this id under the 'unfolded_lines' of the options in its _custom_options_initializer. The thing is, doing so, no check was done that the id being used was indeed an account.journal's. A journal group id or 'divider' could also be used. When 'divider' was added, the report crashed as soon as the options were used as previous_options in a subsequent call to get_options, since it tried to parse it as an integer. We fix that by properly filtering the available journal ids to only contain actual account.journal ids. Forward-Port-Of: odoo/enterprise#69876
Before this commit, it was not possible to resequence the projects in any list views of Project and Field Service because the `handle` widget is not defined in the sequence and the default order applied in those list views does not begin with `sequence` field. This commit shows the sequence field in the list view of `Field Service > Configuration > Projects` and change the default of that list view to allow the user to resequence the projects as he wishes. Community PR: odoo/odoo#180403
Original PR description
Before this commit, it was not possible to resequence the projects in any list views of Project and Field Service because the `handle` widget is not defined in the sequence and the default order applied in those list views does not begin with `sequence` field. This commit shows the sequence field in the list view of `Field Service > Configuration > Projects` and change the default of that list view to allow the user to resequence the projects as he wishes. Community PR: odoo/odoo#180403 Close odoo/odoo#176961 Forward-Port-Of: odoo/enterprise#70137
Remove "Create" and "Create and Edit" of Tax Grids in the list view of Journal Items. task: 4179612 Forward-Port-Of: odoo/enterprise#69864
Original PR description
Remove "Create" and "Create and Edit" of Tax Grids in the list view of Journal Items. task: 4179612 Forward-Port-Of: odoo/enterprise#69864
Problem: The `snailmail_cost` field was not being computed because the compute method was not being called. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#70236
Original PR description
Problem: The `snailmail_cost` field was not being computed because the compute method was not being called. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#70236
Reproduce Steps: ---------- 1. Install the Planning module. 2. Navigate to My Planning. 3. Open the Repeat Shift section. 4. Click the Delete button. 5. Click on a radio button label, such as 'This and Following Shifts'. Fixed an issue where clicking the shift option labels did not select the corresponding value. The problem was addressed by setting the `id` attribute on the input element and properly associating it with the label. task-3978567 Forward-Port-Of: odoo/enterprise#
Original PR description
Reproduce Steps: ---------- 1. Install the Planning module. 2. Navigate to My Planning. 3. Open the Repeat Shift section. 4. Click the Delete button. 5. Click on a radio button label, such as 'This and Following Shifts'. Fixed an issue where clicking the shift option labels did not select the corresponding value. The problem was addressed by setting the `id` attribute on the input element and properly associating it with the label. task-3978567 Forward-Port-Of: odoo/enterprise#70143 Forward-Port-Of: odoo/enterprise#68220
### Steps to reproduce issue: 1. Go to _Accounting > Configuration > Account Reports_ 2. Select Balance Sheet and Add a line in it 3. Select the new line and give it ASSETS as parent_id 4. Go to Reporting > Balance Sheet 5. The new line is still at the end of the report ### Explanation: Lines have a `sequence` to sort them in the report. It is not computed to change along with `parent_id`, since the lines are supposed to be arranged through the `AccountReportListRenderer` widget. Be
Original PR description
### Steps to reproduce issue: 1. Go to _Accounting > Configuration > Account Reports_ 2. Select Balance Sheet and Add a line in it 3. Select the new line and give it ASSETS as parent_id 4. Go to Reporting > Balance Sheet 5. The new line is still at the end of the report ### Explanation: Lines have a `sequence` to sort them in the report. It is not computed to change along with `parent_id`, since the lines are supposed to be arranged through the `AccountReportListRenderer` widget. Because of it a line whose `parent_id` changes will not be placed correctly. ### Fix reasoning: The `parent_id` field will be removed from the view, the hierarchy is already shown in the widget. opw-4101282 Forward-Port-Of: odoo/enterprise#69568
- 17.0 ### Steps to reproduce: - Install sale_planning and project_forecast app. - Create a sale order with the planning product (e.g. Developer (Plan services)) and confirm it. - Create planning for that sale order and set resource (e.g. Marc demo) to it. - Click 'Publish & Send' button. - Set 'User: Own Documents Only' rights for the sales and 'User' or 'none' for the project and planning for Marc demo. - Login from that user and open the planning app. - Open assigned planning form v
Original PR description
- 17.0 ### Steps to reproduce: - Install sale_planning and project_forecast app. - Create a sale order with the planning product (e.g. Developer (Plan services)) and confirm it. - Create planning for that sale order and set resource (e.g. Marc demo) to it. - Click 'Publish & Send' button. - Set 'User: Own Documents Only' rights for the sales and 'User' or 'none' for the project and planning for Marc demo. - Login from that user and open the planning app. - Open assigned planning form view. - Print planning. ### Issue: - Traceback occurs of access right. ### Cause: - While downloading the report, it goes to access the "display_name" and "name" field of sale order line and project respectively that is computed in the _compute_display_name, but the user cannot access "sale.order.line" and "project" due to record rule. ### Solution: - Give access to the record by using sudo(). task-3978552 Forward-Port-Of: odoo/enterprise#69533
Currently, an exception is generated when the user tries to upload an image file for creating an invoice. error: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: invalid start byte` This is because below code line tries to load image context of uploaded image file. https://github.com/odoo/enterprise/blob/799b80d12680153a5ba42ee97501723ba38052b1/l10n_ke_edi_oscu/models/account_move.py#L567 This commit fixes the above issue by handling `UnicodeDecodeError` in `con
Original PR description
Currently, an exception is generated when the user tries to upload an image file for creating an invoice. error: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: invalid start byte` This is because below code line tries to load image context of uploaded image file. https://github.com/odoo/enterprise/blob/799b80d12680153a5ba42ee97501723ba38052b1/l10n_ke_edi_oscu/models/account_move.py#L567 This commit fixes the above issue by handling `UnicodeDecodeError` in `contextlib.suppress.` sentry-5757745777 Forward-Port-Of: odoo/enterprise#69649