Before this commit, some values of res.config.settings were saved
(e.g case of website settings were some fields are related)
After this commit, they are not saved
OPW 1853230
closes#24972closes#25028
Before this commit:
* Module A defines a field X of model M
* Module B inherits from model M without touching field X
* Module C inherits from model M and extends field X by giving an INDEX
/ NOT NULL constraint.
* Module B and C depend from Module A, but not each other
If all three modules are installed and Module B is updated, the INDEX /
NOT NULL constraint could be dropped.
This happens because Module B can be loaded before Module C is loaded,
if that's the case, then after the upgrade of Module B, during the
schema checking, we verify that the field object we have and the field
on the DB are the same, since Module B doesn't introduce the index then
this check is false and we drop the index. When we get to loading Module
C, we do not do any schema checking because the module is not marked as
`to upgrade`, therefore the index is lost forever.
To solve this, we re-init the models that belong to the set of the intersection
between upgraded and modified models and loaded and modified models.
Fixes#24958
Before this patch, early connections made to a 11.0 Odoo server running
on Python 3 and deployed in threaded mode with socket activation would
generate invalid registries.
With this patch it is now possible, when this deployment mode is used,
to opt-out addons preload by setting the following environment variable:
ODOO_PRELOAD_ADDONS=no
Note: this environment variable is only available for v11.0 as later
versions does not preload anymore (cf: 1a39c9b)
Starting with the 1000th user, the kanban view returns the id value
as '1,001', which, for some reason, does not go well when trying to
find the attachment by url...
Use `raw_value` instead, which does not format the id value.
Before this patch the registry and cache signaling was only activated
for PreforkServer. In case Odoo was deployed in a multi process/multi
threaded architecture the signaling was not ensured, causing registry
de-synchronisation amongst threaded servers.
Backported from fd4939dc78
Before this patch the registry and cache signaling was only activated
for PreforkServer. In case Odoo was deployed in a multi process/multi
threaded architecture the signaling was not ensured, causing registry
de-synchronisation amongst threaded servers.
When the runbot spawns an Odoo instance, a CPU TIME limit is set.
When this limit is reached, the kernel kills the Odoo instance and no
message appears in the logs leaving the dev in a deep smoke cloud.
With this commit, the signal sent by the kernel when the soft
limit is reached (SIGXCPU), is intercepeted and Odoo shutdown gracefully with a
nice message for the dev.
We used to only log failed logins, and did not include the IP, which
makes it much less useful for intrusion detections systems (e.g. fail2ban)
For example, the following fail2ban filter definition should match a
failed login (in /etc/fail2ban/filter.d/odoo-login.local):
[Definition]
failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST>
ignoreregex =
This could be used with a jail definition to block the IP on HTTP(S).
Here is what it could look like for blocking the IP for 15 minutes when
10 failed login attempts are detected from the same IP within 1 minute:
[odoo-login]
enabled = true
port = http,https
bantime = 900 ; 15 min ban
maxretry = 10 ; if 10 attempts
findtime = 60 ; within 1 min
logpath = /var/log/odoo.log ; set the actual odoo log path here
Previously to this commit needaction used by JS was not taking into account
read notifications. It means notably Inbox counter could be higher than
expected as taking into account read messages while Inbox displays only
unread messages. This commit fixes that by checking notification state when
giving needaction_partner_ids to message_format result.
This fix has a small impact on performances as message_format is used in
notification process for chat or push. A better implementation of message
format and its postprocess could probably lessen this fix impact. As we
target stable version we avoid rewriting other part of the code. Optimization
will be done in development version.
Related to task ID 1841243. This is a manual backport of commit 69714fbeee
done in saas-11.2.
* margin have been recently added on some query count tests as currently query
count is not completely deterministic. Setting a warning is not really
interesting as it is the current behavior. Being in margin is now green
and solely provide a different logging message;
* logged messages are improved to ease grep;
This also reverts aae54ecc15 .
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
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
Christophe Simonis