Wednesday, December 2, 2020
27 changes · master
Miscellaneous changes
Purpose ======= The global attendances / global time off are copied but not their work entry types. 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#62623
Original PR description
Purpose ======= The global attendances / global time off are copied but not their work entry types. 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#62623
Description of the issue/feature this PR addresses: Deleted Journals: 1- Compras informales. 2- Gastos menores. 3- Compras al exterior. With the inclusion of l10n_latam_invoice_document module is not longer necessary to split purchase invoices in many journals, as an unique one can handle distinct document types. Added Journals: 1- Migracion CXC 2- Migracion CXP These two journals are used to load the invoices of sales and purchases of the initial load of Accounts Receivable and
Original PR description
Description of the issue/feature this PR addresses: Deleted Journals: 1- Compras informales. 2- Gastos menores. 3- Compras al exterior. With the inclusion of l10n_latam_invoice_document module is not…
Description of the issue/feature this PR addresses: Deleted Journals: 1- Compras informales. 2- Gastos menores. 3- Compras al exterior. With the inclusion of l10n_latam_invoice_document module is not longer necessary to split purchase invoices in many journals, as an unique one can handle distinct document types. Added Journals: 1- Migracion CXC 2- Migracion CXP These two journals are used to load the invoices of sales and purchases of the initial load of Accounts Receivable and Accounts Payable Missing taxes were added which are: 1- 18% ITBIS sobre el 10% del Monto Total 2- 18% ITBIS llevado al Costo Bienes 3- 18% ITBIS llevado al Costo Servicios The correct account was assigned to: Retención 5% ISR Gubernamentales [21030308 --> 11080302] Current behavior before PR: The journals that are being eliminated are not being used because the "Taxpayer Type" field replaces them. Lack of CXP and CXC journals for initial loading of accounts receivable and accounts payable. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62330
task-2277511 Forward-Port-Of: odoo/odoo#61586
Original PR description
task-2277511 Forward-Port-Of: odoo/odoo#61586
Behavior prior to this commit: - edit an existing invoice - add a line, but do not save - add an attachment - the attachment uploads and the new line stays visible - save the record: the line now disappears Behavior after this commit: - do not discard changes when reloading after adding an attachment opw-2369162 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62261 Forward-Port-Of: odoo/odoo#62155
Original PR description
Behavior prior to this commit: - edit an existing invoice - add a line, but do not save - add an attachment - the attachment uploads and the new line stays visible - save the record: the line now disappears Behavior after this commit: - do not discard changes when reloading after adding an attachment opw-2369162 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62261 Forward-Port-Of: odoo/odoo#62155
Override name_get to remove html from name this commit clsoes #60204 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#62642
Original PR description
Override name_get to remove html from name this commit clsoes #60204 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#62642
Before this commit the "subscribe to newsletter" form was using the action of the website form to obtain its reCaptcha token, while the validation of the token was done on a specific subscribe action. After this commit the "subscribe to newsletter" form is using its own action that matches the one used for validation. Fixes https://github.com/odoo/odoo/issues/62504 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merge
Original PR description
Before this commit the "subscribe to newsletter" form was using the action of the website form to obtain its reCaptcha token, while the validation of the token was done on a specific subscribe action. After this commit the "subscribe to newsletter" form is using its own action that matches the one used for validation. Fixes https://github.com/odoo/odoo/issues/62504 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#62713
This allow the user to open link in new tabs with middle click task-2387837 Forward-Port-Of: odoo/odoo#62304
Original PR description
This allow the user to open link in new tabs with middle click task-2387837 Forward-Port-Of: odoo/odoo#62304
This code is a leftover of https://github.com/odoo/odoo/commit/2972976962617d4b8a0113bae58c640ab41cdff8#diff-70e782021bdfee46734a7fc7dbcad3104f7f985dd37f9320f1480d424581d67fL191 - We should not get info from the `err` and `data` parameters, those are not the same as the it was before the code got migrated, `data.data` never exists. - The fact that we handle the fail on this call is also a leftover of that refactoring where the error was done through a generic template. - We should not handl
Original PR description
This code is a leftover of https://github.com/odoo/odoo/commit/2972976962617d4b8a0113bae58c640ab41cdff8#diff-70e782021bdfee46734a7fc7dbcad3104f7f985dd37f9320f1480d424581d67fL191 - We should not get info from the `err` and `data` parameters, those are not the same as the it was before the code got migrated, `data.data` never exists. - The fact that we handle the fail on this call is also a leftover of that refactoring where the error was done through a generic template. - We should not handle an error on publish action. We never handle that kind of error if the action should not fail by default. This is typically the case when loading the menu through "Edit Menu" or the page properties. - This is especially true with later version as error raised are already handled globaly  Closes #60041 Forward-Port-Of: odoo/odoo#62532 Forward-Port-Of: odoo/odoo#62439
Some mail servers may provide `Message-Id` header in a section typed `text/rfc822-headers` instead of a `message/rfc822` According to https://quimby.gnus.org/rfc/rfc1892.txt that section's body actually contains the headers from the bounced email. BEFORE: `bounced_message_id` is empty and thus the little email envelope icon doesn't turn red, nor do the email resend features trigger in the UI. You could be sending an invoice and never knowing it was bounced. AFTER: bounces from mail
Original PR description
Some mail servers may provide `Message-Id` header in a section typed `text/rfc822-headers` instead of a `message/rfc822` According to https://quimby.gnus.org/rfc/rfc1892.txt that section's body actually contains the headers from the bounced email. BEFORE: `bounced_message_id` is empty and thus the little email envelope icon doesn't turn red, nor do the email resend features trigger in the UI. You could be sending an invoice and never knowing it was bounced. AFTER: bounces from mail servers that return the `text/rfc822-headers` part will be handled properly. --- @Tecnativa TT21170 opw-2162067 opw-2344252 closes #42340 closes #62551 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#62706 Forward-Port-Of: odoo/odoo#62578
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#62721
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#62721
Introduced by: https://github.com/odoo/odoo/commit/fd50ba9fb838067fab0b920470cf79b9c94d785c#diff-7144f88ea32f36feb17ce1b8dda7dee1631f5ada34075414587df3948c6b3d1bR6148 The way the computed fields are invalidated depends of the dict order passed as parameter to the 'onchange' method. This is causing some unexpected behavior when dealing with computed editable fields because the user is loosing its custom value right away during the 'onchange'. Explanation: During the 'onchange', the one2
Original PR description
Introduced by:
https://github.com/odoo/odoo/commit/fd50ba9fb838067fab0b920470cf79b9c94d785c#diff-7144f88ea32f36feb17ce1b8dda7dee1631f5ada34075414587df3948c6b3d1bR6148
The way the computed fields are invalidated depends of the dict order passed as parameter to the 'onchange'
method. This is causing some unexpected behavior when dealing with computed editable fields because the user
is loosing its custom value right away during the 'onchange'.
Explanation:
During the 'onchange', the one2many value is cache by record._update_cache(changed_values, validate=True).
If the field is a one2many, 'value' contains a (1, _, {...}) command for updated lines.
Due to 'validate=True', the assignations are triggering invalidation.
In case there is anything on the parent model editing any line value, the whole one2many values are returned to
the user.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#62060Message search with `needaction` in domain should only return messages with `needaction` for the current user. Follow up on https://github.com/odoo/odoo/pull/52403 that changed how sub-queries were built. The current fix using `_search` is a non-ideal solution until task-2366651 brings a new domain operator for this use case. task-2388843 task-2389933 Forward-Port-Of: odoo/odoo#62428
Original PR description
Message search with `needaction` in domain should only return messages with `needaction` for the current user. Follow up on https://github.com/odoo/odoo/pull/52403 that changed how sub-queries were built. The current fix using `_search` is a non-ideal solution until task-2366651 brings a new domain operator for this use case. task-2388843 task-2389933 Forward-Port-Of: odoo/odoo#62428
task-2388659 Forward-Port-Of: odoo/odoo#62442
Original PR description
task-2388659 Forward-Port-Of: odoo/odoo#62442
problem ------- On project invoice to one customer based on employee rate A project manager that is not a timesheet approver get the error "You cannot access timesheets that are not yours." when he edit the project.sale.line.employee.map because editing this object may trigger write on account.analytic.line solution -------- The write trigger when a sale.line.employee.map is chaned should be done as sudo -- I confirm I have signed the CLA and read the PR guidelines at www.o
Original PR description
problem ------- On project invoice to one customer based on employee rate A project manager that is not a timesheet approver get the error "You cannot access timesheets that are not yours." when he edit the project.sale.line.employee.map because editing this object may trigger write on account.analytic.line solution -------- The write trigger when a sale.line.employee.map is chaned should be done as sudo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62671
Taxes calculation improved so must revert the following commit : https://github.com/odoo/odoo/pull/53788/commits/8c50e4772d9c5c5758e83302a001cc6f5c7af284 opw-2378978 Forward-Port-Of: odoo/odoo#62725 Forward-Port-Of: odoo/odoo#62244
Original PR description
Taxes calculation improved so must revert the following commit : https://github.com/odoo/odoo/pull/53788/commits/8c50e4772d9c5c5758e83302a001cc6f5c7af284 opw-2378978 Forward-Port-Of: odoo/odoo#62725 Forward-Port-Of: odoo/odoo#62244
In a previous commit, fa-fw classes have been removed from the rating snippet but we forgot to remove it also in the job descriptions templates. task-2312878 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#62760
Original PR description
In a previous commit, fa-fw classes have been removed from the rating snippet but we forgot to remove it also in the job descriptions templates. task-2312878 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#62760
Installing `l10n_mx_edi` on a database with a lot of `account.move.line` could lead to a `MemoryError`, in addition to take a lot of time (for no reason) when the ORM was computing the fields `l10n_mx_edi_tariff_fraction_id` `l10n_mx_edi_umt_aduana_id` which are related, stored, fields from `product.template`, which are empty/`NULL` on install (no default set for the field), and therefore the ORM was taking a lot of time and memory for, at the end, setting `NULL` for all records. By
Original PR description
Installing `l10n_mx_edi` on a database with a lot of `account.move.line` could lead to a `MemoryError`, in addition to take a lot of time (for no reason) when the ORM was computing the fields `l10n_mx_edi_tariff_fraction_id` `l10n_mx_edi_umt_aduana_id` which are related, stored, fields from `product.template`, which are empty/`NULL` on install (no default set for the field), and therefore the ORM was taking a lot of time and memory for, at the end, setting `NULL` for all records. By setting the columns in advance, the ORM doesn't attempt to compute these fields on install. This is similar to 34527639873854d2be5a9bb1e3b5c8b88e52de33 opw-2369886 Forward-Port-Of: odoo/enterprise#15115 Forward-Port-Of: odoo/enterprise#15110
Taxes calculation improved so must revert the following commit : https://github.com/odoo/odoo/pull/53788/commits/8c50e4772d9c5c5758e83302a001cc6f5c7af284 opw-2378978 Forward-Port-Of: odoo/enterprise#15094 Forward-Port-Of: odoo/enterprise#15035
Original PR description
Taxes calculation improved so must revert the following commit : https://github.com/odoo/odoo/pull/53788/commits/8c50e4772d9c5c5758e83302a001cc6f5c7af284 opw-2378978 Forward-Port-Of: odoo/enterprise#15094 Forward-Port-Of: odoo/enterprise#15035
Task [2194008](https://www.odoo.com/web?#id=2194008&action=333&active_id=967&model=project.task&view_type=form&cids=&menu_id=4720) VAT Summary by General account allows you to print for each G/L account the list of VAT codes with the total of the bases and the associated VAT amounts. This list serves among other things to help you draw up Annex A of the Luxembourg annual VAT return but can, for example, be useful when it comes to distinguishing by country the VAT to be reclaimed abroad
Original PR description
Task [2194008](https://www.odoo.com/web?#id=2194008&action=333&active_id=967&model=project.task&view_type=form&cids=&menu_id=4720) VAT Summary by General account allows you to print for each G/L account the list of VAT codes with the total of the bases and the associated VAT amounts. This list serves among other things to help you draw up Annex A of the Luxembourg annual VAT return but can, for example, be useful when it comes to distinguishing by country the VAT to be reclaimed abroad or for VAT Auditing. It’s mandatory for Luxembourg but it's still useful for generic auditing so we can add it globally Forward-Port-Of: odoo/enterprise#8614
There is a need to manage the computed field subject_serial_number (readonly False) using a separated compute method to prevent a loop call to the compute method that leads to store empty records. Forward-Port-Of: odoo/enterprise#14994 Forward-Port-Of: odoo/enterprise#14972
Original PR description
There is a need to manage the computed field subject_serial_number (readonly False) using a separated compute method to prevent a loop call to the compute method that leads to store empty records. Forward-Port-Of: odoo/enterprise#14994 Forward-Port-Of: odoo/enterprise#14972
- Set the current company in a EU country, e.g. Belgium - Create a partner P in another EU country, e.g. Luxemburg - Set a VAT number on the customer - Create a product A - Set the Intrastat Commodity Code on the product category - Create an Invoice for partner P with product A - Fill the Intrastat-related fields - Go to Accounting / Reporting / Intrastat Report The Commodity Code is not displayed. We need the `code` of the `account.intrastat.code`, not the `name`. opw-2393944 F
Original PR description
- Set the current company in a EU country, e.g. Belgium - Create a partner P in another EU country, e.g. Luxemburg - Set a VAT number on the customer - Create a product A - Set the Intrastat Commodity Code on the product category - Create an Invoice for partner P with product A - Fill the Intrastat-related fields - Go to Accounting / Reporting / Intrastat Report The Commodity Code is not displayed. We need the `code` of the `account.intrastat.code`, not the `name`. opw-2393944 Forward-Port-Of: odoo/enterprise#15074 Forward-Port-Of: odoo/enterprise#15067
Create an SO with a Taxcloud fiscal position. Click "Update Taxes": File ".../enterprise/account_taxcloud/models/taxcloud_request.py", line 127, in get_all_taxes_values self.taxcloud_date, # useDate AttributeError: 'TaxCloudRequest' object has no attribute 'taxcloud_date' Introduced by 664d16a154e3d783f8112c9bf30feea22e01be76. opw-2410836 Forward-Port-Of: odoo/enterprise#15078
Original PR description
Create an SO with a Taxcloud fiscal position. Click "Update Taxes":
File ".../enterprise/account_taxcloud/models/taxcloud_request.py", line 127, in get_all_taxes_values
self.taxcloud_date, # useDate
AttributeError: 'TaxCloudRequest' object has no attribute 'taxcloud_date'
Introduced by 664d16a154e3d783f8112c9bf30feea22e01be76.
opw-2410836
Forward-Port-Of: odoo/enterprise#15078WHY: chart of accounts may not be setup right after module installation Forward-Port-Of: odoo/enterprise#15069 Forward-Port-Of: odoo/enterprise#15058
Original PR description
WHY: chart of accounts may not be setup right after module installation Forward-Port-Of: odoo/enterprise#15069 Forward-Port-Of: odoo/enterprise#15058
Steps to reproduce the bug: - Let's consider a partner P and two consumable products PR1 (100€) PR2(200€) - Let's consider a commission plan CP of 10% on consumable products - CP is set on P as commission plan - Create a SO for a customer C and set P as deferrer and CP as commission plan - Add PR1 and PR2 on the SO - Confirm the SO and create the invoice I - Confirm I and register the payment - A RFQ has been created for P with 30€ of commission - Make a credit note CN of I for only P
Original PR description
Steps to reproduce the bug: - Let's consider a partner P and two consumable products PR1 (100€) PR2(200€) - Let's consider a commission plan CP of 10% on consumable products - CP is set on P as commission plan - Create a SO for a customer C and set P as deferrer and CP as commission plan - Add PR1 and PR2 on the SO - Confirm the SO and create the invoice I - Confirm I and register the payment - A RFQ has been created for P with 30€ of commission - Make a credit note CN of I for only PR1 - Confirm CN and register the payment Bug: A new line had been created on the RFQ with an amount of -30€ instead of -10€ opw:2335517 Forward-Port-Of: odoo/enterprise#14935
When changing the target model of a marketing campaign with existing activities, the mails will be sent to incorrect addresses (or it will even raise an error) To reproduce the error: (Set up a mail catcher) 1. Go to Marketing Automation 2. Create a new one with at least one activity 3. Save 4. Edit, Change the Target Model, Save 5. Launch a Test => It will either send the email to an incorrect address or raise an error. From now on, the user is warned when he changes the target m
Original PR description
When changing the target model of a marketing campaign with existing activities, the mails will be sent to incorrect addresses (or it will even raise an error) To reproduce the error: (Set up a mail catcher) 1. Go to Marketing Automation 2. Create a new one with at least one activity 3. Save 4. Edit, Change the Target Model, Save 5. Launch a Test => It will either send the email to an incorrect address or raise an error. From now on, the user is warned when he changes the target model while activities already exist. OPW-2342342 Forward-Port-Of: odoo/enterprise#15046 Forward-Port-Of: odoo/enterprise#14877
TASKID: 2393750 Forward-Port-Of: odoo/enterprise#15020
Original PR description
TASKID: 2393750 Forward-Port-Of: odoo/enterprise#15020
In l10n_lu the result line (18) for the profit and loss reports has the wrong formula. It is taking into account the account 142 while it should not. Task id #2325116 Forward-Port-Of: odoo/enterprise#13517 Forward-Port-Of: odoo/enterprise#13339
Original PR description
In l10n_lu the result line (18) for the profit and loss reports has the wrong formula. It is taking into account the account 142 while it should not. Task id #2325116 Forward-Port-Of: odoo/enterprise#13517 Forward-Port-Of: odoo/enterprise#13339