Friday, April 26, 2024
47 changes · saas-17.1
Resolved issues and error corrections
Clicking a manager or coach avatar on an employee record no longer triggers an error. This keeps employee profile navigation smooth and prevents users from being interrupted by a system traceback.
Original PR description
This traceback occurs when the user clicks on the employee avatar in the employee form view. <h4>To reproduce this issue:-</h4> 1) Install `Employees` 2) open any employee record 3) click on the…
This traceback occurs when the user clicks on the employee avatar in the employee form view. <h4>To reproduce this issue:-</h4> 1) Install `Employees` 2) open any employee record 3) click on the `avatar` of `manager` or `coach` 4) A traceback occurs Error:- ``` ValueError: Invalid field 'employee_ids' on model 'hr.employee ``` When the user clicks on the `employee avatar` in the `Employee` module a traceback occurs after `[1]`. Because the `employee_ids` field is not present in `hr.employee`. which leads to the above traceback when the `read ` method `[2]` triggers with the model as `hr.employee` and fields including `employee_ids` [1] https://github.com/odoo/odoo/pull/157907/commits/fdc0693968b5e50b625406a38e26817d6d9d63ea [2] https://github.com/odoo/odoo/blob/503e9cbf16762cfd753c4427e13228c135db21d5/addons/resource_mail/static/src/components/avatar_card_resource/avatar_card_resource_popover.js#L32-L33 This commit will resolve this issue based on the model in `props` to concat `employee_id` or `employee_ids` in the fields. Related Enterprise PR:- https://github.com/odoo/enterprise/pull/61444 sentry-3954475523
This fixes an issue where importing Peppol documents could fail for users on the Community edition because the system referenced an Enterprise-only field. The import now uses the appropriate shared setting, preventing errors and keeping the OCR-related action hidden when it should be.
Original PR description
The recent commit https://github.com/odoo/enterprise/commit/b12fc61af033f8914529d86a3edb464fc951f7dc changed the way a move is created during the import of a new peppol document. Before, we were passing a default value for `extract_can_show_send_button`, but now we try to set this field to `False` directly in create values. However, this field only exists in enterprise and thus things break if a user is only using community. Also, it's a computed readonly field, so it is better to use `is_in_extractable_state` for this purpose. no task, fixing the error highlighted by tests --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a customer from the Point of Sale no longer triggers an error when using the Argentinian localization. This keeps POS sessions running smoothly and avoids disruption during customer setup.
Original PR description
Steps to reproduce: 1. Install l10n_ar_pos. 2. Make sure we are in the Argentinian company. 3. Open PoS and create a new session. 4. When inside, try to create a new partner from here. The issue is that, since the changes where we retrieve the partner from the props, we might have cases where we don't have a partner since this field is defined as optional in our point_of_sale PartnerList, from we retrieve the props from. opw-3872968
This fix prevents an error from appearing when users click an employee avatar in the Planning app. It removes an enterprise-side change that is no longer needed because the related issue is handled in the core Odoo update, improving reliability without changing user workflows.
Original PR description
After the changes in the related community PR, Commit [2] is no longer needed as that use case in [2] will also resolved in the community PR mentioned below Community PR:- https://github.com/odoo/odoo/pull/163305 [2] https://github.com/odoo/enterprise/pull/58964/commits/7845ff85cad0714a95866f9bfcc9d717960ecf3c sentry-3954475523
The Soda import wizard now keeps its original guidance when the CodaBox integration is not installed. This avoids showing users a message meant only for companies using CodaBox, reducing confusion during Belgian accounting imports.
Original PR description
The soda import wizard message has been changed in commit https://github.com/odoo/enterprise/commit/6322a1850ec95948c517b6db5ecc9bff3e18f755\. The change in the message reflects a behavior change when the codabox module is installed. This message should stay unchanged when the codabox module is not installed.
Miscellaneous changes
The COA should be visible, so existing db won't crash. Indeed, it is used in the Selection field of the config settings. As the field does not exist, the users get an error. We instead don't let a user apply the Syscohada template to a company that does not already have the COA. opw-3893013 opw-3891587 opw-3891028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163350
Original PR description
The COA should be visible, so existing db won't crash. Indeed, it is used in the Selection field of the config settings. As the field does not exist, the users get an error. We instead don't let a user apply the Syscohada template to a company that does not already have the COA. opw-3893013 opw-3891587 opw-3891028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163350
Currently, when the `invoice_date` of an invoice is updated (triggering the recomputation of `date`) and if a system flush occurs before any line's date is accessed, the invoice lines' dates do not get updated. The following test illustrates this issue: ```py move = self.init_invoice( move_type='in_invoice', partner=self.partner_a, amounts=[1000.0], ) move.invoice_date = fields.Date.from_string('2024-01-01') self.env.flush_all() for line in move.line_ids: self.ass
Original PR description
Currently, when the `invoice_date` of an invoice is updated (triggering the recomputation of `date`) and if a system flush occurs before any line's date is accessed, the invoice lines' dates do not…
Currently, when the `invoice_date` of an invoice is updated (triggering the recomputation of `date`) and if a system flush occurs before any line's date is accessed, the invoice lines' dates do not get updated. The following test illustrates this issue:
```py
move = self.init_invoice(
move_type='in_invoice',
partner=self.partner_a,
amounts=[1000.0],
)
move.invoice_date = fields.Date.from_string('2024-01-01')
self.env.flush_all()
for line in move.line_ids:
self.assertEqual(line.date, move.date) # will fail
```
### Cause
The `date` of a move is a computed field dependent on the move's `invoice_date`. The `date` of a move line is a related field, pointing to its parent move's `date` (note: related fields are computed fields). During a flush, the system recomputes all fields that need to be. Here, the system first processes 'account.move.date' and calls its computation (`_compute_date`). However, the `_affect_tax_report()` call within `_compute_date` triggers a recalculation of `account.move.line.date`, but as this happens within `_compute_date`, the invoice lines' `date` is recalculated using the old invoice `date`.
### Fix
Force a recalculation of the invoice lines' dates whenever the invoice's date is changed.
opw-3759472
opw-3875405
opw-3872006
opw-3884013
Forward-Port-Of: odoo/odoo#163491
Forward-Port-Of: odoo/odoo#162956Add the basic package to the Rwanda localisation. -COA -Taxes -Default settings -Tax report -Fiscal position task-3627705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153501
Original PR description
Add the basic package to the Rwanda localisation. -COA -Taxes -Default settings -Tax report -Fiscal position task-3627705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153501
The issue: when you make a payment and there is an exchange difference, since the post exchange difference is not set, it will throw a traceback To reproduce: - Enable 2 currencies - Have the exchange difference journal set to NULL (empty) - Create an invoice with a different currency than the one set for the company - then register a payment. The fix: Throw a user error indicating to set the post exchange difference journal opw-3783917 opw-3768202 Forward-Port-Of: odoo/odoo#157
Original PR description
The issue: when you make a payment and there is an exchange difference, since the post exchange difference is not set, it will throw a traceback To reproduce: - Enable 2 currencies - Have the exchange difference journal set to NULL (empty) - Create an invoice with a different currency than the one set for the company - then register a payment. The fix: Throw a user error indicating to set the post exchange difference journal opw-3783917 opw-3768202 Forward-Port-Of: odoo/odoo#157735
Steps: ------ 1. Have accounting installed. 2. Have a bank journal with a currency different from company's currency, use a bank account with no currency set for this bank journal. 3. Make a misc operation in the bank account used by the journal. 4. On the dashboard, the "Misc. Operations" amount will not be converted to the journal's currency, even though the currency's symbol is correct, the amount is in the company's currency. Fix --- Do not show the total amount of misc operatio
Original PR description
Steps: ------ 1. Have accounting installed. 2. Have a bank journal with a currency different from company's currency, use a bank account with no currency set for this bank journal. 3. Make a misc operation in the bank account used by the journal. 4. On the dashboard, the "Misc. Operations" amount will not be converted to the journal's currency, even though the currency's symbol is correct, the amount is in the company's currency. Fix --- Do not show the total amount of misc operations if the bank journal and bank journal's bank account currencies are not matching. The user still knows there are journal entries not linked to a bank transaction thanks to the "misc operations" text, but we avoid doing a currency conversion that may not make sense. **opw-3767010** Forward-Port-Of: odoo/odoo#156655
Steps to reproduce: - Install eCommerce - Go to My account Issues: There is a box "Addresses" which is useless for the moment as it's the same page that can be accessed by clicking on "Edit information". The feature to have multiple addresses is going to be present in master at some point, however for now we're removing the box as it's useless. opw-3869920 Forward-Port-Of: odoo/odoo#162626
Original PR description
Steps to reproduce: - Install eCommerce - Go to My account Issues: There is a box "Addresses" which is useless for the moment as it's the same page that can be accessed by clicking on "Edit information". The feature to have multiple addresses is going to be present in master at some point, however for now we're removing the box as it's useless. opw-3869920 Forward-Port-Of: odoo/odoo#162626
**Issue**: On the Allocation form, Error when the `date_from` field is left blank. **Cause**: When deleting the `date_from` field, the onchange `_onchange_date_from` is triggered. It will call the `_process_accrual_plans` function and report an error as shown below: ``` first_level_start_date = allocation.date_from + get_timedelta(first_level.start_count, first_level.start_type) TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta' ``` **Solution**: - Check the `dat
Original PR description
**Issue**: On the Allocation form, Error when the `date_from` field is left blank. **Cause**: When deleting the `date_from` field, the onchange `_onchange_date_from` is triggered. It will call the `_process_accrual_plans` function and report an error as shown below: ``` first_level_start_date = allocation.date_from + get_timedelta(first_level.start_count, first_level.start_type) TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta' ``` **Solution**: - Check the `date_from` condition before calling next function - Handle it only in the onchange because the `date_from` field is required --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162730
Before this commit: Accidentally the test case in community inherited class from enterprise After this commit: We inherit the correct class which belongs to community --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163399
Original PR description
Before this commit: Accidentally the test case in community inherited class from enterprise After this commit: We inherit the correct class which belongs to community --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163399
Some options have been renammed a long time ago but there was no mechanism to warn the user should those option be still present in its configuration file. Odoo versions up to Odoo 14 (excluded) used `osv_memory_time_limit` and `geoip_database` in their configuration, those two options have been renamed to `transient_age_limit` and `geoip_city_db` in 14.0 ab4000f and saas-16.1 c59750d82440 but no deprecation warning / automatic failover were provided. Description of the issue/feature this
Original PR description
Some options have been renammed a long time ago but there was no mechanism to warn the user should those option be still present in its configuration file. Odoo versions up to Odoo 14 (excluded) used `osv_memory_time_limit` and `geoip_database` in their configuration, those two options have been renamed to `transient_age_limit` and `geoip_city_db` in 14.0 ab4000f and saas-16.1 c59750d82440 but no deprecation warning / automatic failover were provided. 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#163193
In order for preview images to be shown in the theme selection page, the `update_theme_images` needs to be called. This was done in a `post_init_hook`, which is called e.g. when installing `website`. This was also done in a `website` override of `ir.module.module.update_list()` which is called when updating a module interactively. Unfortunately, even though this override is defiend, at the time `update_list()` is called from `loading.py` when using `-u` on the command line, the modules are n
Original PR description
In order for preview images to be shown in the theme selection page, the `update_theme_images` needs to be called. This was done in a `post_init_hook`, which is called e.g. when installing `website`.…
In order for preview images to be shown in the theme selection page, the `update_theme_images` needs to be called. This was done in a `post_init_hook`, which is called e.g. when installing `website`. This was also done in a `website` override of `ir.module.module.update_list()` which is called when updating a module interactively. Unfortunately, even though this override is defiend, at the time `update_list()` is called from `loading.py` when using `-u` on the command line, the modules are not loaded yet, and therefore the override is not applied. Because of this, when a database was upgraded between versions that introduce new themes or new screenshots for themes, `update_theme_images` was not called during the upgrade, and the new images were missing in the upgraded database. This commit solves this by calling `update_theme_images` from a `function` data record, so that it is run both on install and on update of `website`. Steps to reproduce: - Install website and a theme in 14.0. - Upgrade to 15.0. - Access the theme selection page. => Images were missing for some themes. task-2719425 Forward-Port-Of: odoo/odoo#163118 Forward-Port-Of: odoo/odoo#160452
If an order was validated in PoS but encountered a sync error, the order would revert to a draft state and no receipt would be printed. However, if an order was validated in PoS without internet, the receipt could still be printed. When the internet connection was restored, the system would attempt to validate the unsynced order. If a server error occurred during this process, the system would try to revert the order to a draft state and fail. This behavior is not ideal as an order with a printe
Original PR description
If an order was validated in PoS but encountered a sync error, the order would revert to a draft state and no receipt would be printed. However, if an order was validated in PoS without internet, the receipt could still be printed. When the internet connection was restored, the system would attempt to validate the unsynced order. If a server error occurred during this process, the system would try to revert the order to a draft state and fail. This behavior is not ideal as an order with a printed receipt should not be modified or changed. This commit ensures that in the event of a sync failure, the saved orders do not revert to a draft state. opw-3858994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161250
*: website_mass_mailing Before this commit, when a "Form" snippet was added and the action was changed to "Subscribe to Newsletter", the mailing lists appeared as checkbox fields with the number of subscribers in parentheses. This commit removes the display of this unnecessary information. Steps to reproduce: - Install the "Email Marketing" module and Website. - Navigate to the Website in edit mode. - Drag & drop the "Form" block (dynamic content section). - Change the form action
Original PR description
*: website_mass_mailing Before this commit, when a "Form" snippet was added and the action was changed to "Subscribe to Newsletter", the mailing lists appeared as checkbox fields with the number of subscribers in parentheses. This commit removes the display of this unnecessary information. Steps to reproduce: - Install the "Email Marketing" module and Website. - Navigate to the Website in edit mode. - Drag & drop the "Form" block (dynamic content section). - Change the form action by setting the "Action" option to "Subscribe to Newsletter". Bug: The number of subscribers appears next to the mailing list names. task-3472820 Co-authored-by: Adrien Milis <miad@odoo.com> Forward-Port-Of: odoo/odoo#163336 Forward-Port-Of: odoo/odoo#160509
Steps to reproduce: [account_edi_ubl_cii] - create an invoice and set a line with on the control character https://unicode-explorer.com/b/0000 - confirm it - try to print it Issue: Ugly Stack Trace Cause: XML does not accept such characters ``` The characters to be escaped are the control characters #x0 to #x1F and #x7F (most of which cannot appear in XML) [...] XML processors must accept any character in the range specified for Char: `Char ::= #x9 |
Original PR description
Steps to reproduce:
[account_edi_ubl_cii]
- create an invoice and set a line with on the control character https://unicode-explorer.com/b/0000
- confirm it
- try to print it
Issue:
Ugly Stack Trace
Cause:
XML does not accept such characters
```
The characters to be escaped are the control characters #x0 to #x1F and #x7F (most of which cannot appear in XML)
[...] XML processors must accept any character in the range specified for Char:
`Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]`
source:https://www.w3.org/TR/xml/
```
opw-3773808
Forward-Port-Of: odoo/odoo#157568Description of the issue/feature this PR addresses: Spain localization l10n_es_edi_tbai module, sudo on company when creating TicketBAI chain sequence for the first time to avoid raise of access security errors without Administration/Settings. Current behavior before PR: When creating the first invoice, TicketBAI chain sequence does not exists therefore it is created, if user does not belong to Administration/Settings group, an access error is raised and invoice is not posted. In the sa
Original PR description
Description of the issue/feature this PR addresses: Spain localization l10n_es_edi_tbai module, sudo on company when creating TicketBAI chain sequence for the first time to avoid raise of access…
Description of the issue/feature this PR addresses: Spain localization l10n_es_edi_tbai module, sudo on company when creating TicketBAI chain sequence for the first time to avoid raise of access security errors without Administration/Settings. Current behavior before PR: When creating the first invoice, TicketBAI chain sequence does not exists therefore it is created, if user does not belong to Administration/Settings group, an access error is raised and invoice is not posted. In the same time, a write operation is done in the company to set the value of the sequence on l10n_es_tbai_chain_sequence_id field, and writing in a company only is allowed for users that belongs to Administration/Settings. Desired behavior after PR is merged: We make a sudo in self (res.company) with a user with account permission but not Administration/Settings, no errors are raised, invoice is posted and TicketBAI XML file is created and posted to the agency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162433
Since 3eb96806022705f5b667e149ffa2240760097278, the signature of method `_notify_by_email_prepare_rendering_context` has been changed to provide a default values to `msg_vals` and some overrides were not adapted (or have been added afterwards). No true bug/issue has been found caused by that discrepancy, but for consistency, this commit makes sure those overrides are adapted to provide the same API as the parent method. Fixes #162742 --- I confirm I have signed the CLA and read the P
Original PR description
Since 3eb96806022705f5b667e149ffa2240760097278, the signature of method `_notify_by_email_prepare_rendering_context` has been changed to provide a default values to `msg_vals` and some overrides were not adapted (or have been added afterwards). No true bug/issue has been found caused by that discrepancy, but for consistency, this commit makes sure those overrides are adapted to provide the same API as the parent method. Fixes #162742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163334
Currently, an error is generated when removing all product quantities from the cart after a claiming a reward(discount). Step to produce: - Install a 'website_sale_loyalty' module. - Navigate to the website / eCommerce / Loyalty / Discount & Loyalty to create a record. - Set the Loyalty Program name and Program Type as 'Loyalty Cards'.(Ensure it's available on sale and the website.) - And add 'Rewards' and set a Reward Type as 'Discount' which is applied to on Cheapest Product. - Go
Original PR description
Currently, an error is generated when removing all product quantities from the cart after a claiming a reward(discount). Step to produce: - Install a 'website_sale_loyalty' module. - Navigate to the…
Currently, an error is generated when removing all product quantities from the cart after a claiming a reward(discount).
Step to produce:
- Install a 'website_sale_loyalty' module.
- Navigate to the website / eCommerce / Loyalty / Discount & Loyalty to create a record.
- Set the Loyalty Program name and Program Type as 'Loyalty Cards'.(Ensure it's available on sale and the website.)
- And add 'Rewards' and set a Reward Type as 'Discount' which is applied to on Cheapest Product.
- Go to the website shop add any product on a card, Open a cart increase the quantity of the product, and claim the discount reward.
- Again go to Loyalty Program and open Loyalty Card, Open a record and add a Balance(greater than 200 as default reward points are 200) and copy 'Code'.
- Again go to the website shop and apply this code to claim a discount after a claim discount.
- Now remove all product quantity from a cart.
See Traceback:
```
AttributeError: 'bool' object has no attribute 'price_unit'
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, 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 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/website_sale_loyalty/controllers/main.py", line 126, in cart_update_json
return super().cart_update_json(*args, set_qty=set_qty, **kwargs)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/website_sale/controllers/main.py", line 817, in cart_update_json
values = order._cart_update(
File "addons/website_sale_loyalty/models/sale_order.py", line 174, in _cart_update
self._update_programs_and_rewards()
File "addons/website_sale_loyalty/models/sale_order.py", line 60, in _update_programs_and_rewards
return super()._update_programs_and_rewards()
File "addons/sale_loyalty/models/sale_order.py", line 802, in _update_programs_and_rewards
values_list = self._get_reward_line_values(reward, coupon, product=reward_key[3])
File "addons/sale_loyalty_delivery/models/sale_order.py", line 64, in _get_reward_line_values
return super()._get_reward_line_values(reward, coupon, **kwargs)
File "addons/sale_loyalty/models/sale_order.py", line 573, in _get_reward_line_values
return self._get_reward_values_discount(reward, coupon, **kwargs)
File "addons/sale_loyalty/models/sale_order.py", line 321, in _get_reward_values_discount
discountable, discountable_per_tax = self._discountable_cheapest(reward)
File "addons/sale_loyalty/models/sale_order.py", line 211, in _discountable_cheapest
discountable = cheapest_line.price_unit * (1 - (cheapest_line.discount or 0) / 100)
```
The issue occurs when attempting to remove all product quantities from a cart. At this point [1], a bool value 'False' is returned, and the system attempts to get a value of 'price_unit' from it [2].
link [1]: https://github.com/odoo/odoo/blob/499056a82db26f7d9caa86314e666e2bd49cc79c/addons/sale_loyalty/models/sale_order.py#L187-L195
link [2]: https://github.com/odoo/odoo/blob/499056a82db26f7d9caa86314e666e2bd49cc79c/addons/sale_loyalty/models/sale_order.py#L205
This commit resolves the issue, If the _cheapest_line() method returns False then also returns False from _discountable_cheapest(), To raise an error at [3].
link [3]: https://github.com/odoo/odoo/blob/cbc40eccf576c499709f7825edad9a3b3ce7a22d/addons/sale_loyalty/models/sale_order.py#L317-L333
sentry-5119007021
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#163055Steps to reproduce: - Install e-Commerce - Go to your portal into a quotation - Go to the chatter and send an empty message Issues: A traceback is shown Solution: Catch the error and discard it as the parent method is already displaying the error message to the user. opw-3877096 Forward-Port-Of: odoo/odoo#162424
Original PR description
Steps to reproduce: - Install e-Commerce - Go to your portal into a quotation - Go to the chatter and send an empty message Issues: A traceback is shown Solution: Catch the error and discard it as the parent method is already displaying the error message to the user. opw-3877096 Forward-Port-Of: odoo/odoo#162424
## Reported issue ### Steps to reproduce: Be sure that 'industry_fsm' is installed. - Go to Project > Projects and swap to the list view - Create and save a new project with a customer - Access the related SO via the smart button - Add a service product, a storable product a section and a note - Go back and access the project status with the smart button #### > The SOL generated for the section and the note appear as SO items ### Expected behavior: The purpose of the project
Original PR description
## Reported issue ### Steps to reproduce: Be sure that 'industry_fsm' is installed. - Go to Project > Projects and swap to the list view - Create and save a new project with a customer - Access the…
## Reported issue ### Steps to reproduce: Be sure that 'industry_fsm' is installed. - Go to Project > Projects and swap to the list view - Create and save a new project with a customer - Access the related SO via the smart button - Add a service product, a storable product a section and a note - Go back and access the project status with the smart button #### > The SOL generated for the section and the note appear as SO items ### Expected behavior: The purpose of the project status tab is to have an overview at the project to help in the analyse its profitability, the time investment,... as such, these SOL should not be considered as SO items. In addition, these lines lose their entire purpose in the list view used in this overview (they can not be moved and display irrelevant infos). ### Cause of the issue: These lines were not filtered out by the current query. ## Second Issue: ### Steps to reproduce: Install only the "project" and "sale_management" module and reproduce the same flow as above. #### > Only the service product is displayed as a SO items. ### Cause of the issue: Since the onchange method: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/sale_project/models/sale_order.py#L124-L128 is triggered before an analytic account is linked to the project, the sale order created in our flow will not be linked to an `analytic_account_id`. In particular, as this value is null in the DB and is not computed it can not be relied on here: https://github.com/odoo/odoo/blob/7f5f2963966f5a3bcfeb4bede0f9d956fff6e831/addons/sale_project/models/project.py#L341 to define the SQL query fetching our SOL. ##### Note: If the `industry_fsm` module is installed, the second issue do not happen because an analytic account is linked to the project before the trigger of the onchange method. In particular, since the behavior of this flow is different with additional modules installed we added both a test "at install" and a test "post install". opw-3794386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157984
Recent commit [1] made a typo when converting templates [1]: https://github.com/odoo/odoo/commit/02461534d2b74410bcdfb5cccaac8157fe806127 Forward-Port-Of: odoo/odoo#162757
Original PR description
Recent commit [1] made a typo when converting templates [1]: https://github.com/odoo/odoo/commit/02461534d2b74410bcdfb5cccaac8157fe806127 Forward-Port-Of: odoo/odoo#162757
Steps to reproduce: - create an empty spreadsheet - type in a cell '=ODOO.BALANCE("qsdfqsf", "02/2024")' => #ERROR There's no account that match the given code. The account.move.line domain ends up having a clause `('account_id', 'in', [])` The ORM detects the domain won't match anything and early returns an empty list [] Our code expects a query object and not a list => boom --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of
Original PR description
Steps to reproduce:
- create an empty spreadsheet
- type in a cell '=ODOO.BALANCE("qsdfqsf", "02/2024")' => #ERROR
There's no account that match the given code.
The account.move.line domain ends up having a clause `('account_id', 'in', [])`
The ORM detects the domain won't match anything and early returns an empty list []
Our code expects a query object and not a list => boom
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#163165*: web, web_editor Follow-up of [1] (see its own explanation for details). This is about fixing the remaining code. In the future, we will probably go even further: - No more wrapwrap element at all - No support of a main scroll which is not left up to the browser (see some more details about that in [2] which explains the many problems which occurred when the scroll was on the wrapwrap element). Those final points have yet to be confirmed though. All in all, this PR should no
Original PR description
*: web, web_editor Follow-up of [1] (see its own explanation for details). This is about fixing the remaining code. In the future, we will probably go even further: - No more wrapwrap element at all - No support of a main scroll which is not left up to the browser (see some more details about that in [2] which explains the many problems which occurred when the scroll was on the wrapwrap element). Those final points have yet to be confirmed though. All in all, this PR should not change any behavior in the standard stable versions. But it will fix bugs in some custo trying to change the page scrolling behavior, while unifying the versions codebases. [1]: https://github.com/odoo/odoo/commit/ffc19547c8da2ef7fee8e2ac743ab99a607dcf90 [2]: https://github.com/odoo/odoo/pull/98429 Forward-Port-Of: odoo/odoo#163393 Forward-Port-Of: odoo/odoo#159748
The test_sudo_commands fails when testing portal user without demo data. With this commit, a portal user is created in a setupClass. build-error: 55927 Forward-Port-Of: odoo/odoo#163116
Original PR description
The test_sudo_commands fails when testing portal user without demo data. With this commit, a portal user is created in a setupClass. build-error: 55927 Forward-Port-Of: odoo/odoo#163116
The spec for electronic invoices in Colombia was updated and is now known as Anexo 1.9. This was done in the related enterprise PR (module l10n_co_edi). This commit introduces some changes in the base module that are needed for the Anexo 1.9 update. task-3639271 ### related PRs FW-port of https://github.com/odoo/odoo/pull/148953 (15.0) https://github.com/odoo/odoo/pull/151407 (16.0) https://github.com/odoo/odoo/pull/151418 (saas-16.3) https://github.com/odoo/odoo/pull/151431 (17.0)
Original PR description
The spec for electronic invoices in Colombia was updated and is now known as Anexo 1.9. This was done in the related enterprise PR (module l10n_co_edi). This commit introduces some changes in the base module that are needed for the Anexo 1.9 update. task-3639271 ### related PRs FW-port of https://github.com/odoo/odoo/pull/148953 (15.0) https://github.com/odoo/odoo/pull/151407 (16.0) https://github.com/odoo/odoo/pull/151418 (saas-16.3) https://github.com/odoo/odoo/pull/151431 (17.0)
In line[1], ``self`` is referenced to ``_get_default_mail_attachments_widget``, and using ``self`` instead of ``wizard`` doesn't make sense because ``self`` could potentially hold multiple values. This becomes problematic when the ``ensure_one`` method is called. Due to this below error is raised Traceback : ``` ValueError: too many values to unpack (expected 1) File "odoo/models.py", line 5848, in ensure_one _id, = self._ids ValueError: Expected singleton: account.move.send(168, 1
Original PR description
In line[1], ``self`` is referenced to ``_get_default_mail_attachments_widget``, and using ``self`` instead of ``wizard`` doesn't make sense because ``self`` could potentially hold multiple values.…
In line[1], ``self`` is referenced to ``_get_default_mail_attachments_widget``, and using ``self`` instead of ``wizard`` doesn't make sense because ``self`` could potentially hold multiple values. This becomes problematic when the ``ensure_one`` method is called. Due to this below error is raised
Traceback :
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5848, in ensure_one
_id, = self._ids
ValueError: Expected singleton: account.move.send(168, 167)
File "addons/payment/models/payment_transaction.py", line 985, in _cron_finalize_post_processing
tx._finalize_post_processing()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 144, in _finalize_post_processing
super()._finalize_post_processing()
File "addons/account_payment/models/payment_transaction.py", line 217, in _finalize_post_processing
super()._finalize_post_processing()
File "addons/payment/models/payment_transaction.py", line 1001, in _finalize_post_processing
self.filtered(lambda tx: tx.operation != 'validation')._reconcile_after_done()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 87, in _reconcile_after_done
self._post_subscription_action()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 166, in _post_subscription_action
orders._send_success_mail(tx.invoice_ids, tx)
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/sale_order.py", line 1866, in _send_success_mail
linked_invoices.with_context(email_context)._generate_pdf_and_send_invoice(template)
File "addons/account/models/account_move.py", line 4841, in _generate_pdf_and_send_invoice
return composer.action_send_and_print(force_synchronous=force_synchronous, allow_fallback_pdf=allow_fallback_pdf, bypass_download=bypass_download)
File "addons/account/wizard/account_move_send.py", line 738, in action_send_and_print
return self._process_send_and_print(
File "addons/account/wizard/account_move_send.py", line 663, in _process_send_and_print
moves_data = {
File "addons/account/wizard/account_move_send.py", line 666, in <dictcomp>
**self._get_mail_move_values(move, wizard),
File "addons/account/wizard/account_move_send.py", line 170, in _get_mail_move_values
'mail_attachments_widget': wizard and wizard.mail_attachments_widget or self._get_default_mail_attachments_widget(move, mail_template),
File "odoo/fields.py", line 1206, in __get__
self.recompute(record)
File "odoo/fields.py", line 1421, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1394, in apply_except_missing
func(records)
File "odoo/fields.py", line 1443, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4931, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 100, in determine
return needle(*args)
File "addons/account_edi_ubl_cii/wizard/account_move_send.py", line 68, in _compute_mail_attachments_widget
super()._compute_mail_attachments_widget()
File "addons/account/wizard/account_move_send.py", line 311, in _compute_mail_attachments_widget
self._get_default_mail_attachments_widget(wizard.move_ids, wizard.mail_template_id)
File "addons/account/wizard/account_move_send.py", line 138, in _get_default_mail_attachments_widget
return self._get_placeholder_mail_attachments_data(move) \
File "addons/account_edi_ubl_cii/wizard/account_move_send.py", line 112, in _get_placeholder_mail_attachments_data
if self.mode == 'invoice_single' and self._needs_ubl_cii_placeholder():
File "odoo/fields.py", line 1202, in __get__
record.ensure_one()
File "odoo/models.py", line 5851, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
[1] : https://github.com/odoo/odoo/blob/167dedab5c7423097689c6a7d0d6ee6dd904a8bf/addons/account/wizard/account_move_send.py#L311-L312
sentry - 5234450902
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#162829Steps to reproduce: ------------------- - create a product tag (eCommerce / Product Tags); - go to a product page and open editor; - edit the page adding a "Products" block; - add the created product tag; - remove it and save; Issue: ------ No products are displayed, whereas without tags, a default product set should be displayed. Cause: ------ At first, when we don't have a tag, the domain determined for the search is `[]`, which returns a list of products. When we add the t
Original PR description
Steps to reproduce: ------------------- - create a product tag (eCommerce / Product Tags); - go to a product page and open editor; - edit the page adding a "Products" block; - add the created product…
Steps to reproduce: ------------------- - create a product tag (eCommerce / Product Tags); - go to a product page and open editor; - edit the page adding a "Products" block; - add the created product tag; - remove it and save; Issue: ------ No products are displayed, whereas without tags, a default product set should be displayed. Cause: ------ At first, when we don't have a tag, the domain determined for the search is `[]`, which returns a list of products. When we add the tag, a domain will be built with the products linked to this tag: `['all_product_tag_ids, 'in', []]` (in the case of the use case above, there will be none). The attribute `data-product-tag-ids="[]"` is added to the dynamic snippet section. Then, when we remove it, we will get the same domain: because the string `"[]"` is valid for the condition that checks whether `productTagIds` exists. As a result, it will no longer be possible to obtain the default set for this block. Solution: --------- Try to reduce the domain to a list in all cases and compare its length. If it is empty, the domain must be an empty domain. opw-3859482 Forward-Port-Of: odoo/odoo#161818
We are removing the ``completeness`` field from the order because it's a non-storable field. When we attempt to access this field, it triggers a logger warning check at line [1]. This commit will help you to implement a ``goals`` search by domain and order by ``ID`` and sorting by ``completeness`` and ``current`` value, with condition-based sorting for 'higher' or 'lower' requirements check at line[2]. [1] : https://github.com/odoo/odoo/pull/127353/commits/12e9749bcc1dc4f7b1a129933
Original PR description
We are removing the ``completeness`` field from the order because it's a non-storable field. When we attempt to access this field, it triggers a logger warning check at line [1]. This commit will help you to implement a ``goals`` search by domain and order by ``ID`` and sorting by ``completeness`` and ``current`` value, with condition-based sorting for 'higher' or 'lower' requirements check at line[2]. [1] : https://github.com/odoo/odoo/pull/127353/commits/12e9749bcc1dc4f7b1a129933ae16840195bcae8#diff-7144f88ea32f36feb17ce1b8dda7dee1631f5ada34075414587df3948c6b3d1bL5317 [2] : https://github.com/odoo/odoo/blob/5c5b4d991423e0282d06a98e5677977d53dc0817/addons/gamification/models/gamification_challenge.py#L545-L548 sentry - 5162134321 Forward-Port-Of: odoo/odoo#161270
Case 1: The user can cancel the document directly from the SAT. In that case, in odoo, the user needs to "Request Cancel" first even if the SAT state becomes 'cancelled'. To improve that, this case is now managed by adding a new cancel document automatically on the invoice. Case 2: The user can request a cancellation from the SAT. Currently, the invoice is marked as "cancel" even if the SAT rejects the cancellation. In order to manage that, let's introduce a new document: 'invoice_can
Original PR description
Case 1: The user can cancel the document directly from the SAT. In that case, in odoo, the user needs to "Request Cancel" first even if the SAT state becomes 'cancelled'. To improve that, this case is now managed by adding a new cancel document automatically on the invoice. Case 2: The user can request a cancellation from the SAT. Currently, the invoice is marked as "cancel" even if the SAT rejects the cancellation. In order to manage that, let's introduce a new document: 'invoice_cancel_requested'. Forward-Port-Of: odoo/enterprise#60905
To make correspondences between accounting entries and attachments, we need a new file and guid for the entries. Documentation can be found at https://developer.datev.de/datev/platform/en/node/6344 task-3888995 Forward-Port-Of: odoo/enterprise#61481 Forward-Port-Of: odoo/enterprise#61378
Original PR description
To make correspondences between accounting entries and attachments, we need a new file and guid for the entries. Documentation can be found at https://developer.datev.de/datev/platform/en/node/6344 task-3888995 Forward-Port-Of: odoo/enterprise#61481 Forward-Port-Of: odoo/enterprise#61378
This commit adds the financial reports of Rwanda and make sure they are balanced. task: 3627705 Forward-Port-Of: odoo/enterprise#57099
Original PR description
This commit adds the financial reports of Rwanda and make sure they are balanced. task: 3627705 Forward-Port-Of: odoo/enterprise#57099
In [1] we added a domain on appointment actions to prevent a traceback when users visit the gantt appointment views when resources from different companies appear at the same time. However appointment_resource_id was deprecated in favor of appointment_resource_ids in stable since then. `appointment_resource_ids` should now be used in the domain. [1] ab7addece528d887f062e70732f96fde2ed76dca task-3893256 Forward-Port-Of: odoo/enterprise#61439
Original PR description
In [1] we added a domain on appointment actions to prevent a traceback when users visit the gantt appointment views when resources from different companies appear at the same time. However appointment_resource_id was deprecated in favor of appointment_resource_ids in stable since then. `appointment_resource_ids` should now be used in the domain. [1] ab7addece528d887f062e70732f96fde2ed76dca task-3893256 Forward-Port-Of: odoo/enterprise#61439
To reproduce: ============= - create an employee having night shift from 21:30 to 06:00 configured as 21:30 -> 24:00 and 00:30 -> 06:00 (break of 30 minutes) - in planning create a role for this employee - create an open shift for that role from 21:30 to 06:00 - click auto plan -> shift is not assigned to the employee Problem: ======== when computing the rate of allocated hours for this shift we find out that it exceeds 100%, because the hour 24:00 is represented as 23:59:59.999999 w
Original PR description
To reproduce: ============= - create an employee having night shift from 21:30 to 06:00 configured as 21:30 -> 24:00 and 00:30 -> 06:00 (break of 30 minutes) - in planning create a role for this employee - create an open shift for that role from 21:30 to 06:00 - click auto plan -> shift is not assigned to the employee Problem: ======== when computing the rate of allocated hours for this shift we find out that it exceeds 100%, because the hour 24:00 is represented as 23:59:59.999999 which creates rounding issues. Solution: ========= round the allocated rate opw-3874283 Forward-Port-Of: odoo/enterprise#61438
### Issue: Tours from `tour_shopfloor.js` fail in "No demo" databases. ### Explanation: This is due to the setting `group_mrp_routings` being disabled. When it is enabled, a pop-up appears when entering Shop Floor and the tours take it into account since the setting is enabled with Demo Data. When it is disabled, the pop-up does not appear, and the tests fail at the first step because of it. https://github.com/odoo/enterprise/blob/4b34efc77b57562e4c92956c63c8c20e6de53bf0/mrp_workorde
Original PR description
### Issue: Tours from `tour_shopfloor.js` fail in "No demo" databases. ### Explanation: This is due to the setting `group_mrp_routings` being disabled. When it is enabled, a pop-up appears when…
### Issue: Tours from `tour_shopfloor.js` fail in "No demo" databases. ### Explanation: This is due to the setting `group_mrp_routings` being disabled. When it is enabled, a pop-up appears when entering Shop Floor and the tours take it into account since the setting is enabled with Demo Data. When it is disabled, the pop-up does not appear, and the tests fail at the first step because of it. https://github.com/odoo/enterprise/blob/4b34efc77b57562e4c92956c63c8c20e6de53bf0/mrp_workorder/static/src/mrp_display/mrp_display.js#L107 https://github.com/odoo/enterprise/blob/4b34efc77b57562e4c92956c63c8c20e6de53bf0/mrp_workorder/static/src/mrp_display/mrp_display.js#L114-L119 ### Fix: Due to both tests failing for the same reason, the setting will automatically be enabled in `setUpClass`. `test_shop_floor` also needs an employee named 'Marc Demo', adding the creation of the employee for "No demo" databases. https://github.com/odoo/enterprise/blob/74e0f4fec69d6512e213312bf42f3d743f7a27b3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L28-L31 error-60565 error-58036 Forward-Port-Of: odoo/enterprise#60868
The commit https://github.com/odoo/enterprise/commit/cf61f05e78e40f03f4d1d4ba2692b8b5426759cc forgot to change the name of the module that needs to be installed to make the feature work correctly for the ICP part. Forward-Port-Of: odoo/enterprise#61470
Original PR description
The commit https://github.com/odoo/enterprise/commit/cf61f05e78e40f03f4d1d4ba2692b8b5426759cc forgot to change the name of the module that needs to be installed to make the feature work correctly for the ICP part. Forward-Port-Of: odoo/enterprise#61470
We make this module uninstallable until the certification is done. This commit will be reverted later. Forward-Port-Of: odoo/enterprise#50109
Original PR description
We make this module uninstallable until the certification is done. This commit will be reverted later. Forward-Port-Of: odoo/enterprise#50109
The way the chart templates refs work had changed in 16.2, but this test was never adapted (it never ran before as the needed environment variables were not set on runbot... They are now and this raises an error). Forward-Port-Of: odoo/enterprise#61385
Original PR description
The way the chart templates refs work had changed in 16.2, but this test was never adapted (it never ran before as the needed environment variables were not set on runbot... They are now and this raises an error). Forward-Port-Of: odoo/enterprise#61385
Bug === Create in this order - 1 normal document - 1 link document - 1 normal document Select the first and second documents, the link button is not visible. Select the second and third documents, the link button is visible and shouldn't be. Similarly, the share button should be visible if at least one document is not archived, and not if the first document is not active. Task-3874111 Forward-Port-Of: odoo/enterprise#61400 Forward-Port-Of: odoo/enterprise#61118
Original PR description
Bug === Create in this order - 1 normal document - 1 link document - 1 normal document Select the first and second documents, the link button is not visible. Select the second and third documents, the link button is visible and shouldn't be. Similarly, the share button should be visible if at least one document is not archived, and not if the first document is not active. Task-3874111 Forward-Port-Of: odoo/enterprise#61400 Forward-Port-Of: odoo/enterprise#61118
"here" = "aquí" in Spanish Forward-Port-Of: odoo/enterprise#61474
Original PR description
"here" = "aquí" in Spanish Forward-Port-Of: odoo/enterprise#61474
This should have been done using a bridge module to allow uninstalling SMS but hey. Runbot-27909 Forward-Port-Of: odoo/enterprise#61462
Original PR description
This should have been done using a bridge module to allow uninstalling SMS but hey. Runbot-27909 Forward-Port-Of: odoo/enterprise#61462
### [FIX] l10n_co_edi: add a test for the vendor document Previously there was no test for the vendor document. This commit adds a (simple) test.c In the next commit of the same PR the code for the vendor document had to be adapted while keeping the result the same. This test helps in making sure nothing went wrong. The reason was that the electronic invoice and vendor document share some common code / logic but the shared parts had to be changed for an update to the electronic invoice
Original PR description
### [FIX] l10n_co_edi: add a test for the vendor document Previously there was no test for the vendor document. This commit adds a (simple) test.c In the next commit of the same PR the code for the…
### [FIX] l10n_co_edi: add a test for the vendor document Previously there was no test for the vendor document. This commit adds a (simple) test.c In the next commit of the same PR the code for the vendor document had to be adapted while keeping the result the same. This test helps in making sure nothing went wrong. The reason was that the electronic invoice and vendor document share some common code / logic but the shared parts had to be changed for an update to the electronic invoice spec (Anexo 1.9). (See the next commit for details) ### [FIX] l10n_co_edi: update for anexo 1.9 The spec for electronic invoices in Colombia was updated and is now known as Anexo 1.9. This commit updates the electronic invoice to meet the new spec A bit part of the new spec is the conversion of many fields from document to company currency / COP. There is also a vendor document. But it follows a different spec. Thus some shared logic / section with the electronic invoice was updated so that the vendor document remains unchanged. The following sections were removed since they are obsolete and also (basically) dead code: * OVT section: dead code * FE1 section: content is dead code Previously when creating a credit note from an invoice with the reversal wizard (account.move.reversal) there was the following bug. The Credit Note Concept (l10n_co_edi_description_code_credit on account.move) was set after posting. This was corrected in this commit (since a validation on post was added to check that the concept is there). ### task task-3639271 ### related PRs forward-port of https://github.com/odoo/enterprise/pull/54086 (15.0) https://github.com/odoo/enterprise/pull/55268 (16.0) https://github.com/odoo/enterprise/pull/55274 (saas-16.3) https://github.com/odoo/enterprise/pull/55279 (17.0)
### Steps to reproduce 1. Activate "l10n_account_customer_statements" 3. Register payment for a large amount of invoices (6+) to the same customer 4. Tick the Group Payments box 5. Go to the customer's contact 6. Action / Print Customer Statements You should see that most of the information is outside the page ### Cause The whole table has the `text-nowrap` class. opw-3820027 Before: ![Screenshot from 2024-04-15 20-44-47](https://github.com/odoo/enterprise/assets/1731605
Original PR description
### Steps to reproduce 1. Activate "l10n_account_customer_statements" 3. Register payment for a large amount of invoices (6+) to the same customer 4. Tick the Group Payments box 5. Go to the customer's contact 6. Action / Print Customer Statements You should see that most of the information is outside the page ### Cause The whole table has the `text-nowrap` class. opw-3820027 Before:  After:  Forward-Port-Of: odoo/enterprise#60808
Purpose ======= Prevent the horizontal scrolling of the inspector but allow the vertical scrolling for small screen sizes. Specifications ============== Reverting the addition of the "overflow-hidden" class on the documents inspector as it is preventing its horizontal but also its vertical scrolling. On lower screen sizes, a vertical scrolling is needed or else the inspector becomes pratically unusable. related PR: odoo/enterprise#59652 Task-3884149 Forward-Port-Of: odoo/enterprise
Original PR description
Purpose ======= Prevent the horizontal scrolling of the inspector but allow the vertical scrolling for small screen sizes. Specifications ============== Reverting the addition of the "overflow-hidden" class on the documents inspector as it is preventing its horizontal but also its vertical scrolling. On lower screen sizes, a vertical scrolling is needed or else the inspector becomes pratically unusable. related PR: odoo/enterprise#59652 Task-3884149 Forward-Port-Of: odoo/enterprise#61399 Forward-Port-Of: odoo/enterprise#61220
_compute_l10n_br_is_service_transaction() was added as part of account.external.tax.mixin. It's supposed to be implemented for both account.move and sale.order. The sale.order override is part of l10n_br_edi_sale_services, which is only installed if EDI is installed. This causes issues with the "l10n single modules" runbot tests. When l10n_br_test_avatax_sale is tested it installs l10n_br_avatax and sale. l10n_br_avatax_services is auto-installed because of l10n_br_avatax. Because there's no
Original PR description
_compute_l10n_br_is_service_transaction() was added as part of account.external.tax.mixin. It's supposed to be implemented for both account.move and sale.order. The sale.order override is part of l10n_br_edi_sale_services, which is only installed if EDI is installed. This causes issues with the "l10n single modules" runbot tests. When l10n_br_test_avatax_sale is tested it installs l10n_br_avatax and sale. l10n_br_avatax_services is auto-installed because of l10n_br_avatax. Because there's no sale.order override various tests will fail with NotImplementedError() [1]. Ideally there should have been a l10n_br_avatax_sale_services module that contained just this one override. In absence of that, we make the function set False to stop breaking the tests. Users who just want tax computation on services will need to install the EDI part manually. [1] https://runbot.odoo.com/runbot/build/61615058 Forward-Port-Of: odoo/enterprise#61277