The commit 6d3ada178f
aimed to solve problems occuring whith (single or
double) quotes when creating new custom filters.
Unfortunately, the point was missed and bugs were
still present. The present commit solves the
orginial problem satisfactorily.
There was also a problem in the management of
backslashes. Type '\\' in the search bar would
lead to a domain like
[('...', 'ilike', '\\\\\\\\\\\\\\\\')].
This has also been fixed. Note that it is
necessary to input "\\" if one is looking for a
backslash in db (as before).
A remark on the _formatAST function (py_utils.js):
We deescape only the chars `'`, `"`, and `\`
because it does not seem possible to produce a
string in the search view that would intend a
search for a line return or a tab for example.
A general remark:
Domains should always be in normalized form.
In that way they could be manipulated and combined
together without a tokenization/parsing!
closesodoo/odoo#29756
Recent works in the search view (in 12.0) on dynamic filters had an
unfortunate effect: when the user tries to input escaped strings (for
example "test" in custom filters, there was a crash.
The reason is that the JS python parser (or more specifically, the
tokenizer) was unable to parse that as a string. It worked before
because the web client sent the raw string to the server. However, with
dynamic filters, this is no longer the case, and we need to parse
domains to be able to combine them.
In this commit, we modify the tokenizer to be able to work with escaped
strings.
closesodoo/odoo#29324
Introduce utilities to calculate the start / end of a period given a date or datetime object in the JS python interpreter.
This commit is the JS implementation of commit 960360afe4
This commit allow to create easily a range of periods (related to a field
of date or datetime type) to select in the filters menu.
Two new attributes on elements with tag 'filter' are now usable
in combination in a search view arch:
- date: string.
A valid field name with associated type date or datetime
- default_period: string (optional).
To choose in the following list:
- 'today'
- 'this_week'
- 'this_month' (default)
- 'this_quarter'
- 'this_year'
- 'yesterday'
- 'last_week'
- 'last_month'
- 'last_quarter'
- 'last_year'
- 'last_7_days'
- 'last_30_days'
- 'last_365_days'
Example:
<filter string="Creation Date" name="period_generator" date="create_date" default_period="this_quarter"/>
Note: the attribute 'domain' can not be used for such filters.
The generated domains are dynamic and can be saved as such
via the favorites menu.
Some functions that were in web.pyeval were actually "odoo independant".
To make them easier to manage/understand, this commit move them in the
library py.js, as an extra file.
Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.
Mainly:
- JS refactoring and linting
- Conversion of .sass into .less split into multiple files
- Templates cleaning and DOM simplification
- Re-generation of web.pot, and update of .po files
When providing an args of ``null`` (or ``undefined``) and a non-empty
kwargs, the kwargs would be removed/ignored.
While explicitly providing a null args is not necessary, it's perfectly
valid.
* use new support to colorize reconciled bank statement lines
* fixes tokenization of ``is not`` to not blow up on ``not foo``
* improves calling code to get truthiness of evaluated expression
instead of truthiness of javascript-equivalent objects: an empty list
is falsy in Python but truthy in javascript, since the evaluated
expression is in Python one would expect Python truthiness rules
without having to manually convert to boolean
closes#5070
* Accesses in contexts & domains are object derefs, so using dicts was
dumb
* But objects still need to round-trip through in case of e.g. o2m
commands in contexts, so py.object needs a toJSON (or a special
object kind needs to be added, specifically for round-tripping
objects through)
bzr revid: xmo@openerp.com-20121203122312-gc499mujf4l0nuz7
should probably go through a testing phase (checking its result
against that of eval_domain_and_context) for a while, but apart from
that it's supposed to work.
'stdlib' stuff (datetime.date.today, datetime.timedelta,
time.localtime, time.time, time.strftime) still need to be
written. Isn't there also a dateutil.relativedeleta somewhere?
Anyway that needs to be done and the various evaluation contexts need
to be defined, but the valuator itself should mostly work.
bzr revid: xmo@openerp.com-20120227073721-nkgeiqacbzch8xev
Mathieu Duckerts-Antoine