| Age | Commit message (Collapse) | Author |
|---|
|
Handling of escapes (`\`) was performed during evaluation rather than
parsing, so strings in the AST stored the escaped form (rather than
the proper one), and _formatAST had to mess around in order to try and
get it back into a semblance of relevance (especially as the AST would
store the escaped string without delimiters).
Fix: perform the escapes handling (aka normalisation) during
tokenization where it belongs. This means the AST formatter can now
just JSON.stringify the data. Until and unless we decide to produce a
cpython-compliant
repr (https://github.com/python/cpython/blob/0169d3003be3d072751dd14a5c84748ab63a249f/Objects/unicodeobject.c#L12902-L13006)
which is unlikely.
closes odoo/odoo#50236
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
Conditional expressions were already parsed, but there was no support
for executing them (or stringifying them back though I'm not sure when
that's used).
closes odoo/odoo#40502
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
Add a new behavior to numeric fields, possibility to enter value manually or to use a simple arithmetic expression that will be evaluated.
Example: =20+3*2
In order for the computation of the arithmetic expression to be done, the value needs to starts with = and then an expression can be entered. We only support the basics mathematical operations + - * / ( ) ^
User locale and digits separator are taken into account. If the value entered can't be evaluated to a numeric, the field will be displayed in error.
closes odoo/odoo#34538
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
The commit 6d3ada178f7caf6ea159b871648ca4c440c7845b
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!
closes odoo/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.
closes odoo/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 960360afe478a8f7b9c456721b5591154952a37d
|
|
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
|
|
|
|
|
|
closes #6129
|
|
|
|
|
|
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
|
|
update py.js to support parsing of escape sequences in string literals
bzr revid: xmo@openerp.com-20130517162215-4afen1mdzbfx1mxi
|
|
bzr revid: chm@openerp.com-20130104140000-22t1wj95jp7ro2ho
|
|
and add default toJSON to all py.object
* 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
|
|
bzr revid: xmo@openerp.com-20121203114706-dn5sqq3glqst4g1q
|
|
bzr revid: xmo@openerp.com-20121203084803-ib325gp18g5xvdv6
|
|
bzr revid: xmo@openerp.com-20121129132738-fcnam8bkqyt7h8ey
|
|
also various style improvements in the lib
bzr revid: xmo@openerp.com-20121128155448-1tv62wyv3zy2asr5
|
|
bzr revid: xmo@openerp.com-20121127154037-fiu6vsfdvix3zlmz
|
|
bzr revid: xmo@openerp.com-20121126075327-m3ljltvbhrwm8cbm
|
|
bzr revid: xmo@openerp.com-20121126073002-deta3rdrwmzao6fy
|
|
timedelta
bzr revid: xmo@openerp.com-20121008120619-lhmexjnujjrigjn9
|
|
bzr revid: xmo@openerp.com-20120806110638-1m4rg205sb3vjvm5
|
|
bzr revid: xmo@openerp.com-20120404114647-t81pw90940canfwg
|
|
relativedelta
bzr revid: xmo@openerp.com-20120305085532-0vcz6j0m985gjuz1
|
|
bzr revid: xmo@openerp.com-20120301111807-f3lthxw4zkytk42f
|
|
bzr revid: xmo@openerp.com-20120229115456-5rp0iuv3sftujq6b
|
|
bzr revid: xmo@openerp.com-20120229085250-ihg2vgjrpl2eyd0i
|
|
~
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
|
