Tuesday, April 6, 2021
25 changes · master
Enhancements to existing features
The pull request updates the repository ownership rules so logistics-related code changes are automatically routed to the right team for review. This helps ensure relevant experts are involved earlier, improving review accountability without changing product behavior.
This change makes internal calculation ordering predictable so repeated CRM installations produce consistent database query counts. That consistency helps teams compare performance results more reliably and investigate remaining sources of variation.
Original PR description
[IMP] core: make compute order deterministic CRM install query count can vary from one execution to another, leading to difficulties when analysing performances evolution. The main reason for this is that some compute methods were called in different order. Even if compute order shouldn't have any effect on the final result, making it well defined will help finding other causes of non-determinism. The initial observation was that sorting Environment.fields_to_compute leads to a fixed number of query when installing crm. The main cause of non-determinisim is the usage of `set` impacting Field.compute_value and BaseModel._modified_triggers. Transforming all these `set` to `OrderedSet` solves the problem. The query count is now deterministic when installing a database from scratch, but not when updating a database with -i crm. OrderedSet is also slightly optimised by using a dict instead of an OrderedDict: dict order is deterministic since python3.6
This draft pull request adds test coverage for employee-related behavior in the HR module. It also includes a contributor license agreement file, helping ensure the contribution can be reviewed under project guidelines.
Original PR description
Description of the issue/feature this PR addresses: Together with my team we are investigating the software architecture of your system. To better understand the code base I'm trying to add a new test case to hr_employee Current behavior before PR: Some methods in hr_employee aren't covered by test. Desired behavior after PR is merged: Better test coverage. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The project screens now only show the analytic account option when analytic accounting or timesheets are actually configured. This reduces confusion for users by hiding an accounting-related field when it cannot be used or updated.
Original PR description
Currently, In project module -> configuration -> Project list view column "analytic account" is suggested as a hidden column when the accounting app or timesheet app are not configured. At the same time, the analytic account field is not shown in the project from view and cannot be updated. In this commit, I have made the "analytic account" field a hidden column only when the analytic accounting or timesheet app is configured. And the same applies to the project form view also. Task ID: 2451722
Resolved issues and error corrections
This fix prevents the website editor from showing an error when the text selection is unexpectedly unavailable. It improves editing stability for users while a more complete cleanup fix is planned separately.
Original PR description
Note : This should be fix properly by calling destroy on the editor. So this is more of a quick and dirty fix, in before the detroy fix.(see [this task](https://www.odoo.com/web#id=2468804&action=333&active_id=1695&model=project.task&view_type=form&cids=1&menu_id=4720) for the destroy fix ) Odoo task : https://www.odoo.com/web#id=2497783&action=333&active_id=1695&model=project.task&view_type=form&cids=1&menu_id=4720 Bug report from LNA : > Stack of tracebacks Secret traceback level? https://youtu.be/EZ9-M6aAdlU https://pastebin.com/PSvQB5WS To replicate: https://youtu.be/Om4mh5I9k5g -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
- On accounting settings, activate 'Cash Basis'; - Select a 'Base Tax Received Account'; - Modify a purchase taxes, and set the 'Tax Due' to 'Based on Payment'; - Set a 'Cash Basis Transition Account'; - Be sure that the previously selected account allows reconciliation; - Create a Vendors Bills, using the modified purchase tax; - Register a payment; - Reset to draft the vendors bill. Before this commit, an error was raised : 'Record does not exist or has been deleted.' This occurs
Original PR description
- On accounting settings, activate 'Cash Basis'; - Select a 'Base Tax Received Account'; - Modify a purchase taxes, and set the 'Tax Due' to 'Based on Payment'; - Set a 'Cash Basis Transition Account'; - Be sure that the previously selected account allows reconciliation; - Create a Vendors Bills, using the modified purchase tax; - Register a payment; - Reset to draft the vendors bill. Before this commit, an error was raised : 'Record does not exist or has been deleted.' This occurs because when trying to unlink the partial reconcile, it will first reverse and unlink the tax cash basis partial reconcile moves. After when trying to access the partial reconcile to unlink the error is raised because one is already unlink. Now, the vendors bill is correctly reset to draft. opw-2477526 Forward-Port-Of: odoo/odoo#68333
The website editor now shows a default icon for the media alignment toolbar button when editing content. This prevents a missing-icon visual glitch and makes the editor controls clearer for users.
Original PR description
Odoo task : https://www.odoo.com/web#id=2497783&action=333&active_id=1695&model=project.task&view_type=form&cids=1&menu_id=4720 bug report from LNA: > Missing icon? https://tinyurl.com/yzbmffx3 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
That method iterates over move lines: https://github.com/odoo/odoo/blob/7623a0c771495cd41bf40af37c0d2b6e4beb7cdc/addons/stock_account/models/account_move.py#L16-L18 So, we have O(n^2) complexity at least. It leads to timeout error on invoices with few hundres products. After this commit it takes 70 seconds to confirm an invoice with 450 lines: 23527 11.038 56.530 (Number of queries / Query time, sec / Remaining time, sec) --- https://github.com/odoo/odoo/commit/9e1aec7873a935b2
Original PR description
That method iterates over move lines: https://github.com/odoo/odoo/blob/7623a0c771495cd41bf40af37c0d2b6e4beb7cdc/addons/stock_account/models/account_move.py#L16-L18 So, we have O(n^2) complexity at least. It leads to timeout error on invoices with few hundres products. After this commit it takes 70 seconds to confirm an invoice with 450 lines: 23527 11.038 56.530 (Number of queries / Query time, sec / Remaining time, sec) --- https://github.com/odoo/odoo/commit/9e1aec7873a935b287b4b3c5dbc2688acee5422a opw-2488458 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#68763 Forward-Port-Of: odoo/odoo#68354
When using "Generate Missing Terms" we export all translations and reimport them with `create_empty_translation` so they empty translation are made available. But since we export all modules in the same PO file, the same terms that might have different translation in different modules would get the same translation value after using "Generate missing terms" which is unexpected => usually we import/export PO file by module and so a term translation is unique for one module only. With this chang
Original PR description
When using "Generate Missing Terms" we export all translations and reimport them with `create_empty_translation` so they empty translation are made available. But since we export all modules in the same PO file, the same terms that might have different translation in different modules would get the same translation value after using "Generate missing terms" which is unexpected => usually we import/export PO file by module and so a term translation is unique for one module only. With this changeset, we import translation module by module. When testing speed of Generate Missing Terms with 90 modules and 37000 translations, the timing taken change like this: - original code: 21 seconds - exporting/importing 1 PO file per module: 45 seconds - exporting 1 TGZ file total/importing 1 PO file per module: 23 seconds opw-2439029 Forward-Port-Of: odoo/odoo#68663 Forward-Port-Of: odoo/odoo#68306
Demo data is not usually updated. It was also deleting the demo data when doing a `-i account` when the module was already installed (or actually the chart of accounts instantiated) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#66598
Original PR description
Demo data is not usually updated. It was also deleting the demo data when doing a `-i account` when the module was already installed (or actually the chart of accounts instantiated) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#66598
Steps to reproduce the bug : - Go to accounting > Configuration > Reconciliation Models - Create a new reconciliation model - Select the “Match existing invoices/bills” type - In the field “Match Invoice/bill with” choose “Label” - Add a new partner mapping > encode in "Find text in label" an erroneous regex like “*test” > choose any partner - Go to accounting Dashboard > click on “Bank” - Create a new Bank statement> add new transaction without selecting “Partner” - Post the created b
Original PR description
Steps to reproduce the bug : - Go to accounting > Configuration > Reconciliation Models - Create a new reconciliation model - Select the “Match existing invoices/bills” type - In the field “Match Invoice/bill with” choose “Label” - Add a new partner mapping > encode in "Find text in label" an erroneous regex like “*test” > choose any partner - Go to accounting Dashboard > click on “Bank” - Create a new Bank statement> add new transaction without selecting “Partner” - Post the created bank statements > Reconcile it Problem : An error is triggered because the regex is wrong. opw-2473973 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#68683
Description of the issue/feature this PR addresses: When printing a check from a payment the check number wizard shows the number 1 for the next check... it should show the last check added one +1, it doesn't because it doesn't exclude the account.payments without checknumber. This fix excludes the account.payments without checknumber so that it doesn't shows "1" as the next check number when there are multiple new checks to be printed -- I confirm I have signed the CLA and read the PR
Original PR description
Description of the issue/feature this PR addresses: When printing a check from a payment the check number wizard shows the number 1 for the next check... it should show the last check added one +1, it doesn't because it doesn't exclude the account.payments without checknumber. This fix excludes the account.payments without checknumber so that it doesn't shows "1" as the next check number when there are multiple new checks to be printed -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#68123
Steps to reproduce the bug: - Let's create two partners P1 and P2 where P1 is a company and P2 a child of P1 - P2 is a portal user - Log with P2 and go to the shop - Add a product in the cart and process to checkout - The billing address details of P2 are auto completed, click on next - For the shipping address, the details of P1 are auto completed, click on next Bug: A 403 page was displayed with: You cannot create recursive Partner hierarchies. opw:2487590 Forward-Port-Of: od
Original PR description
Steps to reproduce the bug: - Let's create two partners P1 and P2 where P1 is a company and P2 a child of P1 - P2 is a portal user - Log with P2 and go to the shop - Add a product in the cart and process to checkout - The billing address details of P2 are auto completed, click on next - For the shipping address, the details of P1 are auto completed, click on next Bug: A 403 page was displayed with: You cannot create recursive Partner hierarchies. opw:2487590 Forward-Port-Of: odoo/odoo#68237
Steps: - Install l10n_ar, website_sale - Go to Website / Configuration / eCommerce / Payment Acquirers - Install PayUlatam - Edit PayUlatam: - Argentinian credentials: http://developers.payulatam.com/en/web_checkout/sandbox.html - Go to Website / Configuration / Settings - Check Multi-Currencies - Save - Click Currencies - Edit all currencies: - Rates: - Edit or create the current rate: - Rate: 1.000000 - Go to Website / Products / Pricelists - Create an ARS pricelis
Original PR description
Steps: - Install l10n_ar, website_sale - Go to Website / Configuration / eCommerce / Payment Acquirers - Install PayUlatam - Edit PayUlatam: - Argentinian credentials:…
Steps:
- Install l10n_ar, website_sale
- Go to Website / Configuration / eCommerce / Payment Acquirers
- Install PayUlatam
- Edit PayUlatam:
- Argentinian credentials: http://developers.payulatam.com/en/web_checkout/sandbox.html
- Go to Website / Configuration / Settings
- Check Multi-Currencies
- Save
- Click Currencies
- Edit all currencies:
- Rates:
- Edit or create the current rate:
- Rate: 1.000000
- Go to Website / Products / Pricelists
- Create an ARS pricelist and make it selectable
- Go to Website / Products / Products
- Create a product (1):
- Sales Price: 15.75
- No taxes
- Click "Published On Website"
- Select your new ARS pricelist
- Add (1) to Cart
- Process Checkout
- Select PayUlatam
- Pay Now
- Use this info to process the checkout: http://developers.payulatam.com/en/web_checkout/sandbox.html
- Pagar (Pay)
- Regresar al sitio de la tienda (Back to the store website)
Bug:
500: PayUlatam: invalid sign
Explanation:
From PayU's documentation:
> 2. Response page
> Signature validation
> In order to get the new value new_value you always should approximate
> the TX_VALUE to a decimal, using the rounding method "Round half to
> even"
http://developers.payulatam.com/en/web_checkout/integration.html
opw:2457240
Forward-Port-Of: odoo/odoo#68757
Forward-Port-Of: odoo/odoo#68593Steps to reproduce the bug: - Let's consider an employee E and two partners P1, P2 - P1 is the private address of E and P2 is the partner linked to the user of E - Let's consider two vehicles V1, V2 - The driver of V1 is P1 and the driver of V2 is P2 - Change the mobility card of E Bug: The mobility card of V1 was not updated but the mobility card of V2 was updated. The number of cars computed by _compute_employee_cars_count was doubled. opw:24313
Original PR description
Steps to reproduce the bug:
- Let's consider an employee E and two partners P1, P2
- P1 is the private address of E and P2 is the partner linked to the user of E
- Let's consider two vehicles V1, V2
- The driver of V1 is P1 and the driver of V2 is P2
- Change the mobility card of E
Bug:
The mobility card of V1 was not updated but the mobility card of V2 was updated.
The number of cars computed by _compute_employee_cars_count was doubled.
opw:2431316
Forward-Port-Of: odoo/odoo#68300Before, depending on the screen size, it was not always clear for the user that he can use the search bar to find library images. The upload buttons and search bars have been switched in order to make the search the first choice for the user. Also, make the arrow pointing at the searchbar more understandable. task-2446852 Forward-Port-Of: odoo/odoo#68806
Original PR description
Before, depending on the screen size, it was not always clear for the user that he can use the search bar to find library images. The upload buttons and search bars have been switched in order to make the search the first choice for the user. Also, make the arrow pointing at the searchbar more understandable. task-2446852 Forward-Port-Of: odoo/odoo#68806
Previously on v12, every tax was added in an account.invoice.tax line, being clear about the amount of each one.  Now on v13, that table has dissappeared, and the tax summary at the footer is grouped by tax group, resulting in a mix of all taxes with the same percentage. This is not usually a problem, as the same percentage taxes are not included at the same time in the sam
Original PR description
Previously on v12, every tax was added in an account.invoice.tax line, being clear about the amount of each one.…
Previously on v12, every tax was added in an account.invoice.tax line, being clear about the amount of each one.  Now on v13, that table has dissappeared, and the tax summary at the footer is grouped by tax group, resulting in a mix of all taxes with the same percentage. This is not usually a problem, as the same percentage taxes are not included at the same time in the same invoice, except an exception: non deductible VAT. For this case, we can have several lines with the same percentage as deductible or non deductible, and all being mixed in the footer.  For avoiding the problem, we create a new tax group, and use it for non deductible VAT taxes. We can consider to add 3 groups, one per percentage of non deductible VAT, but it's an overhead that doesn't add too much value (the 95% percent of the non deductible is 21%), and even if having several of them in the same invoice, to see the total amount grouped as "IVA no deducible" is not a big deal. @Tecnativa TT29009 Forward-Port-Of: odoo/odoo#68662
**Description of the issue/feature this PR addresses:** - Fix: Create again the removed account group "Otros créditos" - Imp: move account groups data to a CSV template 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#68621
Original PR description
**Description of the issue/feature this PR addresses:** - Fix: Create again the removed account group "Otros créditos" - Imp: move account groups data to a CSV template 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#68621
Beforehand, tax exigibility was not systematically recomputed upon move creation. Now, as soon as an account move line is created on a move, tax exigibility is recomputed. 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#68703
Original PR description
Beforehand, tax exigibility was not systematically recomputed upon move creation. Now, as soon as an account move line is created on a move, tax exigibility is recomputed. 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#68703
This should hopefully fix the race condition that is described in the related task. The issue is that our mounted callbacks are legitimately relying on the component to be actually rendered. task-2481713 --- Example of original issue: https://runbot.odoo.com/runbot/build/6647176 Proof of `recursiveCallMounted` being called with `status === 1` https://runbot.odoo.com/runbot/build/7007672 Forward-Port-Of: odoo/odoo#68711
Original PR description
This should hopefully fix the race condition that is described in the related task. The issue is that our mounted callbacks are legitimately relying on the component to be actually rendered. task-2481713 --- Example of original issue: https://runbot.odoo.com/runbot/build/6647176 Proof of `recursiveCallMounted` being called with `status === 1` https://runbot.odoo.com/runbot/build/7007672 Forward-Port-Of: odoo/odoo#68711
If the company's currency is C, when trying to import a CAMT file to a journal with a currency defined but different from C, the new bank statement will not contain any line. To reproduce the error: (Company's currency must be USD) 1. In Settings, enable: - Multi-Currencies - CAMT Import 2. In Accounting, create a new journal J: - Type: Bank - Currency: EUR 3. Import statements into J using this file: - [camt_053_minimal_EUR.xml](https://drive.google.com/file/d/
Original PR description
If the company's currency is C, when trying to import a CAMT file to a journal with a currency defined but different from C, the new bank statement will not contain any line. To reproduce the error:…
If the company's currency is C, when trying to import a CAMT file to a
journal with a currency defined but different from C, the new bank
statement will not contain any line.
To reproduce the error:
(Company's currency must be USD)
1. In Settings, enable:
- Multi-Currencies
- CAMT Import
2. In Accounting, create a new journal J:
- Type: Bank
- Currency: EUR
3. Import statements into J using this file:
- [camt_053_minimal_EUR.xml](https://drive.google.com/file/d/1PyjqGgDeM12KVgo0Iux3FOxrM4ASIo35/view?usp=sharing)
Error: When confirming the import, the page is redirected to the
reconciliation page. However, there is nothing to reconcile. When
consulting the statement in J, the imported statement is present.
However, there is only one line in the statement, and this bank
statement line is zero (should be 500€)
Until now, the module reads the CAMT file and looks for an amount
expressed in the company's currency. However, it is not possible to find
an amount in the company's currency (USD) because all the amounts in the
CAMT file are expressed in journal's currency (i.e, EUR). This is the
reason why the bank statement line is zero.
Note: the file `camt_053_minimal_and_multicurrency.xml` has been added
to test #16656
OPW-2486849
Forward-Port-Of: odoo/enterprise#17506
Forward-Port-Of: odoo/enterprise#17279This commit is a cherry-pick of 32acb048f7149b529ee5fc00a626b927ea55e156 in which we added a test. Before this commit, it was not possible to scan a barcode with the camera on a tablet. It does work for mobile phones though. This bug was present since we removed native dialogs: See 6ca2d9e832a04df843b9aaeec54439f25f9cb006 _invokeMobileDialog was replaced by _search but the override of the latter is only done for small screens, otherwise the file is escaped. It's why it didn't worked
Original PR description
This commit is a cherry-pick of 32acb048f7149b529ee5fc00a626b927ea55e156 in which we added a test. Before this commit, it was not possible to scan a barcode with the camera on a tablet. It does work…
This commit is a cherry-pick of 32acb048f7149b529ee5fc00a626b927ea55e156 in which we added a test. Before this commit, it was not possible to scan a barcode with the camera on a tablet. It does work for mobile phones though. This bug was present since we removed native dialogs: See 6ca2d9e832a04df843b9aaeec54439f25f9cb006 _invokeMobileDialog was replaced by _search but the override of the latter is only done for small screens, otherwise the file is escaped. It's why it didn't worked for tablets (which have larger screens). To fix this, we cherry-picked a commit from saas-14.1 where we use _searchCreatePopup instead of using _search. It wasn't originally intended to fix this issue but it does the job in an elegant way. In addition, maintenance will also be easier by having common code between version 14.0 and saas-14.1. Steps to reproduce: - Go to Field service - Create a project.task - Go on Studio and add a many2one_barcode product.product - Open the camera by clicking on the widget - After scanning, nothing is shown to the user. opw-2466999 Forward-Port-Of: odoo/enterprise#17469 Forward-Port-Of: odoo/enterprise#17401
… partner_bank_id Steps to follow to reproduce the bug: - Install the "account_sepa" module - Go to Accounting > Customers > Batch Payments - Create a new Batch payment - Choose “Outbound” or “Inbound” for Batch type, - Select a Bank - Choose “Manual” for Payment method - Add a new Batch content Problem : When creating a new batch content, the field "partner_bank_id" is required while it shouldn't be. In the view this field is not based on the right field for the required condit
Original PR description
… partner_bank_id Steps to follow to reproduce the bug: - Install the "account_sepa" module - Go to Accounting > Customers > Batch Payments - Create a new Batch payment - Choose “Outbound” or “Inbound” for Batch type, - Select a Bank - Choose “Manual” for Payment method - Add a new Batch content Problem : When creating a new batch content, the field "partner_bank_id" is required while it shouldn't be. In the view this field is not based on the right field for the required condition. opw-2469311 Forward-Port-Of: odoo/enterprise#17427 Forward-Port-Of: odoo/enterprise#17267
Forward-Port-Of: odoo/enterprise#17452 Forward-Port-Of: odoo/enterprise#16970
Original PR description
Forward-Port-Of: odoo/enterprise#17452 Forward-Port-Of: odoo/enterprise#16970
1. Set terms and conditions on a Subscription, SO, and in General Settings (all different) 2. Add subscription product to SO and confirm 3. Generate invoice from the SO. Terms and conditions are inherited 4. Go to subscription, generate a new SO from the subscription, original SO terms and conditions are inherited 5. Let the subscription automatically generate a recurring invoice. The invoice has the terms and conditions from the General Settings Fine tuning of https://github.com/odoo
Original PR description
1. Set terms and conditions on a Subscription, SO, and in General Settings (all different) 2. Add subscription product to SO and confirm 3. Generate invoice from the SO. Terms and conditions are inherited 4. Go to subscription, generate a new SO from the subscription, original SO terms and conditions are inherited 5. Let the subscription automatically generate a recurring invoice. The invoice has the terms and conditions from the General Settings Fine tuning of https://github.com/odoo/enterprise/commit/a4eac4dff5fff35f83012bf2c7ae2456858feafc to give precedence to the subscription description before applying general terms and conditions opw-2440081 Forward-Port-Of: odoo/enterprise#17331