The _auto_init method was overriden without keeping the return value of
the super on some models.
This break the new stored computed fields computation at field creation.
Closes#11985
opw-677232
This case corresponds to searches like `[(field, 'ilike', name)]` where `field`
is a many2many field. The domain processing performs a `name_search` on the
field's comodel, then makes the relation match the returned record ids.
Problem: the call to `name_search` uses the default limit (100), and this makes
the search return less results than expected. Make the search complete by
forcing `limit=None`.
Users may sometimes need to edit their own partner records directly,
although indirect access by writing on `res.users` directly works
fine in most cases.
The result of searching on a o2m field for a missing ID was
the whole set of records which do not have any lines in the
o2m fields. This is definitely not the desired behavior,
and could lead to disatrous performance, because the
returned set could be extremely large.
One example of such behavior is for recomputing fields
in the env cache in 8.0+. When a o2m line gets deleted,
it triggers the recompute of any dependent fields.
In order to locate the records to recompute, the ORM
searches for the 'parent' records in the comodel table.
When this operation is done by 2 users concurrently
the o2m line may not exist anymore, and the bug
is triggered: dependent fields are recomputed on a possibly
very large set of records that did not need any recompute!
When a new column has been added after that some data already exists,
the old lines will keep an empty/null value. So when we search is the new field
is equals to False or if it is different of True, we need to match the null
values.
Backport of de3b64018a
This revision back-ports revisions
983d5eb9fa
&
ccbb8e09a6
regarding this signature regex.
Besides, it adds the fact the dashes have to
be at the beginning of the line
to make them detected as a signature.
opw-655834
The current code when applying negative operator on an expression used
recursion which in extreme case is not best friend with python.
e.g: on instance with a lot of wharehouse, some simple action could lead
to a domain with lot of elements which could easiliy go over the python
maximum recursion limit.
This commit fixes this by replacing recursion with iteration.
We have a stack of negation flags and loop on each token of the domain
as follow :
- when we iterate on a leaf, it consumes the top negation flag,
- after a '!' operator, the top token negation is inversed,
- after an '&' or '|' operator, the top negation flag is duplicated on
the top of the stack.
closes#9433
opw-653802
In some complex use case of a workflow instance with several workitems,
a given workitem processing could itself somewhat recursively process
one of the following workitems.
This situation was currently not taken into account, so in that given
case, the already processed workitems would be processed again.
opw-647580
In case of different directory for stroing po and pot files than 'i18n'
(e.g. 'i18n_extra'), a po could be linked to a wrong pot file.
Use the same folder as the po file to look for pot.
Closes#4323
If an error happens in an overload of setUp, the already-open cursor
is likely not to get properly released before the next test,
deadlocking the db, because tearDown only runs if setUp has
succesfully completed.
Cleanups were added specifically to run every time, after tearDown has
(potentially) been executed.
closes#8327
Note: cleanups run in LIFO order (as they should).
Authentication modules are supposed to override res_users.check_credentials()
in order to plug in their own mechanism, without actually modifying the
behavior of res_users.check(), res_users.authenticate() or
res_users._login().
auth_openid was incorrectly overriding check() instead of
check_credentials(), and unnecessarily accessing private
attributes of res_users. Fixing the implementation of auth_openid
to follow the API means we can completely make those attributes
private.
This regex is used for a quick sanity check of
the order_spec in `search(order=<order_spec>)`.
Because it was build on the repetition of a
group ending with a series of optional patterns,
it could cause expensive backtracking when the
order spec did not actually match the regex
(the regex engine was trying all possible ways
to split the groups)
Forcing the repeating group to either end
with a comma or the end of the string prevents
prohibitive backtracking, while being even
more restrictive with regard to the syntax of
the order spec.
Closes#7755
Comments in .po(t) files for translations of type "code" (e.g. field labels)
specify the path to the file containing the translation. This path should be
OS-independent to get the same result whatever the plateform the instance is
running on.
Closes#7561
The field display_name is present in account_report_company but not in base
on the res.partner (has been added in v8 in base).
Create a hook method to keep using the slow CASE in base and switch to the
faster display_name when installing account_report_company.
In commit 44f2c8d54 we unified the return value of the function to int,
but it seems the returned size could be None which is not a valid input
of the int() built-in function.
To distinguish two ir.attachment 'File Content', we base it on the file
size (this I imagine is for efficiency).
This is done by setting bin_size in the context. Doing this, the
returned db_datas field will be the file size of the converted to base64
content (if no filestore).
But this size is returned in string format, so "get_nice_size" (in
openerp/osv/fields.py) which gets this size calculates the length of the
string. e.g: if the size is '2142' get_nice_size will return 4.
This fix solves this by converting the string to an integer, thus
unifying it with the filestore case (where we use os.path.getsize which
return an integer).
Also, the field presenting the issue (FieldBinaryFile) has been changed
so it is always updated even if the size is the same (as it was already
done by 3632949 for FieldBinaryImage widget).
closes#7223
opw-643071