Friday, November 1, 2019
3 changes · master
Miscellaneous changes
When testing the import of records, a flush should be done to check all databases constraints and fields computations. Moreover, in case an exception is raised within a savepoint, the environment should be cleaned up, to avoid tricky bugs (see below). We replace the manual handling of savepoints with the savepoint context manager, which already handles all of this. This code predates the context manager, so in a way it was archaic. Same for the check that the cursor was not broken already
Original PR description
When testing the import of records, a flush should be done to check all databases constraints and fields computations. Moreover, in case an exception is raised within a savepoint, the environment…
When testing the import of records, a flush should be done to check all databases constraints and fields computations. Moreover, in case an exception is raised within a savepoint, the environment should be cleaned up, to avoid tricky bugs (see below). We replace the manual handling of savepoints with the savepoint context manager, which already handles all of this. This code predates the context manager, so in a way it was archaic. Same for the check that the cursor was not broken already. When testing the import of records, the following could happen: "An unknown issue occurred during import (possibly lost connection, data limit exceeded or memory limits exceeded)." This would happen on project tasks; the fields 'working_hours_open', 'working_hours_close', 'working_days_open', 'working_days_close', all depend on the computation of _compute_elapsed. Because this is a test import, the records would raise a MissingError, and fields_to_compute would always contain 3 of the fields. The resulting is an infinite loop giving this error. opw 2092134 Co-authored-by Raphael Collet <rco@odoo.com> 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#39627
By default, the name of a file input field is 'Custom File Upload'. If there are two fields with the same name, then they both end up in self.form_fields with the name 'Custom File Upload[0]', and their values are concatenated, which are file objects. So the concatenation of two files is a String, ('[object File],[object File]'), because JavaScript. (And if you don't like it you don't like the web nor human progress.) The resulting bug is that instead of adding attachments to the created
Original PR description
By default, the name of a file input field is 'Custom File Upload'.
If there are two fields with the same name, then they both end up in
self.form_fields with the name 'Custom File Upload[0]', and their values
are concatenated, which are file objects. So the concatenation of two
files is a String, ('[object File],[object File]'), because JavaScript.
(And if you don't like it you don't like the web nor human progress.)
The resulting bug is that instead of adding attachments to the created
record, it adds the string message to the notes.
Adding the outer loop index disambiguates the names, so that all
attachments are created as intended.
opw 2092653
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#39499Steps to reproduce the bug: - Ask a question in the forum with a title but with no content Bug: A traceback was raised. opw:2093665 Forward-Port-Of: odoo/odoo#39625
Original PR description
Steps to reproduce the bug: - Ask a question in the forum with a title but with no content Bug: A traceback was raised. opw:2093665 Forward-Port-Of: odoo/odoo#39625