Tests have been adapted accross all affected modules to support the new
"comparison" menu component.
Task ID: 2245719
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
This commit adds the support of nolabel attribute on fields
in list view. This attribute can be used to empty the column header.
Example of use:
<record id="module_example_tree_view" model="ir.ui.view">
<field name="name">module.example.tree.opportunity</field>
<field name="model">module.example</field>
<field name="arch" type="xml">
<tree>
<field name="name"/>
<field name="tag_ids" widget="many2many_tags" nolabel="1"/>
</tree>
</field>
</record>
Result:
This will create a tree view with 2 columns.
The second column will have an empty header and won't be sortable.
Name |
--------+--------------
Record1 | [tag1]
Record2 | [tag1][tag2]
Record3 | [tag2]
closesodoo/odoo#52302
Task: 2269315
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Adjacent buttons in the arch are now displayed in a single column
in list views (main and x2many views). As soon as there is a node
in-between (even if it is invisible="1"), the rule doesn't apply
anymore and buttons placed before/after that node are rendered in
a separated column.
Task 2261774
closesodoo/odoo#51970
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, owl renderers were mounted twice.
This commit makes owl renderers mounted just once as it should be
X-original-commit: 9234aa5c5c7de2f7af23071a3ff76adf93e9cee7
1) Clicks on a section value are now bound to the entire header, meaning
that the sole purpose of the carets is purely esthetic.
2) Search panel categories will now only be folded if they are being
clicked on while already selected.
Classes that were no longer useful have been removed and tests have been
updated accordingly.
Task 2264700
closesodoo/odoo#51555
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this commit, hierarchy carets in the search panel have been moved to
the left side of the labels. To achieve a consistent and correct
alignment, some DOM elements have been added/moved and the related SCSS
sheets have been adapted.
Carets on filter sections of the search panel have also been removed.
Task 2258508
Due to commit odoo/odoo@0150141756
when the widget calendar is initialized with date type record for
date_start and without all_day mapping events aren't shown on day/week
views. This is because all day zone isn't visible when all_day mapping
is not set.
After this commit, we show the all day zone also when the date_start is
a date type.
Steps to reproduce:
* Go to Project App
* Select/Create a project
* Select/Add a task with a deadline
* Return to project
* Select calendar view
* Select week view (of the deadline) => BUG
closesodoo/odoo#51818
X-original-commit: 1d83f4184e1b82db4dd4db54d98e509432340996
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
PURPOSE
Currently, reporting views such as the bar and line charts have
their x-axis sorted either alphabetically or according to a
sequence. When reporting, the user would be interested in sorting
the x-axis values by their measure.
SPECIFICATIONS
Add 'ascending' and 'descending' options in graph view for bar and
line charts
Task 2070103
closesodoo/odoo#49970
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
This commit makes easier to select records in list views, by
extending the clickable area to the whole cell, instead of the
inside of the checkbox.
closesodoo/odoo#51156
Task: 2247387
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Have two x2many lists in a group in a form view. Increase the
width of a column in the first table. Before this commit, the
second table was also expanded.
task-2189968
closesodoo/odoo#47652
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Issue
- Install Projects
- All Tasks > Form View
- Edit the view
- Set statusbar clickable to '0'
Still clickable
Cause
In relational_field.js we do
`!!'0'` which returns true
like `!!'anythingelse'`
Solution
Add a '+' which will convert
the value into an integer
for a better conversion.
OPW-2235311
closesodoo/odoo#51083
X-original-commit: 53cc68fce32f46a0b4bc83a1e73a5d13a60fc995
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Before this commit: A problem occurs with kanban views that are not
groupable (i.e. for which searchMenuTypes does not contain 'groupBy'):
if the action has a default groupby (set in Studio for instance) then
it is still applied and causes crashes. That happens in the documents
kanban view for instance.
More generally, if a view is not groupable, some information on groupbys
can appear in the interface (in a facet) while not used/useful
for the view.
After this commit:
- if a kanban view is not groupable, a default groupby will never be
applied.
- if a view is not groupable, we ensures that
- the search query generated in the control panel has
groupBy = [],
- groupbys cannot be represented in a facet.
closesodoo/odoo#51041
X-original-commit: 91c80291e90127792623476d8997fd2a67569170
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
before this commit,
tabbing into the date or datetime field input it has only focus, value is not
selected.
after this commit,
navigate through a view in edit mode with the TAB key, when focus comes into
date/dateetime field input then input is focused and value of date/datetime
field is also get selected.
task-2246593
closesodoo/odoo#51062
X-original-commit: 962e4e18b559d90aa3456c77035659ac8017501d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Before this commit, it wasn't possible to multi-edit boolean
fields in list views. Actually, it didn't work for fields rendered
by Owl components. It only impacted boolean fields because it was
the only editable field widget that had already been converted in
Owl.
It didn't work because of three issues:
1) there is some sort of an hack in basic renderers: we set the
attribute '__node' on the field widgets, and this attribute is
used for instance by the controller, when it has to handle a
multi-edition. It tries to read it from the event's target
(typically the field widget). However, with owl components,
'__node' was set on the FieldWrapper (wrapping the actual
Field Component).
2) the original target (the Owl Component which triggered the
event) was lost when the event went through the compatibility
layer (for owl Component embedded in legacy widgets).
3) the multi-edition confirm dialog didn't handle Owl field
components.
Task 2254717
closesodoo/odoo#51044
X-original-commit: 36d23cfcdef3cea3539004ee5bb4479b859b8137
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
... when there is no data and user clicks anywhere in the no content
helper.
Task 2239617
Co-authored-by: Jinal Patel <jip@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
This commit introduces several changes in the search panel with
respect to record counts:
- the record counts are now also available for
the fields with select="one" attribute
(if not disabled explicitely).
- the record counts are better computed using the idea that
selected values within a group should not impact the counts
for the group values but only the counts for the other
group values.
On the way we have changed two keys in the values returned
by the server:
- 'count' becomes '__count'.
It has been done to avoid a possible clash in case a model would
have a field named 'count' and that the field values would be
wanted for some reason.
- 'name' (multi case) becomes 'display_name'.
It has been done in order to make the select one and multi cases
more similar and factorize some code.
TASK-ID: 2166814
Co-authored-by: Raphaël Collet <rco@openerp.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Alexis Lacroix <laa@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
In the search panel, if a select multi was grouped by a field that can
take the value 'false' (like a char field), that value would be confused
with the value false and the group 'false' would never be
displayed (its values would be put in the group false).
This commit avoids that situation by using JSON.stringify instead of
the implicit stringification done when using a value as an object key.
closesodoo/odoo#50647
X-original-commit: 5b19e6c13b636d108e8aa1a09f01124fdb38a577
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If set, this value will be displayed as column name in list views.
This attribute could be used in the future in form view for the
same purpose.
Part of task 2195254
In list views, one can specify decoration-XXX attributes on the
arch root node. Those decorations are evaluated for each record,
and the corresponding style is applied on rows for which the
condition is true.
This commit allows to specify those decoration-XXX attributes on
field nodes as well. In this case, when the condition is met by a
record, only the field on which the attribute is set will be
impacted.
Part of task 2195254
Buttons with icon and string attributes now have both their icon
and string displayed, whereas before only the icon was displayed
(the string was available as title).
We also force class btn-link to style buttons with icon, except if
another btn-xxx class is explicitely provided.
Part of task 2195254
In the pivot view, groups comming from many read_group are assemble
to create the header hierarchies and the table.
Groups returned by the read_group may be already sorted by the server
using the order set on the model for instance and that order should
be reflected in the header hierarchies (and in the table).
It is important to keep that order since it might not be possible
to recreate it in the interface. Even if possible it might not be a
good idea for performance reasons.
Before this commit:
The groups are added in a JS object, whose keys are the group ids
(when grouping on a many2one at least). Then, to generate the table,
we iterate over the keys of that object, but those keys are sorted
according to the numerical order (not the insertion order),
because keys are kind of numeric.
See https://stackoverflow.com/questions/5525795/does-javascript-guarantee-object-property-order.
After this commit:
Instead of a JS object, we use a Map for which the insertion order
is used (official spec).
Task ID: 2243416
closesodoo/odoo#50551
X-original-commit: 1a9a85c8b8d0f47c3c6f3878cd6d9401ddc3ad75
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when a list contained owl field components,
the mounted hook was called twice on those components. This may
cause tricky issues like handlers being bound twice, and memory
leaks.
closesodoo/odoo#50127
X-original-commit: 206dd91e78f7896fc6b01020507657e61771787f
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, some elements in the control panel were not properly encapsulated
in layout-related parent elements and this caused some inconsistencies if some of
the control panel components were not displayed. For example: if the breadrumbs
were missing, the search bar went to the left side instead of the right.
Now, all components are in a grid-like structure (in desktop mode) and should not
overstep their given boundaries. The layout in mobile remains unchanged since the
top part behaves quite differently.
closesodoo/odoo#50057
X-original-commit: 533db5991a5bb871198485cd71a63f75a8c6becf
Related: odoo/enterprise#10148
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, when re-activating a previously active notebook tab, the form
renderer would assume that a tab was actually active. However this does not happen
if no tab is visible or defined and it results in a crash instead.
Now, if no active tab is found, a default active tab (0 = first) is set. This only
helps to prevent the crash and does not affect the current behaviour.
closesodoo/odoo#50006
X-original-commit: 73e0c0a1395ebd0e2b4ac7f857c863a0358c5e17
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Have a list view with an Owl field component (e.g. widget="badge"),
visible. Open the optional field dropdown and make another field
visible.
Before this commit, the '_onToggleOptionalColumn' handler was
executed twice, because two click events where triggered: one on
the label, and one on its associated input (because of the for
attribute, see [1]).
As a consequence, the new field was added, and directly removed
from the view. This could even cause subsequent crashes.
The difference between an Owl component and a legacy widget is
that the Owl component is async (more than a nextTick) as we wait
for the nextAnimationFrame to render. When the rendering is fast
enough (e.g. without Owl components), the click event isn't remap
to the input yet (because we empty the list HTML node), so the
handler is executed only once.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label
Issue reported on task 2204306
closesodoo/odoo#49920
X-original-commit: b02d347e8770835ad28a6487071930a904bce101
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
For testing, we use helpers functions like testUtils.dragAndDrop().
Due to the commit odoo/odoo@de924f41ee
these methods were wrapped by a deprecated function to add a deprecation
warning in the console when these methods are used.
After this commit, the deprecated method will properly propagate the
returned value of the original function. And so if the returned value
is a Promise now we can await this Promise.
This should fix some false positives on runbot in saas-13.3 (e.g. FullCalendar).
closesodoo/odoo#49611
X-original-commit: 33bfe175bf1ba7824a1bef27fd7fa0898dbe8cb3
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit fixes the kanban view to render components.
Before this commit, when rendering a component an error was thrown.
closesodoo/odoo#49525
X-original-commit: 29c18b53af26752079a49e4ece2419f62f680b5d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Let's assume an editable="bottom" list view with handle widget and a
required field. Moreover, there are less than 4 records in the list,
so there are empty lines at the bottom of the list s.t. there are
at least 4 rows.
Click to add a row: a new row (in edition) is added at the end of
the list (instead of an empty row). Do not fill the required field,
but instead move another row after the new one (which is still in
edition). Then click on discard.
Before this commit, the discarded row was replaced by an empty one
(s.t. there are always at least 4 rows in the table), but that
empty row wasn't added in the bottom of the list.
task-2209076
closesodoo/odoo#49251
X-original-commit: 22f43536cb78e07aaab3fd806f3c6c5f068824f3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
After cb76a0022, three more Qunit tests were found to fail randomly.
closesodoo/odoo#49190
X-original-commit: 9809c53e65059d53a9f115ab29ef02583f84bdb5
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Following 889dd9245, there is still a qunit test that randomly crash.
closesodoo/odoo#48977
X-original-commit: cb76a00226cf22d1ed659d736a36fa9b92e0a512
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In a form view, nodes with classname "oe_read_only" (resp.
"oe_edit_only") are only visible in readonly (resp. edit) mode.
Moreover, fields inside a group automatically have an associated
label.
Before this commit, when one of these classnames was set on a
field node inside a group, the effect wasn't applied on its label,
so the label was always visible, even if the field was hidden.
Bug reported in PR odoo/odoo#48699closesodoo/odoo#48968
X-original-commit: 705f434f0f18a0e4d2fdb0f86d3e350d190b2a30
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The "Views > CalendarView > drag and drop on month mode with all_day
mapping" test would fail regulary with "Found 2 elements to click on,
instead of 1" because the drag and drop would be ongoing and the event
would sometimes appear two times in the DOM when we try to click on the
drag and dropped event.
closes#48928closesodoo/odoo#48937
X-original-commit: 9bc0b11b2e255852c1376fe6fa87722186681a73
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Add a new group allowing administrators to remove the ability for
users to bulk-export data from the database. It's pretty minor as
technically the user can still access the underlying object through
the basic methods but it's still a bit of a roadblock.
Users can export by default.
Task 2170900
closesodoo/odoo#45400
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
After this commit, in the graph view, when the user clicks on parts
of the bar and pie charts, it opens the list view of the concerned
records (like what was already done in the pivot view).
This is the default behavior, but it can be deactivated by setting
the attribute 'disable_linking' to true in the view.
Task 2198461
closesodoo/odoo#47796
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, when the duration of an event is "24H * n". The event
is set as allDay. This is strange to have a event that start a 8H and end
at 8H of next days and the event is in the allDay slot.
After this commit, we don't change the allDay flag anymore.
Steps to reproduce:
* Open calendar in week view
* Create a event from 8 -> 16
* Then resize the end of this event from 16 -> 8 of the next day (BUG)
Task ID: 2183249
Before this commit, it was possible to create/move an event in the "all
day" slot of FullCalendar even when the mapping field wasn't set.
With this commit, when the "all day" mapping is not present, the "all
day" slot of FullCalendar becomes hidden.
Ref:
https://fullcalendar.io/docs/allDaySlot
Task ID: 2183249
Due to previous commit, in month view, the flag marking events as "all
day" is no more present and so some logic is not applied anymore. This
results into the wrong end-date.
With this commit we avoid to change the end date of an event in
FullCalendar.
Note that it changes the behavior on drag-and-dropped event in month
view:
* Before both the last and this commit, an event if 1H will become an
"all day" event when it's dropped into another cell.
* After them, the time will be the same as the original event and only
the date will change.
Also, one test was already added in commit odoo/odoo@7af13089df
to check that, in month view, when we move a non-"all day" event to
another day, it can't change into a all day event.
This commit adds a second test to cover the case when the "all day"
mapping is present.
Task ID: 2183249
Before this commit, events were sorted by ID in month view.
Event A occurring after event B would be placed on top of B instead
of below.
Steps to reproduce:
* Go in the calendar app
* Insert a event at 12:00
* Insert a event at 8:00
* Insert a event at 14:00
* Go in view month the events are not sorted (BUG)
In month view, events are forced to be "allday", so the sequence used
can't be based on its time but only on its ID.
To fix this, this commit doesn't force the "allday" flag anymore.
Task ID: 2183249
In `calendar_tests.js`, the tests about creating an event with timezone in
week mode only triggers 7 asserts but they were design to trigger 8 of
them.
After analysis, it looks like in the commit odoo/odoo@369c20a99b
the FullCalendar's UI was redesigned and some CSS rules might have add
some margin preventing a MouseEvent from being triggered correctly,
resulting in misadapted tests.
This commit restores the original behavior by adding some pixels to
these offsets, allowing the events to be correctly dispatched and
adapting again the tests.
Task ID: 2092550
This commit updates the FullCalendar library from v3 to v4.
The purpose of this update for us is to add a proper support of the
drag-and-drop of events on mobile.
But also to fix scrolling issues present mainly on smaller screens. In
those configurations multi/inner-scrolls were present resulting into
either the inability to properly scroll the desired content or even
blocking alltogether the scroll.
As a nice-to-have feature, the version 4 removes its dependency on the
jQuery library, allowing a faster loading of a bigger set of events.
Last but not least, this version also reduces its dependency on the
Moment.js library (but still keeps a binding to it for compatibility
purpose).
This commit focus only on the update of the library itself and the
adaptation of the related code to keep it working. Further
enhancements/fixes will be done later on.
To do so it modifies the following points:
* Update the library in itself (js, css...).
* Convert all FullCalendar's method calls to the new syntax (e.g.
`$calendar.fullCalendar('destroy')` becomes `calendar.destroy()`).
* Add a utility method to convert v4 events into the old v3 event
structure to ease the transition from one version to the other.
* Wrap all event's custom fields into a new event's
`extendedProps` object (as its the new way of storing them instead of
directly as a prop. of the event).
* Adapt `slotLabelFormat` and `weekNumberCalculation`.
* Use the view's new names:
** `agendaDay` -> `timeGridDay`
** `agendaWeek` -> `timeGridWeek`
** `month` -> `dayGridMonth`
* Use the option's new names:
** `viewRender` -> `datesRender`
** `eventMouseover` -> `eventMouseEnter`
** `eventMouseout` -> `eventMouseLeave`
** `isRTL` -> `dir`
** `selectHelper` -> `selectMirror`
** `weekNumberTitle` -> `weekLabel`
Ref:
https://fullcalendar.io/docs/upgrading-from-v3
Task ID: 2092550
* account
This commit adds a new field registry for component fields.
This field registry is used to only register the new field components
and the other one should register the legacy fields.
Those two registries will be used together while all legacy fields are
not converted to owl component.
As the legacy registry now throws an error when adding a component
field the existing component fields (account.ShowGroupedList and
account.ShowResequenceRenderer) are moved into the new registry.
This commit also refactors some field managers (form renderer, list
editable renderer, calendar popover) to use the new registry and thus
support the component fields.
task id: 2193996
... when toggling an optional field.
This bug wasn't really important until now, but with the new
selection mechanism, it could lead to weird situations (e.g. the
selection box says that all records are selected, but the thead
checkbox isn't checked).
Part of task 2185145
We don't change the multi edit mechanism for now: it still only
applies to the selected records, limited to the current page.
However, we add the information in the confirm dialog to make it
clear for the user.
Part of task 2185145
This commit allows the user to apply actions to all records
matching the current domain in list views. It also ensures that
the user is aware of the set of records actually selected.
The number of selected records is now displayed in the control
panel, and the user can, with an additional click, select all
records matching the current domain instead of the ones of the
current page.
Task 2185145
Purpose Of the task is, we need a visual cue on those fields to let
the user know that their value is company-specific.
So, in this commit On company depedent field we added a building
icon with title 'Values set here are company-specific' next to the
label in the form view.
closes odoo/odoo#47178
Taskid: 2001748
Closes: #47178
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
We have an editable list with 4 fields:
- fieldA (say boolean)
- fieldB with readonly modifier, readonly iff fieldA is true
- fieldC with readonly modifier, readonly iff fieldA is false
- fieldD
Add a new row to the list: fieldA being false by default, fieldC
is readonly whereas fieldB isn't.
Change the value of fieldA: fieldB becomes readonly, and fieldC is
now editable.
From that point, before this commit, clicking on fieldC activated
fieldD (instead of fieldC).
The bug occurred since 3fd7b20, which added a delay between
the moment fields are re-rendered (and inserted at the end of
allFieldWidgets) and the moment there previous instances are
destroyed (and the new ones take their place in the list). So when
several fields were re-rendered at the same time, the order in
allFieldWidgets could not match the actual column order anymore,
and cause issues like the one described above.
Part of task 2210323
closesodoo/odoo#48039
X-original-commit: 89b9717c08e148ad94db17d8746faa2312b6a07a
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
