When a string value is assigned to a selection field expecting integers, the
value simply rejected. In such a case, convert the value to an integer before
validating it.
When ir.values was removed and the "action" ir.values were merged
directly into the actions themselves, "client_action_relate" was
discarded as unused (and possibly too similar to
client_action_multi?). *However*:
* it was actually used implicitly as "relate" was the default key2 of
the <act_window> XML tag
* and it had a crucial difference from client_action_multi:
client_action_multi is shown on both form and list views by default
and only on list if multi=True, whereas relate is shown on *either*
the form or list view (tree if multi else form)
This means without relate the actions which should be only visible on
the form view are now on both list and tree, which leads to
overpopulated `Action` menus and odd behaviours (e.g. actions relying
active_id on lists, which id do they get and why?)
=> reintroduce relate as "action_form_only" for the specific case of
multi=False and either no key2 or a key2 of client_action_relate. If
multi=True then binding_type=action.
Fixes#20124
Followup: Task 1843603 to remove #multi and redundancy
The transcoding of a mail (transforming CSS into inline styles on the
element nodes of the mail) used the form:
property:value;
So when a mail is saved, it would be eg. with `style="property:value;"`
and when it is being edited "property:value" is removed if available via
CSS stylesheet given the structure.
But the sanitize_style (introduced in bfe7aafa7) adds an espace before
the value (which is more pretty but was probably not choosen in
transcoding to decrease size of mail):
property: value;
so the inline style would not be removed when editing possibly causing
conflict with the editor.
With this commit, the sanitize_style doesn't add a space. It could have
been changed in transcoding but the code is already rather slow and we
don't want to use a regex replace or two string replace instead of the
current one string replace.
opw-1841107
New records (with a NewId) are not necessary in the cache, but should
not be prefetched.
This check has been omitted during optimisation in b0c08a6846.
opw-1843566
opw-1843636
opw-1843683
opw-1843548
opw-1843629
opw-1843657
Closes#24595
Users will be more likely to look for a module named email marketing
than they would be searching for a module named mass mailing.
Task #1825294Closes#23634
Instead of searching for ids in the whole cache, search for the ones we will potentially prefetch.
Example: imagine you have 1K records in cache, and only 3 records in your prefetch set. Instead of retrieving the 1K records that have a value in cache, retrieve which of the 3 records that have no value in cache.
Steps to reproduce:
- Go to the Contact
- Create a new contact with an email address with an ascii character
Bug:
A traceback was raised.
Closes#19852
opw:1837714
ConnectionError is raised when there is no internet connection
if case of timeout a ConnectTimeout or ReadTimeout is raised.
It was not catched.
requests.exceptions.Timeout catches both
Restore behaviour of not adding the separating dot if the module field
of an ir.model.data record is empty. This is useful/important for
interop with external systems.
When a record fields are prefetched, the currently accessed record is
prefetched as well as PREFETCH_MAX (=1000) minus currenly accessed
records.
Since 439fa826 the id field was thought as "prefetched" but was not,
which caused that in an onchange, we would have a prefetching as follow
for 1200 records:
- get records 1-1000
- get record 1001 (1001-1200 INTERSECTION 1-999 (id) + 1001 (current))
- get record 1002 (1002-1200 INTERSECTION 1-999 (id) + 1002 (current))
- get record 1003 (1003-1200 INTERSECTION 1-999 (id) + 1003 (current))
- ...
- get record 1200 (1200 INTERSECTION 1-999 (id) + 1200 (current))
So we would do 201 queries instead of 2 when prefetching the records.
The added test without this change failed the query count with:
"AssertionError: 284 not less than or equal to 5 : admin"
opw-1837548
opw-1837552
closes#24326
Assume a custom field F is defined on model 'res.partner'. The setup of F may
silently fail because of missing stuff. In that situation, setting up the
field inherited from F on model 'res.users' should also silently fail.
To reproduce the bug, install Invoicing, create a related custom field F on
'res.partner' with 'property_account_position_id.active', and install another
module. Setting up F after loading module 'base' will fail because the field
'property_account_position_id' does not exist yet. The error is not caught by
the inheritance of F on model 'res.users', and the installation crashes.
Assume a custom field F is defined on model 'res.partner'. The setup of F may
silently fail because of missing stuff. In that situation, setting up the
field inherited from F on model 'res.users' should also silently fail.
To reproduce the bug, install Invoicing, create a related custom field F on
'res.partner' with 'property_account_position_id.active', and install another
module. Setting up F after loading module 'base' will fail because the field
'property_account_position_id' does not exist yet. The error is not caught by
the inheritance of F on model 'res.users', and the installation crashes.
OPW 1835872
The Arabic we use on Transifex is "simple" Arabic, not the one from Syria.
The .po files we synchronise are named 'ar.po', not 'ar_SY.po'
Change the iso_code to match the one we actually use.
transifex module relies on the iso_code to make its URL
The issue occurs when `read_group` is called with a date/datetime field to
group and order on, and the group_by is qualified, such as:
model.read_group(..., groupby=['date:week'], orderby='date')
The ORDER BY clause in the query should use the same term as the GROUP BY
clause for the corresponding field.
OPW 1834148
Christophe Simonis