In this commit, we extend the search view to allow the selection
of some intervals for date or datetime fields in groupby menu.
The valid intervals are day, week, month, quarter, and year.
It is also possible to add a button 'Group By' in the control panel
owned by a graph view in case it is declared 'embedded' (e.g. in a
dashboard view).
Note that have three new generic reusable widgets have been introduced
in this commit: DropdownMenu, GroupByMenu, and FiltersMenu.
It is sometimes useful to be able to customize slightly the color of a
field depending on some conditions on the current record.
For example, imagine that we want to show a VAT number field in green/red, if
it was validated or not. To do that, we can add a field with an
onchange, and simply add decoration-danger and decoration-success
attributes to the field.
We need the calendar view to be consistent in the usage of time formats
currently the week column (on the far left) is not consistent with what
we display in the meeting time slot.
It is currently not ovious that you can add and view anybody's calendar
so we need to add a placeholder.
In order to create a meeting you have to click on create which is not
explicit.
Task #1838108Closes#24675
When a line in a editable tree view has no acivable element
(readonly or toggle_bollean fields only) the currentFieldIndex
will be null after selecting the row, and when trying to edit a
field (boolean field_toggle in this example) an error will be
thrown when trying to put focus on currentWidget.
We need to check that the currentWidget is not undefined.
There was no consideration of the fact that the widget
rendering process could be asynchronous. This commit
fixes that situation so that render a node of type
<widget name="..."> is now possible.
In some cases, the calendar view sends a trivial domain, such as
["partner_id", "not in", []]
This is clearly not really useful, and it could hurt performances in
some cases (for example, if the partner_id field is a related on a large
table, and non stored).
This is clearly not a complete fix, but it is easy, safe and does not
hurt.
In some cases, the calendar view sends a trivial domain, such as
["partner_id", "not in", []]
This is clearly not really useful, and it could hurt performances in
some cases (for example, if the partner_id field is a related on a large
table, and non stored).
This is clearly not a complete fix, but it is easy, safe and does not
hurt.
Let's assume the following scenario in a Kanban view with a default
filter. The user removes the filter, and quickly adds a new one.
On a slow network, it may happen that the second reload request
returns before the first one. On odoo.com, this is easy to
reproduce on the tasks Kanban view.
Before this rev., when this occured, the result of the first
request was displayed, whereas it should have been ignored as
another request was done later on.
Recently, rev. c0809dd41 removed a protection in the reload of
Kanban views with progressbars. This protection ensured that the
manual reload of the progressbars was only done when one of the
records of the Kanban view was updated (and not when a column, or
the whole view was).
However, removing it highlighted a bug linked to the manual reload
of progressbars, which messed up the list of ids in the
environment. As a consequence, for instance, if the user archived
the records of a column, and then opendc a record in form view,
it couldn't use the pager anymore.
Besides fixing this bug, this rev. re-introduces the protection,
and refines it to prevent 2 useless RPCs when the whole Kanban
view was reloaded.
opw~1841276
opw~1841342
In the chart of account editor, which is an editable list with 2
contiguous monetary field, we could not change the first then move to
the second using the TAB key: the focus was not set on the input of the
second monetary field, and when it is, that input is destroyed and
recreated so the focus was lost
Before this fix, the user needed to hit TAB twice to move to the next
field.
After this fix, the user can navigate between fields monerary with TAB
When the focus is on a kanban card that do not have
oe_kanban_global_click or oe_kanban_global_click_edit when hitting the
ENTER key,
before this fix, the default action was to open the record of the card
after this fix, the action executed will be the action of the first
button or link of the card
if the card has the oe_kanban_global_click or
oe_kanban_global_click_edit class, the record still opens with ENTER key
The way the calendar view selected its form view was broken for two
reasons:
- any value given in the form_view_id attribute was kept as string,
which means that the string value would be sent to the server, and
this is not good.
- if no value was set, the calendar view then simply did a do_action
with the form view id set to false, which means that the default form
view is used. This is mostly ok, except when we are in the context of
an action with a form view which is not the default one. In that
case, we clearly prefer the form view from the action.
For example, before this commit, the form view in the timesheet
application (community) is not the same as the default form view on
account.analytic.line.
Note that this commit also adds a small tweak to the mock server to
better simulate errors like the web client does (in session.js).
Here is the story of the problem: back in 10.0, everything *seemed*
fine with button rendering except it was very messy duplicated codes.
The system was still not consistent:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-default btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-default btn-link
oe_link -> btn-default oe_link
btn-danger -> btn-default btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> no class
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> oe_link
btn-danger -> btn-danger
some_class -> some_class
So, outside the header, the system seemed to not process anything except
transforming the oe_highlight class. In the header, the btn-default was
always added, except if using the oe_highlight class. The style is fine
for those, except for .btn-default.btn-link and .btn-default.oe_link
where the link class has no effect (which is fine as header are not
supposed to contain links).
In 11.0, the new views were introduced alongside websitepocalypse. The
new system led to:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-default btn-primary
oe_highlight -> btn-default oe_highlight
btn-default -> btn-default
btn-link -> btn-default btn-link
oe_link -> btn-default oe_link
btn-danger -> btn-default btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> oe_highlight
btn-default -> btn-default
btn-link -> btn-link
oe_link -> oe_link
btn-danger -> btn-danger
some_class -> some_class
So, it worsened the header buttons by not processing the oe_highlight
class and adding the btn-default class in all cases. This is even
worse since in 11.0 .btn-default.btn-link do have a specific style and
thus not appear as .btn-default anymore. Those may be invisible "bugs"
though as .btn-link are not supposed to be in header and oe_highlight
is styled correctly in css. For buttons outside the header, a little
processing was added to add "btn-default" class for buttons which did
not specify a class (and oe_highlight is not processed anymore there
too).
In master, with the less2scss task, the system had to change again but
led this time to visible bugs:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
As you can see, the system is now the same for both header button and
normal buttons. The system is also better for all cases as it produce
only *one* *bootstrap* class for all cases. However, the problematic
case is the last one for header buttons: it did not receive the
btn-default class automatically. Even though this is the API for the
rest of odoo (dialogs, renderButton (old WidgetButton), ...), this is
a problem here as fixing this would require to add the 'btn-default'
class in every view which is using this case.
While waiting for a better solution, this commit is instead forcing
the btn-default class in that header case only (so only when a class
was mentioned but it did not contain any bootstrap btn type class).
So the new system gives:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
This commit also adds tests which will prevent the system to change
again without noticing it.
Closes https://github.com/odoo/odoo/pull/24443
Before this, the progressbar values were not updated (both count and progress)
after archiving all the records of a column.
Multiple things have been done here to update it.
Firstly, a optimization had been done to avoid reloading the progressbar when
updating a column ; this optimization was not correct due to this precise use
case. This will update the progressbar.
Secondly, the `aggregateValues` are reset when putting empty groups back in the
datapoint. This attribute is used to compute the counter if a `sum_field` is set
on the progressbar widget. It needs to be reset because the loop that computes
it won't iterate on empty groups.
Eventually, the mockRPC of the progressbar route was not taking the `group_by`
argument into account (probably a typo).
Rev. 374af56 changed the way 'button' nodes are rendered in basic
views (form, list, kanban). As a consequence, their 'name'
attribute wasn't transmitted to the produced html elements anymore.
However, this attribute is very convenient to debug views, and to
write selectors in tests. For instance, it broke the test added by
rev. 8d17a2a once forwardported in master.
This commit reverts 1ce5bea.
This feature has been removed in rev. odoo/odoo@e533085 but this commit
reintroduces it. It was considered as "too dangerous" for new users.
Instead of removing the feature, a confirmation request has been added to warn
the user about his potentially harmful action.
The same warning has also been added in List view when archiving records.
Task 60393
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Before this fix, when going on the graph view from the dashboard view (
using the fullscreen button on dashboard), the focus is on the search
input, hitting the tab key creates a crash.
This fix gives a default implementation of giveFocus to the
abstractrenderer so there is no crash.
When doing several grouping quickly (or if the system is slow) on the
pivot view, we may try to display data that now doesn't corresponds to
the current selected groupBys.
This commit ensures that when we load data of the pivot view, we drop
the previous data loading that are currently being carried out.
Without the fix, the added test failed with:
TypeError: Cannot read property 'length' of undefined
because the test does:
- select one level of group by
- select two levels of group by
- resolve the first level of group by
- resolve the second level of group by
Without the fix, we would try to display the data for one level of group
by when the pivot view had two levels selected.
With the fix, displaying the first level of group by was discarded once
a second one was being requested.
opw-1825892
closes#24396
When a user creates a new column in a kanban view, leave the action and
comes back, the order is not preserved. With this commit, we force a
call to resequence to ensure that the order does not change.
and keep all those filters at last. (PR#20463)
e.g. If field used in color attribute of calendar view does not have value then such sidebar filters will not have string besides filter checkbox
in such cases we should set Undefined string and put all those filters at last in filter list
Currently we can see issue in calendar of manufacturing orders in db with demo data
Related to Issue #1778360
Co-authored-by: Mohammed Shekha <msh@openerp.com>
this.call('web.Notification', 'notify', params)
Display a notification at the appropriate location, and returns the
reference id to the same widget. Note that this method does not wait
for the appendTo method to complete.
@param {Object} params
@param {string} params.title notification title
@param {string} params.message notification main message
@param {string} params.type 'notification' or 'warning'
@param {boolean} [params.sticky=false] if true, the notification will stay
visible until the user clicks on it.
@param {string} [params.className] className to add on the dom
@param {function} [params.onClose] callback when the user click on the x
or when the notification is auto close (no sticky)
@param {Array<Object>} params.buttons
@param {function} params.buttons[0].click callback on click
@param {Boolean} [params.buttons[0].primary] display the button as primary
@param {string} [params.buttons[0].text] button label
@param {string} [params.buttons[0].icon] font-awsome className or image src
@returns {Number} notification id
this.call('web.Notification', 'close', notificationId)
Here is a scenario that could happen before this commit:
1. go to a list view with more than one record, say 3
2. click on the 3rd record to open the form view
3. the pager says 3/3
4. click on edit button
5. click on discard button
6. the pager says 1/3 (but the record displayed is still the same)
It is often necessary to restore the offset for the sub records, because
the number of pages in a one2many could have changed. However, it is
not a good idea to do that for the main record, since it interferes with
the usual flow of operations.
* test_main_flows
The style of a primary/link button is given by the
'btn-primary'/'btn-link' class. The old 'oe_highlight'/'oe_link'
class should still be supported in views but not rendered in the DOM.
The commit [3079415fb17232117b0d5059a23ae89232eaf5e8] allows the read_group groupby parameter not to be contained in the fields parameter. This makes possible the simplification made here. Similar changes could certainly be applied elsewhere.
On a pivot view expand a field in column
another one in row
Then put a domain in the search view
Save the whole thing (ir.filter) as favorite
Before this commit, the ir.filter was not saved the right way when a domain was present
(Let alone its restoration)
This was because of
- the internal default groupbys of the pivot model was not updated, and what we got in the params was overwritten
by what existed before
- a slight typo in the code made the row updated with the col values
OPW 1835865
OPW 1829925
closes#24215
In the calendar view there is some mixing of moment with:
- a local date with given timezone
- a UTC date with added timezone manually applied
The setDate function of calendar model sometimes received either of the
two types, and always transforms them to UTC date with added timezone.
This cause eg. the following issues:
- in the minicalendar, if we click on a day (eg. 12) the day highlighed
will be the one of 12th at midnight with timezone applied. So with a
negative timezone the 11th would be highlighted in the mini calendar
(but the 12th would still be the day shown).
- if we change scale (week/day/month) or open calendar or use next or
previous button: we call `setDate` with a UTC+timezone moment. So each
time this is done, we get an additional timezone
eg. when opening the calendar view on the 12th at 5:00 with GMT-0200:
-> the target date is 12th at 1:00
-> if we set the day mode: target date is 11th at 23:00
-> if we set the week mode: target date is 11th at 21:00
With this change we keep target_date and highlight_date as local date so
setDate always receives a local date and jquery-ui DatePicker gets the
date in the expected format.
opw-1831368
closes#24188
In the form view, a new problem appeared since we introduced the extra device
size_class: the buttonbox was folded for large screens, even if there is
only two buttons.
The reason is that the form renderer code used a list to map size class
numbers to the number of buttons allowed to be displayed. With the
extra size class, this number was undefined, which caused an issue.
Mathieu Duckerts-Antoine