Tuesday, November 24, 2020
18 changes · master
Enhancements to existing features
When an unbuild order linked to a manufacturing order is completed, the system now automatically logs a note on the manufacturing order. This improves traceability by making it easier for users to see when and why a produced item was unbuilt.
Original PR description
This commit makes it so a note is logged when an unbuild order is linked to a manufacturing order is completed. Task: 2378831 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change simplifies Odoo's internal testing framework so two similar test approaches now behave consistently. It helps developers write faster, more reliable tests and reduces the chance that one test affects another, without changing day-to-day user features.
Original PR description
Essentially make both classes be the same one, and behave like `SavepointCase`.
This change updates many automated tests to use a newer shared testing approach and fixes an issue in Belgian payroll test setup. It helps make future development safer by reducing fragile test behavior, with no expected change for day-to-day users.
Marketing Automation was updated to stay aligned with recent changes in the related mailing system. This helps ensure existing marketing automation views continue to work correctly after the underlying naming updates.
Original PR description
This commit is simply the follow-up of the community counterpart where we had to rename a few XML elements. Task ID 2202759 Community PR odoo/odoo#57000
Resolved issues and error corrections
The point of sale cash control popup can now be validated when the entered amount is 0. This removes a checkout setup blocker for stores that need to record a zero opening cash balance.
Original PR description
It was impossible to validate the cash control popup if the value was 0. Now it's possible to validate any amount, including 0. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
What are the steps to reproduce your issue ? 1. Create two companies on a multi-company database without Website installed. For this use case, install Purchase 2. Configure two distinct logos per company 3. Create a Purchase Order with the second company. 4. Send PO from second company over as email. 5. Check recipient email (or mailhog for Runbot) for the email 6. Find that while the PDF report reflects second company's logo, the header navigati
Original PR description
What are the steps to reproduce your issue ? 1. Create two companies on a multi-company database without Website installed. For this use case, install Purchase 2. Configure two distinct logos per…
What are the steps to reproduce your issue ?
1. Create two companies on a multi-company database without Website installed.
For this use case, install Purchase
2. Configure two distinct logos per company
3. Create a Purchase Order with the second company.
4. Send PO from second company over as email.
5. Check recipient email (or mailhog for Runbot) for the email
6. Find that while the PDF report reflects second company's logo,
the header navigation bar in the client email when clicking "View Request
for Quotation" reflects company_id=1's logo.
What is currently happening ?
The displayed logo is not the correct one.
What are you expecting to happen ?
Display the right logo.
Why is this happening ?
Because when rendering the view. The value of 'res_company' declared in the context has as value the id of the default company of the user.
How to fix the bug ?
Specify the current company.
opw-2380274
Forward-Port-Of: odoo/odoo#62013
Forward-Port-Of: odoo/odoo#61957Original PR description
Companion of https://github.com/odoo/odoo/pull/62031
Before this commit, `destination_account_id` field was not required on model/view, Creating record without `destination_account_id` is not allowed since it is required on `account.move`. Now field is required. 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#62207
Original PR description
Before this commit, `destination_account_id` field was not required on model/view, Creating record without `destination_account_id` is not allowed since it is required on `account.move`. Now field is required. 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#62207
resize_class can be missing from the properties opw-2379828 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#61786
Original PR description
resize_class can be missing from the properties opw-2379828 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#61786
The replenishment menu is available even for users that are not allowed to use it. This causes the click_all test to fail with a warning. Forward-Port-Of: odoo/odoo#62223
Original PR description
The replenishment menu is available even for users that are not allowed to use it. This causes the click_all test to fail with a warning. Forward-Port-Of: odoo/odoo#62223
Activate multicurrency: * EUR with rate 1.0 * USD with rate 100.0 Have a company in currency USD Create an invoice (in USD) * invoice line of 12.15, no tax Save, post and register payment In the payment widget change currency to EUR. The amount will be automatically converted in 0.12 Register payment Invoice will be still marked to paid as the amount paid is 12.0. This occur because the system does not check if the amount to be paid, expressed in payment currency, is what has been
Original PR description
Activate multicurrency: * EUR with rate 1.0 * USD with rate 100.0 Have a company in currency USD Create an invoice (in USD) * invoice line of 12.15, no tax Save, post and register payment In the payment widget change currency to EUR. The amount will be automatically converted in 0.12 Register payment Invoice will be still marked to paid as the amount paid is 12.0. This occur because the system does not check if the amount to be paid, expressed in payment currency, is what has been paid. opw-2376336 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#61938
task-2392010 Forward-Port-Of: odoo/odoo#62230
Original PR description
task-2392010 Forward-Port-Of: odoo/odoo#62230
Steps to reproduce the bug: - Let's consider the current company C in Germany with a VAT number - Let's consider a partner P in Belgium with a VAT number and fiscal position Geschäftspartner EU (mit USt-ID) - Let's consider a product PR with weight and a 19% tax - Make a cutomer invoice CI to P with PR - The 19% tax will be replaced by Steuerfreie innergem. Lieferung (§4 Abs. 1b UStG) - Post CI - Go to the Intrastat report Bug: PR didn't appear in the report opw:2379263 Forwar
Original PR description
Steps to reproduce the bug: - Let's consider the current company C in Germany with a VAT number - Let's consider a partner P in Belgium with a VAT number and fiscal position Geschäftspartner EU (mit USt-ID) - Let's consider a product PR with weight and a 19% tax - Make a cutomer invoice CI to P with PR - The 19% tax will be replaced by Steuerfreie innergem. Lieferung (§4 Abs. 1b UStG) - Post CI - Go to the Intrastat report Bug: PR didn't appear in the report opw:2379263 Forward-Port-Of: odoo/odoo#62039
During the uninstall step of the registry, we perform a commit right after the uninstallation of all module data, this commit is performed right before the creation of a new registry, this means that said commit will call `flush_env` and thus `recompute` on an environment that is based on a stale Registry (memory and database are unsynchronized). This means that during this specific moment, there's a chance that the recompute function may have to fetch some fields it depends on to perfo
Original PR description
During the uninstall step of the registry, we perform a commit right after the uninstallation of all module data, this commit is performed right before the creation of a new registry, this means that…
During the uninstall step of the registry, we perform a commit right after the uninstallation of all module data, this commit is performed right before the creation of a new registry, this means that said commit will call `flush_env` and thus `recompute` on an environment that is based on a stale Registry (memory and database are unsynchronized). This means that during this specific moment, there's a chance that the recompute function may have to fetch some fields it depends on to perform its computations if said fields are not in cache, this in turn means that it will try to prefetch fields that are potentially no longer in the database, making the registry crash and preventing the uninstall. This is what happened with multiple if not all `payment_*` modules, the main module `payment` depends on a `ir.module.module` record, most notably the `color` field of the `payment.acquirer` model which depends on the `state` field which in turn depends on the `ir.module.module.state` field. This meant that uninstalling a module such as `payment_paypal` triggered a recompute of `payment.acquirer.color` during uninstall, and to perform that computation we need several `payment.acquirer` fields to be fetched from cache or the database. If in cache, the uninstall would go through without a hitch, if not in cache, we would fetch the required fields from the database but we'd also attempt to prefetch the fields introduced by `payment_paypal` that had just been deleted from the database! To avoid this, the `_module_uninstall_data` method of `ir.model.data` will henceforth guarantee that `ir.model.fields` that are to-be-deleted will have their prefetch set to False, meaning only existing fields will be fetched from the database during the uninstall of extending modules. Fixes #60424 opw-2372598 Co-authored-by: Raphael Collet <rco@odoo.com> Forward-Port-Of: odoo/odoo#62231
task-2388650 Forward-Port-Of: odoo/odoo#62059
Original PR description
task-2388650 Forward-Port-Of: odoo/odoo#62059
The `Adyen Account` menu entry leads to an external page. This cannot be tested by the click_all test. Forward-Port-Of: odoo/odoo#62224
Original PR description
The `Adyen Account` menu entry leads to an external page. This cannot be tested by the click_all test. Forward-Port-Of: odoo/odoo#62224
The partner is not visible in the form so copying can lead to unwanted behaviours. Task [2389917](https://www.odoo.com/web#id=2389917&model=project.task) opw-[2388430](https://www.odoo.com/web#id=2388430&model=project.task) 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#62067
Original PR description
The partner is not visible in the form so copying can lead to unwanted behaviours. Task [2389917](https://www.odoo.com/web#id=2389917&model=project.task) opw-[2388430](https://www.odoo.com/web#id=2388430&model=project.task) 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#62067
WHY: chart of accounts may not be setup right after module installation --- opw-2382456 X-original-commit: bea9f098edf6d5213f4b97edebbb13506dceaeae Forward-Port-Of: odoo/enterprise#14933
Original PR description
WHY: chart of accounts may not be setup right after module installation --- opw-2382456 X-original-commit: bea9f098edf6d5213f4b97edebbb13506dceaeae Forward-Port-Of: odoo/enterprise#14933
Steps to reproduce the bug: - Let's consider an employee E with lang's home adress (address_home_id.lang) in French - Let's consider the current logged user U in English - Go to a payslip P of E and print it from button 'Print' in the form view header - A PDF report in french is printed - Print P from the context menu print/payslip Bug: The report is in English Inspired from https://github.com/odoo/odoo/blob/14.0/addons/sale/report/sale_report_templates.xml#L5 https://github.c
Original PR description
Steps to reproduce the bug: - Let's consider an employee E with lang's home adress (address_home_id.lang) in French - Let's consider the current logged user U in English - Go to a payslip P of E and print it from button 'Print' in the form view header - A PDF report in french is printed - Print P from the context menu print/payslip Bug: The report is in English Inspired from https://github.com/odoo/odoo/blob/14.0/addons/sale/report/sale_report_templates.xml#L5 https://github.com/odoo/odoo/commit/222fcb137bc9c25d15ee0ad851078caa99e16bdf opw:2380631 Forward-Port-Of: odoo/enterprise#14868