Daily updates from Odoo
Thursday, January 30, 2020
29 changes · master
Enhancements to existing features
Avatar images shown on kanban cards now appear round instead of square. This provides a cleaner, more consistent visual presentation for users browsing records in kanban views.
Original PR description
Change the style of avatar images in kanban cards to make them round. Task 2179548
Resolved issues and error corrections
This fix makes web templates easier and more consistent to inherit when their names include a module prefix. It reduces configuration mistakes for developers and helps prevent template-related issues in the web interface, with a related fix avoiding a naming conflict in the upload progress display.
Original PR description
A good practice is to always prefix the name of a template by the name of the module it is defined in. So in the case where a template ```xml <t t-name="module.template" /> ``` was inherited by another Before this commit, one should have written ```xml <t t-name="other" t-inherit="module.module.template" /> ``` After this commit, it becomes more natural, and one should only write ```xml <t t-name="other" t-inherit="module.template"/>
Fixed an error that could prevent users from unbuilding a manufacturing order. This helps manufacturing teams complete reverse production actions without encountering a system traceback.
Original PR description
We get a traceback when we try to unbuild a MO due to a inexistant field call (scrap_qty) instead of product_qty -> 8458cc18674b267e64f95aa311a210ed5be41c51. Fix the issue.
The Documents app now respects the intended delay before opening the inspector on mobile. This prevents the inspector from appearing too quickly and keeps the mobile browsing experience consistent with recent interface changes.
Original PR description
Following the change of the inspector rendering in #7911, the mobile inspector wasn't taking the delay into account. This commit fixes this issue.
Fixes a template formatting issue that could cause Website CRM scoring pages to fail when loading. This helps keep affected sales and marketing views accessible after a recent translation-related change.
Original PR description
Task : https://www.odoo.com/web#id=2182586&action=333&active_id=965&model=project.task&view_type=form&menu_id=4720
This update removes an outdated validation in asset accounting after a field change, preventing unnecessary checks from running. It also corrects how asset-related balances are read so calculations use the right filtering and ordering, reducing the risk of incorrect asset accounting behavior.
Original PR description
The field asset_id has been changed to asset_ids in 66c53e43eddc6a6e0511c9f5700f3d5ab191a7d9 The check done in _check_original_move_line_ids is no longer needed. Also, the resolve_2many_commands we trying to access cumulated_balance without the order and domain set in the domain, which was problematic.
Code cleanup and technical improvements
This update refines an internal test for Gantt view access rights by avoiding duplicate demo user setup. It helps keep the test suite simpler and more reliable without changing business features or user workflows.
Original PR description
rev[0] introduced a test on the auto acl on gantt view and used the TransactionCaseWithUserDemo class. With this class, there's already a demo user present. [0] 3839e122d9e2ebf1faa848b01e1631e6c6f7d809
Miscellaneous changes
The access right on payment_token is based on the partner_id linked with the user If there is token link with the public user, they are shown for every request were the partner_id is not defined If you are logged with an internal user with sales access right, you'll see all the payment_token linked with the acquirer We should avoid both situation and show only the payment_token from the legit partner_id the one of the current user or the one given as parameter -- I confirm I have
Original PR description
The access right on payment_token is based on the partner_id linked with the user If there is token link with the public user, they are shown for every request were the partner_id is not defined If you are logged with an internal user with sales access right, you'll see all the payment_token linked with the acquirer We should avoid both situation and show only the payment_token from the legit partner_id the one of the current user or the one given as parameter -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44319
Before this commit, when clicking on a channel mention from a chat window, it crashed with the following error: `TypeError: channel.detach is not a function` This happens due to `MailService.joinChannel()` returning a promise that is resolved with channel ID, instead of a channel object. `channel.detach()` becomes `<Number>.detach()`, which is treated like `undefined()`, hence crash. Forward-Port-Of: odoo/odoo#44293 Forward-Port-Of: odoo/odoo#44228
Original PR description
Before this commit, when clicking on a channel mention from a chat window, it crashed with the following error: `TypeError: channel.detach is not a function` This happens due to `MailService.joinChannel()` returning a promise that is resolved with channel ID, instead of a channel object. `channel.detach()` becomes `<Number>.detach()`, which is treated like `undefined()`, hence crash. Forward-Port-Of: odoo/odoo#44293 Forward-Port-Of: odoo/odoo#44228
…s value. Description of the issue/feature this PR addresses: Current behavior before PR: It was raising the singleton error when updating multiple category records. Desired behavior after PR is merged: It will fix the singleton error. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44244
Original PR description
…s value. Description of the issue/feature this PR addresses: Current behavior before PR: It was raising the singleton error when updating multiple category records. Desired behavior after PR is merged: It will fix the singleton error. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44244
Before this commit, when typing something in the search view in Japanese, and then clicking on a suggestion from the IME dropdown menu, the search view menu did not update with selection. Steps to reproduce: - Enable Japanese IME in hiragana mode; - Type "test" in search view; - Soft-select another suggestion item, e.g. "テスト"; - Double-click on suggestion item "test"; => The search view menu still detects "テスト". As a result, clicking on any of these search view suggested filters
Original PR description
Before this commit, when typing something in the search view in Japanese, and then clicking on a suggestion from the IME dropdown menu, the search view menu did not update with selection. Steps to reproduce: - Enable Japanese IME in hiragana mode; - Type "test" in search view; - Soft-select another suggestion item, e.g. "テスト"; - Double-click on suggestion item "test"; => The search view menu still detects "テスト". As a result, clicking on any of these search view suggested filters picks "テスト" instead of "test". This commit fixes the issue by updating search menu when clicking in a suggestion in the IME menu. opw-2061590 Forward-Port-Of: odoo/odoo#44224 Forward-Port-Of: odoo/odoo#43723
Description of the issue/feature this PR addresses: The pagination of the events list is incorrectly aligned with the layout. Plus, if you deactivate the sidebar, the pager is inlined with the events. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42195
Original PR description
Description of the issue/feature this PR addresses: The pagination of the events list is incorrectly aligned with the layout. Plus, if you deactivate the sidebar, the pager is inlined with the events. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42195
-github issue: 14673 -task: 2007300 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44288 Forward-Port-Of: odoo/odoo#40847
Original PR description
-github issue: 14673 -task: 2007300 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44288 Forward-Port-Of: odoo/odoo#40847
The issue is: the user wants to send an invoice to a customer, changes the email template, and after the onchange, the field "Template" of the wizard is empty. Here is what happens. The onchange on the template renders a PDF file with the corresponding invoice document. The rendering builds some assets to convert the invoice to a PDF document, and former assets are deleted. The deletion of former assets (`ir.attachment` records) invalidates the whole record cache, which implicitly cl
Original PR description
The issue is: the user wants to send an invoice to a customer, changes the email template, and after the onchange, the field "Template" of the wizard is empty. Here is what happens. The onchange on…
The issue is: the user wants to send an invoice to a customer, changes the email template, and after the onchange, the field "Template" of the wizard is empty. Here is what happens. The onchange on the template renders a PDF file with the corresponding invoice document. The rendering builds some assets to convert the invoice to a PDF document, and former assets are deleted. The deletion of former assets (`ir.attachment` records) invalidates the whole record cache, which implicitly clears all the fields of the record of the onchange. The problem is that the asset is systematically invalidated by the rendering of the report itself. This hack changes the CSS assets to introduce company-specific colors for the rendering of reports. This implementation is actually not consistent with the fact that assets are kept in cache by the server. This patch does not fix the root cause of the problem, but it reduces the sides effects of it, and makes the issue above less frequent. It simply consists in not updating the asset's attachment when its value is already correct. OPW 2168623 OPW 2171040 Forward-Port-Of: odoo/odoo#44225
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#44165 Forward-Port-Of: odoo/odoo#43878
Original PR description
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#44165 Forward-Port-Of: odoo/odoo#43878
Steps to reproduce the problem: - Have user A with B2B group. - Have user B with B2C group. - Add simultaneously on both - via write - another group (or call `_check_one_user_type`). Expected result: - No problem Got result: - Error "A user cannot have both Tax B2B and Tax B2C..." That's because the check is performed for more than one user each time, while it has to be record per record. The implementation of `_has_multiple_groups` actually checks if the passed recordset is
Original PR description
Steps to reproduce the problem: - Have user A with B2B group. - Have user B with B2C group. - Add simultaneously on both - via write - another group (or call `_check_one_user_type`). Expected result: - No problem Got result: - Error "A user cannot have both Tax B2B and Tax B2C..." That's because the check is performed for more than one user each time, while it has to be record per record. The implementation of `_has_multiple_groups` actually checks if the passed recordset is only one record, and if not, it looks directly for all existing users, so also the case of both users A and B being in the same B2x group, but having a 3rd user in the other group will fail. Revisiting the query in `_has_multiple_groups`, there's a hidden error when you use it for only one ID because a missing space. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr cc @Tecnativa TT20968 Forward-Port-Of: odoo/odoo#43964
- Activate the VIES online check - Create a partner of type Company and add several contacts - Set the VAT number, save A call to VIES is done for each contact. The field VAT is propagated from the parent company to the children, triggering the check on all partners. This is not problematic for local checks since those are fast. However, online checks take time which can lead to a timeout of the request if there are many contacts. Since the check is triggered through a constraint (
Original PR description
- Activate the VIES online check - Create a partner of type Company and add several contacts - Set the VAT number, save A call to VIES is done for each contact. The field VAT is propagated from the…
- Activate the VIES online check - Create a partner of type Company and add several contacts - Set the VAT number, save A call to VIES is done for each contact. The field VAT is propagated from the parent company to the children, triggering the check on all partners. This is not problematic for local checks since those are fast. However, online checks take time which can lead to a timeout of the request if there are many contacts. Since the check is triggered through a constraint (`check_vat`), only one record at a time is checked. Therefore, it is not possible to build a local list of the VAT numbers to avoid duplicated verifications inside a single transaction. The solution is to store the result in cache. Since the call to the external API may fail (e.g. timeout), we extract the check to store only the successful calls. opw-2181744 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#44260 Forward-Port-Of: odoo/odoo#44160
opw-2122776 * CompAuxNum should be the code of the account concatenated with the id of the client * It should be popuated only if it is a receivable/payable The problem is the export of the partner ID in the column G "CompAuxNum". We only export the ID of the linked customer/vendor. When they import the FEC into their software to make tax declarations and annual accounts. The system will notice if an account is filled in in the column G and will override the account in column E with th
Original PR description
opw-2122776 * CompAuxNum should be the code of the account concatenated with the id of the client * It should be popuated only if it is a receivable/payable The problem is the export of the partner ID in the column G "CompAuxNum". We only export the ID of the linked customer/vendor. When they import the FEC into their software to make tax declarations and annual accounts. The system will notice if an account is filled in in the column G and will override the account in column E with the ID of the partner. As the ID is not a real account, they cannot use the FEC to import correctly. 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#43985
Forward-Port-Of: odoo/odoo#44264
Original PR description
Forward-Port-Of: odoo/odoo#44264
### Issue - Contacts - Import a contact that will be a portal user - Test import Activation email sent ### Cause Testing an import do the whole process (including sending an email) ### Solution Check if we are testing the import with a new context key import_dryrun. **OPW-2168868** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44211 Forward-Port-Of: odoo/odoo#43724
Original PR description
### Issue
- Contacts
- Import a contact that will be a portal user
- Test import
Activation email sent
### Cause
Testing an import do the whole process (including sending an email)
### Solution
Check if we are testing the import with a new context key
import_dryrun.
**OPW-2168868**
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#44211
Forward-Port-Of: odoo/odoo#43724Steps to reproduce: - install sales and contact - install another language - go to contacts, pick a specific contact and set its language to the new language installed - go to sales > settings > activate the "product configurator" option - create a product with a translated variant (the variant has to have at least 2 translated attributes with custom values) - create a quotation with the modified contact and the product with the variant (use the product configurator wizard) > save - pr
Original PR description
Steps to reproduce: - install sales and contact - install another language - go to contacts, pick a specific contact and set its language to the new language installed - go to sales > settings > activate the "product configurator" option - create a product with a translated variant (the variant has to have at least 2 translated attributes with custom values) - create a quotation with the modified contact and the product with the variant (use the product configurator wizard) > save - print that quotation Previous behavior: product description is not fully translated the part describing the variants is in the current user's language while the product display_name is using the associated partner's language Current behavior: product description is fully translated into the correct language opw-2168102 Forward-Port-Of: odoo/odoo#43846
Now, we can again creates ingenico token on production environment. Commit https://github.com/odoo/odoo/commit/f0e059e6#diff-0c487d0R558 replaced aquirer.id by self.acquire_id.id. It is wrong since env['payment.token'].create() will call the function with self == payment.token(). self.acquirer_id == False --> self.acquirer_id.state != 'enabled' --> request done in test mode each time. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior aft
Original PR description
Now, we can again creates ingenico token on production environment. Commit https://github.com/odoo/odoo/commit/f0e059e6#diff-0c487d0R558 replaced aquirer.id by self.acquire_id.id. It is wrong since env['payment.token'].create() will call the function with self == payment.token(). self.acquirer_id == False --> self.acquirer_id.state != 'enabled' --> request done in test mode each time. 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#43963
Description of the issue/feature this PR addresses: Fixes #44133 Current behavior before PR: Before this commit, the Bank account on the new Bill created from the PO was not set due to missing methods to set those fields. Desired behavior after PR is merged: This commits adds missing methods to set Bank account. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44136
Original PR description
Description of the issue/feature this PR addresses: Fixes #44133 Current behavior before PR: Before this commit, the Bank account on the new Bill created from the PO was not set due to missing methods to set those fields. Desired behavior after PR is merged: This commits adds missing methods to set Bank account. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44136
Before this commit, if you call get_alias_info with an id of group that you cannot read, it raises a traceback. It was not a problem previously since we don't handle traceback from rpc call, but now in v13 we toast it. Now, we handle the exception error in JS (cannot change controller instable) and don't toast exception. How to reproduce the bug: Drop a snippet Discussion Group Select a channel (public only are shown) Save page Edit the channel in backend and make it pri
Original PR description
Before this commit, if you call get_alias_info with an id of group that you cannot read,
it raises a traceback. It was not a problem previously since we don't handle traceback
from rpc call, but now in v13 we toast it.
Now, we handle the exception error in JS (cannot change controller instable) and don't
toast exception.
How to reproduce the bug:
Drop a snippet Discussion Group
Select a channel (public only are shown)
Save page
Edit the channel in backend and make it private
Refresh
-> a toast with an access error on the mail channel.
task-pad-feedback
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#43858Description 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#44212
Original PR description
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#44212
- Create and validate a leave - Go to Time Off > Everyone - In the Gantt view, move the leave Nothing prevents the modification of the leave while is it validated. opw-2179839 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#44194 Forward-Port-Of: odoo/odoo#44096
Original PR description
- Create and validate a leave - Go to Time Off > Everyone - In the Gantt view, move the leave Nothing prevents the modification of the leave while is it validated. opw-2179839 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#44194 Forward-Port-Of: odoo/odoo#44096
As this race condition seems not possible to be reproduced in local, all this is an assumption based on the logs. After the checkout, the user is redirected to `/shop/confirmation` where there is RPCs fired ever seconds to fetch the payment status (`/shop/payment/get_status`). As the test was considered as finished on that page, sometimes the RPC would still be processed in python while the tour was considered done and killed, thus also the cookies, session & co. From that point, the
Original PR description
As this race condition seems not possible to be reproduced in local, all this is an assumption based on the logs. After the checkout, the user is redirected to `/shop/confirmation` where there is RPCs fired ever seconds to fetch the payment status (`/shop/payment/get_status`). As the test was considered as finished on that page, sometimes the RPC would still be processed in python while the tour was considered done and killed, thus also the cookies, session & co. From that point, the python would crash when accessing the session. In the logs, the python crash in the RPC call occurs after the test is done. Forward-Port-Of: odoo/odoo#44222 Forward-Port-Of: odoo/odoo#44113
A payment always has a currency, which can differ from its journal's currency. We should never put the journal currency into the dictionary passed to SEPA functions. Forward-Port-Of: odoo/enterprise#8026
Original PR description
A payment always has a currency, which can differ from its journal's currency. We should never put the journal currency into the dictionary passed to SEPA functions. Forward-Port-Of: odoo/enterprise#8026
In case an invoice is having multiple tax lines, we are not correctly computing the tax balance sum. This issue was introduced with commit 3079ed1fbe1c483bfc9da6d6da4b46805b06d493. opw-2179640 Forward-Port-Of: odoo/enterprise#8020
Original PR description
In case an invoice is having multiple tax lines, we are not correctly computing the tax balance sum. This issue was introduced with commit 3079ed1fbe1c483bfc9da6d6da4b46805b06d493. opw-2179640 Forward-Port-Of: odoo/enterprise#8020