Friday, January 8, 2021
19 changes · master
Documentation and clarification updates
This pull request adds a signed contributor agreement record for an individual contributor. It supports Odoo's legal contribution process and does not change any product functionality or user workflows.
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
Miscellaneous changes
In `run_scheduler`, we are running certain functions as super user to avoid inter company and access rights issues. This commit moves up the `sudo()` call such that it applies to the whole function, instead of only the `procure_orderpoint_confirm`. In addition a commit call is moved up to apply after the `procure_orderpoint_confirm` call (as it was, it was applied after the `_action_assign` loop, but there is in fact already a commit in that loop, this lead to a somewhat random behavio
Original PR description
In `run_scheduler`, we are running certain functions as super user to avoid inter company and access rights issues. This commit moves up the `sudo()` call such that it applies to the whole function, instead of only the `procure_orderpoint_confirm`. In addition a commit call is moved up to apply after the `procure_orderpoint_confirm` call (as it was, it was applied after the `_action_assign` loop, but there is in fact already a commit in that loop, this lead to a somewhat random behavior where the replenish rules were sometimes rolled back and sometimes not) opw-2394706 Forward-Port-Of: odoo/odoo#64021 Forward-Port-Of: odoo/odoo#63935
Forward-Port-Of: odoo/odoo#64186 Forward-Port-Of: odoo/odoo#63292
Original PR description
Forward-Port-Of: odoo/odoo#64186 Forward-Port-Of: odoo/odoo#63292
commit 38711e9f9c7a06017d284d75e31198fa9ae3cf37 prevent multi company issues. But it goes a little too far in restriction and prevent to put a service in the repair fee. Which is a feature since user would like to register and invoice human resources in maintenance cost. Forward-Port-Of: odoo/odoo#64019
Original PR description
commit 38711e9f9c7a06017d284d75e31198fa9ae3cf37 prevent multi company issues. But it goes a little too far in restriction and prevent to put a service in the repair fee. Which is a feature since user would like to register and invoice human resources in maintenance cost. Forward-Port-Of: odoo/odoo#64019
The Australian equivalent of a VAT number is an ABN number. In Australia TFN are private and not meant to be entered into systems or publicly displayed. ABN numbers are the public facing number that legally must be displayed on all tax invoices and legal documents. This fix will override the 'tfn' check done via stdnum for AU companies with 'abn' check opw-2415142 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merg
Original PR description
The Australian equivalent of a VAT number is an ABN number. In Australia TFN are private and not meant to be entered into systems or publicly displayed. ABN numbers are the public facing number that legally must be displayed on all tax invoices and legal documents. This fix will override the 'tfn' check done via stdnum for AU companies with 'abn' check opw-2415142 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#64131
[FIX] account: reconciliation models: make auto_reconcile rules work properly with write-offs - Create an invoice for 100 - Create a bank statement for 95 - Setup your reconciliation model so that it will match them and create a write-off for the remaining 5. Make it auto_reconciled. => Doing that, we expect the bank journal move to be created like this: - 100 on payable/receivable, reconciled with the invoice - 95 on the bank account - 5 on the write-off account This wasn't the
Original PR description
[FIX] account: reconciliation models: make auto_reconcile rules work properly with write-offs - Create an invoice for 100 - Create a bank statement for 95 - Setup your reconciliation model so that it…
[FIX] account: reconciliation models: make auto_reconcile rules work properly with write-offs - Create an invoice for 100 - Create a bank statement for 95 - Setup your reconciliation model so that it will match them and create a write-off for the remaining 5. Make it auto_reconciled. => Doing that, we expect the bank journal move to be created like this: - 100 on payable/receivable, reconciled with the invoice - 95 on the bank account - 5 on the write-off account This wasn't the case. Instead, Odoo created the following (correct from an accounting point of view, but weird): - 95 on payable/receivable, reconciled with the invoice - 5 on payable/receivable, not reconciled - 95 on the bank account - 5 on the write-off account => So an open balance of 5 was actually created. This was weird, and also caused an additional bug, as only the first payable/receivable line was reconciled with the invoice, making it only partially paid. This commit restores the expected behavior. [FIX] account: reconcile models: create write-offs properly when matching a statement line with no partner Before that, write-offs were simply never created in this case ; only an open balance. This was (obviously) wrong. Also, the partner set on the statement line was not modified, and kept empty. We fix that so that, when a statement line without is reconciled with lines sharing the same partner, this partner is also assigned to the statement line. Task 2423231 Forward-Port-Of: odoo/odoo#64150
In the bank reconciliation widget, allow matching a payment (blue lines) owned by another bank journal as the statement line one if both journal are sharing the same outstanding account. It implies to remove the constraint preventing such accounts sharing. The purpose is the following. Suppose you are working with payment acquirers generating payments on a bank journal A. At the end of the month, the bank journal B is debited to pay the payment acquirer. At this point, you get a statement
Original PR description
In the bank reconciliation widget, allow matching a payment (blue lines) owned by another bank journal as the statement line one if both journal are sharing the same outstanding account. It implies to remove the constraint preventing such accounts sharing. The purpose is the following. Suppose you are working with payment acquirers generating payments on a bank journal A. At the end of the month, the bank journal B is debited to pay the payment acquirer. At this point, you get a statement line on journal B you need to match with payments generated on A. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#64068
Create two differnt journals for two different bank accounts (A, B). Create an Internal Transfer in bank A to send money, then reconcile. Create an Internal Transfer in bank B to receive money, then try to reconcile Internal transfers are labeled 'Customer Reimbursement' and 'Customer Payment' even if no external partner is involved in the process, opw-2423161 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
Create two differnt journals for two different bank accounts (A, B). Create an Internal Transfer in bank A to send money, then reconcile. Create an Internal Transfer in bank B to receive money, then try to reconcile Internal transfers are labeled 'Customer Reimbursement' and 'Customer Payment' even if no external partner is involved in the process, opw-2423161 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#64139
Steps: - Install Invoicing and load French - Go to Invoicing - Click an invoice due in the future - Click Preview - Switch the preview to French by modifying the URL like this: example.com/my/invoices/6 -> example.com/fr_FR/my/invoices/6 Bug: "Due in %d days" is still displayed in English. The rest of the page is in French. Explanation: This is due to two things: 1. `mail` and `portal` are both installed and we cannot have more than one `code` translation of a source [1]. Since `ma
Original PR description
Steps: - Install Invoicing and load French - Go to Invoicing - Click an invoice due in the future - Click Preview - Switch the preview to French by modifying the URL like this:…
Steps: - Install Invoicing and load French - Go to Invoicing - Click an invoice due in the future - Click Preview - Switch the preview to French by modifying the URL like this: example.com/my/invoices/6 -> example.com/fr_FR/my/invoices/6 Bug: "Due in %d days" is still displayed in English. The rest of the page is in French. Explanation: This is due to two things: 1. `mail` and `portal` are both installed and we cannot have more than one `code` translation of a source [1]. Since `mail` is loaded before, alphabetically, `portal` doesn't add the duplicated translations with its own module name. When loading a web page, only the modules returned by `_get_translation_frontend_modules_domain()` are sent to the frontend. `mail` is not one of them and the duplicated translations are not sent. Since sending all the `mail` translations is overkill, this commit is modifying the format string. This won't change the text outcome, but will make the new sources unique and make the backend send these translations to the frontend. 2. Translations in `portal_sidebar.js` are queried before the translation DB [2] is made. This results in an empty array and `_t()` returns the source. `session.is_bound` will wait until the app is fully loaded before querying. [1] https://github.com/odoo/odoo/blob/ad2d96db8ad3e1fd7af2edda218fc34c0c1d259a/odoo/addons/base/models/ir_translation.py#L290 [2] https://github.com/odoo/odoo/blob/0de069b8ca9fb005ba5b076984f5677de25889ee/addons/web/static/src/js/core/translation.js#L51 opw:2421501 Forward-Port-Of: odoo/odoo#64249 Forward-Port-Of: odoo/odoo#64160
This takes the fix in #61820 one step further. Assume you recompute a field on two records, and the computation assigns the first record but not the second one. Before this patch, the recomputation process was accessing the field on both records. * When accessing the first record, both records are recomputed, and the value of the first one is found in cache. * When accessing the second record, no recomputation is made (it has been done already), and the cache is empty. The field is thus f
Original PR description
This takes the fix in #61820 one step further. Assume you recompute a field on two records, and the computation assigns the first record but not the second one. Before this patch, the recomputation process was accessing the field on both records. * When accessing the first record, both records are recomputed, and the value of the first one is found in cache. * When accessing the second record, no recomputation is made (it has been done already), and the cache is empty. The field is thus fetched from database, and this crashes because of insufficient access rights. This scenario was causing some obscure nondeterministic crashes in tests. The nondeterminism comes from * the choice of the environment for flushing (it should not be in superuser mode); * the order of records in the set to compute; * the order in which records are assigned in the compute method; * the fact that the compute method should assign some records and some not. Forward-Port-Of: odoo/odoo#64250
In the context of bug #43365, the fix merged in #48031 introduced an override of `ir.translation._load_module_terms()`, which calls `super()` then does some extra stuff. This was forward-ported to later versions, unfortunately the forward-ports missed the fact that the method signature changed at some point (circa saas-13.2) and the `overwrite` flag which used to be passed in the `context` had become an explicit method argument. As a result, that argument is lost in the `super()` call and
Original PR description
In the context of bug #43365, the fix merged in #48031 introduced an override of `ir.translation._load_module_terms()`, which calls `super()` then does some extra stuff. This was forward-ported to later versions, unfortunately the forward-ports missed the fact that the method signature changed at some point (circa saas-13.2) and the `overwrite` flag which used to be passed in the `context` had become an explicit method argument. As a result, that argument is lost in the `super()` call and the `website` module entirely disables the "overwrite" mode for the translation loading wizard. The fwd-port that seems to introduce the issue is odoo/odoo#50477 (998987f8ee148235f4025eb97a424e838ac6fc9f), here: https://github.com/odoo/odoo/commit/998987f8ee148235f4025eb97a424e838ac6fc9f#diff-12b5cd198104ceefb265af4d92669a9ae1cd8428339411b64e418e733887fa78R11 Forward-Port-Of: odoo/odoo#64231
Steps: - Install eCommerce - Go to "Website" > "Go to Website" - Click Edit - Add the Dynamic Products block with a template and a category - Save - Switch to mobile view Bug: The right arrow of the block overflows and makes it possible to scroll the entire view sideways. Explanation: This commit puts back prev and next arrows onto the carousel. It also changes their design to be more visible over the content. The arrows are now smaller and displayed in clickable gray circles.
Original PR description
Steps: - Install eCommerce - Go to "Website" > "Go to Website" - Click Edit - Add the Dynamic Products block with a template and a category - Save - Switch to mobile view Bug: The right arrow of the block overflows and makes it possible to scroll the entire view sideways. Explanation: This commit puts back prev and next arrows onto the carousel. It also changes their design to be more visible over the content. The arrows are now smaller and displayed in clickable gray circles. opw:2415187 Forward-Port-Of: odoo/odoo#63911
Steps to reproduce the bug: - Let's consider a company C with TaxCloud setup - Create a sale order SO with a customer C - Click on update taxes Bug: Odoo sent the information to TaxCloud without the customer ID. This was a problem, because, if the customer C had an exemption certificate, TaxCloud ignored that, as it couldn't match the ID, it charged the full tax and fees as well. Fine tuning of https://github.com/odoo/enterprise/commit/628ff63d131fe2f28dcdb6c47895766361db3398 o
Original PR description
Steps to reproduce the bug: - Let's consider a company C with TaxCloud setup - Create a sale order SO with a customer C - Click on update taxes Bug: Odoo sent the information to TaxCloud without the customer ID. This was a problem, because, if the customer C had an exemption certificate, TaxCloud ignored that, as it couldn't match the ID, it charged the full tax and fees as well. Fine tuning of https://github.com/odoo/enterprise/commit/628ff63d131fe2f28dcdb6c47895766361db3398 opw:2422962 Forward-Port-Of: odoo/enterprise#15641 Forward-Port-Of: odoo/enterprise#15640
Forward-Port-Of: odoo/enterprise#15646
Original PR description
Forward-Port-Of: odoo/enterprise#15646
This bug was introduced by the payments refactoring; the 'sent' state of account.payments has been replaced by a is_move_sent on account.move. Payments in 'posted' state can now be posted. Forward-Port-Of: odoo/enterprise#15633
Original PR description
This bug was introduced by the payments refactoring; the 'sent' state of account.payments has been replaced by a is_move_sent on account.move. Payments in 'posted' state can now be posted. Forward-Port-Of: odoo/enterprise#15633
In the bank reconciliation widget, allow matching a payment (blue lines) owned by another bank journal as the statement line one if both journal are sharing the same outstanding account. It implies to remove the constraint preventing such accounts sharing. The purpose is the following. Suppose you are working with payment acquirers generating payments on a bank journal A. At the end of the month, the bank journal B is debited to pay the payment acquirer. At this point, you get a statement
Original PR description
In the bank reconciliation widget, allow matching a payment (blue lines) owned by another bank journal as the statement line one if both journal are sharing the same outstanding account. It implies to remove the constraint preventing such accounts sharing. The purpose is the following. Suppose you are working with payment acquirers generating payments on a bank journal A. At the end of the month, the bank journal B is debited to pay the payment acquirer. At this point, you get a statement line on journal B you need to match with payments generated on A. Forward-Port-Of: odoo/enterprise#15556
### Summary Commit https://github.com/odoo/enterprise/commit/423f32764eff2243fb86af8f48af63a09aa2a7da introduced an error in the visualization of planning in the website due to a wrong parameter name. This PR fixes the parameter name, therefore fixing the error.  Forward-Port-Of: odoo/enterprise#15642
Original PR description
### Summary Commit https://github.com/odoo/enterprise/commit/423f32764eff2243fb86af8f48af63a09aa2a7da introduced an error in the visualization of planning in the website due to a wrong parameter name. This PR fixes the parameter name, therefore fixing the error.  Forward-Port-Of: odoo/enterprise#15642
The document is available on the documents applications. But nothing is really sent if the Documents application is not installed. Forward-Port-Of: odoo/enterprise#15617 Forward-Port-Of: odoo/enterprise#15611
Original PR description
The document is available on the documents applications. But nothing is really sent if the Documents application is not installed. Forward-Port-Of: odoo/enterprise#15617 Forward-Port-Of: odoo/enterprise#15611
…mail.thread PURPOSE Notification may be sent using a generic mail.thread record, notably when sending user notifications. In that case links to view document are incorrect. SPECIFICATIONS Propagate message value through various notification sub methods. That way we can rely on them if model seems void. Also limit values given as URL parameters to some white listed values. This commit updates enterprise code according to community changes. See related community PR odoo/odoo
Original PR description
…mail.thread PURPOSE Notification may be sent using a generic mail.thread record, notably when sending user notifications. In that case links to view document are incorrect. SPECIFICATIONS Propagate message value through various notification sub methods. That way we can rely on them if model seems void. Also limit values given as URL parameters to some white listed values. This commit updates enterprise code according to community changes. See related community PR odoo/odoo#63292 for more details. LINKS opw-2358846 Task ID-2379766 Followup of odoo/odoo#60998 Followup of odoo/odoo#61545 Closes odoo/odoo#63292 Closes odoo/enterprise#15585 Forward-Port-Of: odoo/enterprise#15605 Forward-Port-Of: odoo/enterprise#15585