| Age | Commit message (Collapse) | Author |
|---|
|
closes odoo/odoo#52826
Related: odoo/enterprise#11084
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
before this commit, domain selector widget does not support
TRUE_LEAF and FALSE_LEAF i.e. [(1, '=', 1)] and [(0, '=', 1)] respectively,
the reason is the chain part of the domain i.e. field name has value 1/0 and
we don't have field name like 1 and 0 in domain and hence ModelFieldSelector
don't accept it
after this commit, domain selector can handle this special two domains which is
[(1, '=', 1)] and [(0, '=', 1)], add support for chain with 1/0 in ModelFieldSelector
task- 1998145
closes odoo/odoo#35603
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
The datepicker lib has been updated to tempus dominus (BS4)
recently, but our code hasn't been adapted correctly to the
requirements of the new version of the lib. As a consequence,
the datepicker didn't close itself when the input was focused
out anymore.
This required a slight change in the DomainSelector widget as it
produced a crash when a focused datepicker widget is removed from
the DOM (before the datepicker is destroyed), e.g. by a call to
html() on one of its parent.
Task 1878254
|
|
|
|
|
|
Before this rev., there was a crash when a FieldDomain was reset
with a new domain (e.g. coming from an onchange). For instance, it
crashed in Email Marketing > create new Mass Mailing > select
mailing lists. Introduced by 68332a01.
opw-1882850
|
|
|
|
The domain was instantiated without being given any evaluation context.
As a result, the uid variable was not defined,
crashing the js if present in a user-defined filter.
opw 1866852
|
|
This option is used to set a default domain value when creating a new node
(instead of [['id', '=', 1]]).
|
|
- The dropdown structure was simplified, allowing to get rid of the
3-levels structure induced by <ul/> elements and dropdowns can now
contain anything. The class 'dropdown-item' is now mandatory for
each dropdown clickable element. The class 'dropdown-item-text' can
be used to add same padding and style but without making the element
have a clickable look.
- Dividers now use the class 'dropdown-divider'
- The way dropdowns are opened and hidden also changed (before the
'open' class was added on the `.dropdown-menu` parent, now the
'show' class is added on both the `.dropdown-menu` parent and the
`.dropdown-menu` itself).
- JS-wise, no click event handlers can be put on `.dropdown-toggle`
elements anymore (instead, use handlers for dropdown events).
- Carets are automatically put on `.dropdown-toggle` elements, so this
commit replaces the `.caret` elements with this. This feature was
possible to disable but would prevent us from adding a caret with
scss. Also, this simplifies the DOM. The 'o-no-caret' class was also
introduced to allow using the 'dropdown-toggle' class on non-caret
elements.
- Also adapt the scss to use $caret-width instead of $caret-width-base
|
|
Lots of small usability improvements on the mass_mailing app.
|
|
A domain could contain the key `parent` (in an embedded subview), like:
domain="[('display_name', '=', parent.display_name)]")
This is currently not handled by the DomainSelector.
This will probably be handled in a future version but for this stable version,
this case that triggered an error is now catched and an error message is
displayed in the widget.
This was causing a traceback when opening a domain with `parent` in the edition
of a subview with Studio.
|
|
|
|
Since the new views, the field parsing for m2o returns an object with
id and display_name. If the given value to parse is a string, it is
supposed that this is an ID. This was breaking the domain selector
widget which should allow strings as name-strings of m2o values.
|
|
For boolean fields, the choice is "set (true)" or "not set (false)"
Missing _t to translate it
|
|
Fix a bunch of ill-documented/incomplete/incorrect method docs
Without this, the automatic doc generation does not work.
|
|
|
|
+ Document and refactor the files using the new guidelines
* Now only non-technical names are used when building field chains and
domains (technical names can be used in debug mode).
* Better warnings are displayed when using the field and/or domain
selector widgets (also checks domain validity in both domain field
AND domain selector widget).
Also improve design (thanks to original work of @stefanorigano):
- Hovering 'remove' highlights the element that will be removed
- Hovering 'add node' btns shows where the new node will be created
- Restyle debug domain input field (make it similar to a text editor)
- Improve design and layout
- Resize inner fields
|
|
|
|
With the new `field_utils` parsing functions, many field types were
not able to be used with the domain selector anymore.
* a m2o value is now parsed to an object with an `id` key and a
`display_name` key. This object cannot be placed in the `<input/>`
holding a `DomainLeaf` value in the domain selector widget (right
now, it is showing [Object object] because of this parsing). If
the value is an object, display its `id` key or nothing if this
key does not exist.
* a date(time) value is now parsed to a moment object. Adaptation had
to be made so that it is correctly displayed for the user and
properly converted to its server format when building the char
domain.
* an array of char is formatted to an empty string... obviously the
selector implementation is wrong here and should format array
values individually. However, as the widget only support arrays
for char values, the formatting is useless so it can simply be
disabled in that case while waiting for better implementation.
Note: the parsing and formatting code in domain selector should be
improved to be more accurate and understandable. This will be done
in a future update.
|
|
* Data manager load_view returns a viewInfo object
* ViewInfo contains: the arch, fields and fieldsInfo objects, and some extra informations
* The fields come from the server and are frozen, without any view attributes (depend of the model).
* The fieldsInfo contains every view attributes and informations.
|
|
We replace a bunch of formatting and parsing functions by an object
(parse or format) which can be used to dispatch on the correct type. It
allows us to remove the format_field and parse_field functions.
Also, we camelcase our new code and add some comments.
|
|
Add the implementation of the "FieldDomain" (widget='domain') in
basic fields file.
|
|
use 'web.field_utils' instead of 'web.formats'
|
|
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
|
|
|
|
The domain selector currently determined the list of available
operators according to field types (and used only a subset of
supported ones).
In some context, we might want to restrict this list of available
operators. Indeed, in client-evaluated domains, the "ilike" operator
cannot be used for example.
|
|
In saas-14, domain selector widgets are supposed to be instanciated
with a valid domain.
The problem is that some valid domains were wrongly evaluated. Indeed,
when receiving a domain which does not begin by an operator, the
"DomainTree" widget considered there is an implicit "&" operator that
should be used. This is not enough. Indeed, when evaluating the domain
["|", A, B, C], there is also an implicit "&" despite the fact the
domain starts with an operator ("|"). Because of that, previous
implementation interpreted this domain as ["|", A, "&", B, C] while
it should have been interpreted as ["&", "|", A, B, C].
Note: in master the parsing will be improved to handle wrong domains
and be decoupled of the DomainTree widget.
|
|
The "ModelFieldSelector" widget has a "filters" option which can
customize the fields which are displayed.
The "DomainSelector" widget has of course the same option it can
transmit to its internal "ModelFieldSelector" instance... but it
was documented as "fs_filters" instead of "filters".
Also, let the "ModelFieldSelector" document its own options and
sets their defaults (instead of the "DomainSelector" widget).
|
|
Before this commit, you had to avoid to click on the "..." icon inside
the button to have it have the right behavior.
|
|
Before this commit, the DomainSelector had to be instanciated with an
array-typed value which forced the user to use (and import) the pyeval
module. Now, the conversion to array is done in the DomainSelector.
This commit introduces a web.domainUtils module allowing to do the
convertion array -> string and string -> array of a domain.
|
|
* base_action_rule, gamification, mass_mailing
1) Create the independant DomainSelector widget
- Allow to build a prefix char domain
2) Replace old FieldCharDomain with a new FieldDomain which uses the
new DomainSelector widget
3) Create the independant ModelFieldSelector widget
- Allow to build a valid field chain for a specific model
(e.g 'partner_id.name' for a 'res.users')
- Used by DomainSelector widget
---
The DomainSelector widget uses a tree-like representation with
user-friendly buttons (ALL/ANY/+/-/...). Any domain can be built,
except those containing the "!" (not) operator or some operators
like "like", "child_of" (@see DomainSelector). However, if the
user enters these in the debug input, the widget can handle them.
Note: these widgets had to do unusual stuff the widget API does not
allow to handle efficiently right now but it will be adapted to the
new widget/field API in a further update.
Note2: the widgets also have possibility of other improvements like
supporting m2o input instantiation in DomainLeaf, etc.
---
This work is an adaptation of the original code made by @pga-odoo.
|
