odoo/enterprise#84203
Created by fw-bot
Statuses:
- legal/cla: Contributor License Agreement check
- ci/runbot: Odoo Test Suite
- ci/upgrade_enterprise: Test upgrades for enterprise master
- ci/template: Contact runbot team on discord for help.
- ci/style: Optional style check. Ignore it only if strictly necessary.
- ci/security: Required security check. Can only be ignored by security team.
- ci/l10n: (runtime 1s)
- label
- odoo-dev:saas-18.2-17.0-opw-4577091-safe_eval_is_within-abz-432006-fw
- head
- b5dc0dbbef43a2437efb1aa7821c9a2a462bb47c
- merged
- 1 year ago by Bugfix, Achraf Ben Azzouz (abz)
| odoo/odoo | odoo/enterprise | |
|---|---|---|
| 17.0 | #204172 | #82564 |
| saas-17.4 | #206507 | #83635 |
| 18.0 | #206708 | #83738 |
| saas-18.1 | #207558 | #84174 |
| saas-18.2 | #207601 | #84203 |
| saas-18.3 | #208479 | #84703 |
| master | #208491 | #84713 |
[FW][FIX] web_studio: Supports dynamic domain
Similar to: odoo/odoo#184830
We've recently introduced a new operator: “is within” in the domain
selector, which can be used to find out whether a date is within a
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as context_today,
which is defined in py_builtin.js and dynamically retrieves the
current date.
https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/core/py_js/py_builtin.js#L77-L79
However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s
In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where uid, user, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:
("date", "=", context_today()), they get a traceback.
This happens mainly because, in Python, the domain is evaluated via
literal_eval, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.
The community commit (odoo/odoo#204172) handles:
- website/model_page.py:
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L13-L18
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L47-L50
This commit
handles two other cases:
-
web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2 -
marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
literal_eval
In all three cases, the problem is the same: the problem is not only
present in is_within but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:
-
First,
to_utc()is removed from the domain, since it's purely
client-side and this notion doesn't exist in the python server -
We replace the
literal_evalcall withsafe_eval, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.) -
safe_evalcan therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as definingcontext_today() -
For the moment, the values we use are the same as those used by
is_within, i.e.: - context_today()
- relative_delta()
- datetime
- time
opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091
community: odoo/odoo#204172