- Install the 'Maintenance' app
- Create a maintenance request, set a day and a duration of 6 hours
- Go the calendar view, month mode
- Move the maintenance request from one day to another
The duration is changed with a non-sense value.
In month mode, the hours are not represented in the calendar so it is
not possible to compute the `date_delay`. Moreover, when a record is
moved from one date to another (`_onDropRecord`) in month mode, there is
actually no point recomputing the duration; the `date_start` is enough.
Note that `date_delay` is used (at the time of writing) in 2 views and
absolutely not tested.
opw-1984637
closesodoo/odoo#33193
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Following f4fbaf1efa
which changes the label/checkbox structure into:
```
<div class="custom-control custom-checkbox">
<input type="checkbox" class="custom-control-input" id="customCheck1">
<label class="custom-control-label" for="customCheck1">...</label>
</div>
```
So, before this commit, there may have been multiple input with the same Id.
The consequence is that, when clicking on a label, the browser would take the first Id it found
which was erroneous, because all checkboxes in Favorites menu had the same Id
In reality, the use case goes as:
- open a x2m,
- search more
- Favorites > Save current search
> click on one the two checkboxes
> The dropdown closed, without checking the box
After this commit, when clicking on the checkbox in the favorites menu
the checkbox is toggled and the dropdown stays. Also, the checkboxed have now unique ids
OPW 1974587
closesodoo/odoo#33032
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Backport of 7bc53ac30e.
Assume an editable list view with a date(time) widget, click to
edit a line, focus the date field (the datepicker opens), press
ESC: there is a crash in the lib, and the datepicker remains open
forever.
This fix is twofold:
- we added a check in the lib to prevent it from crashing (it is
easily reproducible: it crashes when an opened datepicker is
removed from the DOM).
- we added an event handler of ESC keydown event to hide the
datepicker before the field is removed from the DOM.
closesodoo/odoo#32647
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
The calendar should send to server:
- for an all day event (all_day field on view): the date in UTC (ie. if
we are on 22 august 2018 on UTC+2, not send 21 august 2018 22:00)
- for a datetime event not all day: the UTC datetime corresponding to
UTC (for 03:25 with UTC+5 timezone, we send 22:25 the day before)
- for a date event: the date in UTC (ie. same as all day)
The current code was alright for datetime, but there was a missing case
if the start_date was a Date field (eg. project task calendar view uses
a date_deadline Date field) and not a Datetime field.
This changeset apply the same behavior as an all_day event to a calendar
with a start date that is a Date field.
Note: the issue happen since 11.0's 03d74f4 (26th march 2019) that
solved a similar case but for datetime (a datetime event at 8:00 with
timezone UTC+9 would be moved the previous day when drag and dropped on
the month view).
opw-1969876
opw-1971106
opw-1971019
closes#32796
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, a domain that had been written in order to be
JSON parsable, would trigger a JS crash when activated in the UI
It happens when adding custom filters through the edition of the search view with studio
This was because, Odoo developers write, in the XML of a search view
domains python style: `[('field', '=', 'value')]`
When parsing the view in JS, this doesn't get altered by `xml_to_json`
Then, the search view code evaluates it python style
This commit considers that behavior fortunate, but not really clear or conceptually correct
But, when customizing a search view with studio, the domain is written by the code, in JS
JSON parsable format `[["field", "=", "value"]]`
This should be supported too, as so many customizations may have been done before hand
After this commit, both expressions are supported by the filters menu
OPW 1957297, 1960732, 1965649 (at least)
closesodoo/odoo#32690
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since f4fbaf1efa the structure of checkboxes has been improved, now we
have something like:
```
<input type="checkbox" id="checkbox-18" class="custom-control-input">
<label for="checkbox-18" class="custom-control-label">​</label>
```
With the first input invisible (whilst before it was visible and the
clickable element).
This cause an issue in an editable list view:
- we have a boolean readonly field in a cell
- we are on focused on a line (not in the boolean field cell)
- we click on the boolean field
=> the check mark is toggled
This is because when we switch cell, we try to activate the widget of
the other cell. Before f4fbaf1efa this issue did not happen since the
browser do not generate a click event when clicking a disabled checkbox.
With this changeset, a disabled FieldBoolean is not focusable as is the
case for other fields, so we can't "activate" it.
Without the fix, the added test fails with:
[clicking disabled checkbox did not work]
opw-1958433
closes#32652
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In an editable (main) list view with modifiers depending on the
record id, add a new record. While the record isn't created yet,
the modifiers were correctly evaluated. However, they weren't
re-evaluted when the record was saved (thus getting an id), and a
reload of the view was necessary for the modifiers to be correctly
applied. With this rev. they are now correctly re-evaluated when
the record is saved.
closesodoo/odoo#32483
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Before this rev., navigating with shift-tab didn't produce the
expected result when there were readonly fields on the way. For
instance, pressing shift-tab on a field:
- to the right of a readonly field: the focus was kept in the
current field, whereas it should have been moved to the first
editable field to the left of the readonly one
- in the editable first cell of a row, with a readonly field in
the last column: the focus was moved to the previous line,
which is ok, but on the first editable cell of it, whereas it
should have been on the last editable cell.
@KangOl this commit needs to be forwardported up to saas-12.2, not
later (the code slightly changed in saas-12.3, and we did another
version of the fix).
In fullcalendar, we have in f5b7ad80f fake moments date with UTC time
that are the local time, thus when we move an event to another day, we
need to set it as:
- the selected year-month-day
- the original utc hours (real local hours) -> local hours
- the original utc minutes (real local minutes) -> local minutes
- the original utc seconds (real local seconds) -> local seconds
When it is sent to server, timezone offset will be removed so we will
transfer to server the expected datetime in UTC.
With this changeset we send server the correct time when a fullcalendar
event is "all_day" but the original event was not (eg. drag and dropping
event on the month view).
Added test without change failed with:
- 4. event moved to 27th nov 16h00 +40 hours timezone
(expected "2016-11-29 08:00:00", result: "2016-11-27 16:00:00")
- 5. expected: "event|6|11/27/2016|16:00:00"
result: "event|1|12/09/2016|08:00:00"
- 6. expected: "event|1|12/09/2016|08:00:00"
result: "event|3|12/10/2016|23:55:05"
opw-1955281
closes#32136
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When creating a record from a calendar view,
the default form view is always used when using the popup mode,
ignoring the `form_view_id` attribute of the <calendar/> tag.
After this commit, the `form_view_id` is no longer ignored.
closesodoo/odoo#32379
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Have a list view, apply a group_by and a filter with a sort parameter
Click on one record to access the form view
Have a x2m within it
Before this commit, the x2m records were loaded with a context containing
the keys orderedBy and group_by
It seems harmless at first, but even conceptually those keys should not be here
- they apply on a list of records, and not to individual ones
- they may contain field names not existing in the x2m model
Hence, when accessing another list view through an action button, the list
will try to be orderedBy or group_by with the given context
Which is plain wrong in the first place and may cause crashes
After this commit, the context of a record datapoint (representing a single record)
is stripped from the keys
Read the opw for a concrete use case
OPW 1943583
closesodoo/odoo#31706
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since f8b38f64d dictionaries "groupbys" are the same object between the
pivot model instance and the headers menu.
But this causes an issue in 12.0 since when there is no results, the
headers menu groupbys is truncated and now being the same object, the
pivot model instance is also truncated.
So succedding search that find results would possibly have lost the
groupbys which is unexpected and breaks some 12.0 tests not expecting
it.
With this changeset, the groupbys are not truncated anymore.
Without the change, the added test fails with:
Column groupby not lost after reload after empty results
expected: { "pivot_column_groupby": [ "customer" ],
"pivot_measures": [ "__count" ], "pivot_row_groupby": [] }
result: { "pivot_column_groupby": [], "pivot_measures":
[ "__count" ], "pivot_row_groupby": [] }
closes#31644
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 187c32c2 some improvements were made for conserving/restoring group
bys on the pivot view.
This introduced an issue on the column group by:
- before reload, if we set manually a column group by (+ icon in the
header) it would be saved and not lost (unless a context or filter
in the search view override it)
- after reload, the following manually set column group by are not saved
anymore on subsequent reload (the column group by at the first reload
are set back)
This behavior is not normal since the behavior (conserving or losing
column group bys) should be the same at first reload or second reload.
The issue was caused by the duplication of group bys that were not
synchronized (one on the column root header, one on the pivot model
instance).
Without the change, the added test failed with: "Column groupby not lost
after second reload" and product_id is hidding from the object
pivot_column_groupby dictionary (having only "customer").
Using _.clone on initialRowGroupBys was necessary change because without
duplication of "groupbys", the initialRowGroupBys would be changed on
expandHeader which is unexpected.
opw-1941095
closes#31407
On a pivot view with a default filter which has column and row groupbys
Remove the filter
Collapse all columns and rows
Activate another Filter from favorite which has a column groupby at least
Before this commit, the columns were not displayed in the DOM, though RPC's
and internal data were actually correct
This was because we considered the changes had been done "in place"
taking the old tree to build the new one for the columns
when really, we should have recomputed the column tree
After this commit, the columns display the group we want
OPW 1935155
closesodoo/odoo#31247
Let's assume a form view with a clickable statusbar, in readonly.
When the user clicks on a status, the change is saved directly.
When the save fails (e.g. access rights), the statusbar widget
is in an inconsistent state and must be reloaded.
This rev. reloads the whole record and re-render the form when
this happens.
Related to Issue: #1915391closes#29519
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Backport of d9fed5381a78c19ce14ddc8b9233f60d53c65453
Before this commit, when opening the calendar view with a specific locale
in the "week" view
the days were translated but the date format was wrong and fell back to english
This was because the translated terms were passed explicitly, but the locale did not
get passed
After this commit, we do what it takes to pass the locale to fullcalendar
and the dates are formatted with the right pattern
Also, there may be a bug in fullcalendar, because just passing the locale in the options
won't work, it should be instanciated first in fullcalendar's "locales cache"
OPW 1922092
OPW 1934127
closesodoo/odoo#30909
In 11.0 f8b38f64d improved the column group by managment when reloading
several times by having the same "groupbys" dictionaries between the
pivot model instance and the header menu.
This has been reverted in 12.0 (with c6e7adfb95) because the following
pivot tests failed with the change:
- 'rendering of pivot view with comparison'
- 'export data in excel with comparison'
The failure is because now that the "groupbys" dictionaries are the same
object, the truncated dictionary of a header truncate the one of the
model instance.
So if we search something that has no results, then something with
results, the groupbys could be lost.
This behavior has no reason to be and is changed in 11.0 with #31644,
this commit is the forward-port of f8b38f64d and #31644.
closes#31627
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit:
Editing a translatable field -> clicking on a translation
warning ->
come back through breadcrumb do not preserve translation
warning.
After this commit:
Editing a translatable field -> clicking on a translation
warning ->
come back through breadcrumb preserves translation warning.
Technical note: alertFields is now an object and an attribute
of the form renderer
that stores translation alerts per record. The translation
alerts
created for a given record are maintained unless
they are closed manually or the renderer is destroyed.
Issue-ID: 1877480
Co-authored-by: Mohammed Shekha <msh@openerp.com>
closesodoo/odoo#29377
Open a pivot view with default filters automatically activating
Disable those filters
Change the groupBys on the rows and cols of the pivot
Save your result as a favorite filter
Before this commit, the filter did not contain the context information for columns groupby
Also, the search view did not exploit the context of the new filter as it should be
After this commit, the flow works as expected
OPW 1913732
closesodoo/odoo#29415
related to: #28446
On a pure list view, click on a column to sort the records by that field.
Save the filter as favorite
Reload, now apply the filter
Before this commit, there were two issues:
1. The order of the list was never propagated to search view, which couldn't save
the filter with its attribute "sort"
2. There was no mechanism to load the attribute sort from a loading Filter
After this commit, those two issues are corrected
Unfortunately, complex search view flows are not testable in v11.0
OPW 1906968
closesodoo/odoo#28766
Before this rev., the following scenario didn't work:
Open manufacturing order and click on Produce button (note that
bom product should have Serial number enabled) then add quantity
in Done field in o2m and press Record Production button in wizard,
it will produce UserError and after then if you change Lot number
field in wizard's o2m then the many2one value doesn't get selected.
This occured because the renderer wasn't updated after the RPC fail
and thus still got an outdated version of the state.
The issue raised after commit: 02eef78bbd which was done to remove
useless rpc call, it's OK to remove rpc call but let's keep
updating renderer.
Related to task ID: #1852715
Co-authored-by: Tejas Shahu <tsh@odoo.com>
On a form view (of model A), define a many2one (model B) with a [form|tree]_view_ref context key
In that view, have a x2m field (model C) with a different [form|tree]_view_ref context key
Before this commit, the second load_views (i.e. on the model C) crashed because
the wrong context key was sent to the server, which returned the view to which the _view_ref points
i.e. the view of the model B
After this commit, we clean the context of subviews loading, because those keys are only useful for the python
and one shot. Hence, there is no crash
OPW 1903780
closesodoo/odoo#28260
When creating a SO line and clicking on search more for product_id
Before this commit, every user had the button "Create" to create a product.product
After this commit, only user in groups that actually can create a product have the button
OPW 1910371
closesodoo/odoo#28924
Have an editable list that begins with a date/time field
create a line.
The first field is focused and the datetimepicker is popped up
Now, stroke ESC key
Before this commit, there was a traceback because the datetimepicker received an erroneous
BLUR/INPUT event
After this commit, there is no traceback as we detroy the widgets of the line
(including the datetimepicker) before removing the row from the DOM
OPW 1932409
closesodoo/odoo#31342
This rev. fixes 3 issues with async (field) widgets in the kanban
view.
From rev. 5faec34a, widget'$el doesn't exist before start. This
means that for async widgets, one can't interact with the widget's
$el right after calling appentTo. In KanbanRecord, this is exactly
what we did for both field widgets (<field name=.../>) and widgets
(<widget name=.../>).
Moreover, when the kanban view was updated (e.g. when the user
refined the search using the search view), and the rendering was
async (because of the presence of an async widget), the renderer
didn't wait at all for the widget to be ready before updating the
view. This caused flickering, mostly, but also a crash in
accounting with the JournalDashboardGraph widget (because
on_attach_callabck was called before the widget was ready). To
reproduce this particular issue, go to accounting, add a filter
that doesn't match any record and save it as favorite (default),
press F5 (no record is displayed), remove the filter.
opw-1925079
opw-1925479
Fixes#30087Closes#31254closesodoo/odoo#31327
The commit 6d3ada1
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#31025
On a view, define a timerange for fetching data
Save as favorite
Before this commit, the time range description were not transmitted as
strings for the creation of the filter
So, when loading the filter back, there was no description for column headers
resulting in displaying "Object [Object]" as their title
After this commit, we save in the context of the filter the description of the title
OPW 1930582
closesodoo/odoo#30992
When editing a record, if it cannot be saved (b.e. due to required
fields) and the user clicks on save, then on discard
Before this fix, the window did nothing (seems like it is unresponsive)
After this fix, the user is able to discard the form.
task-id: 1937142
closesodoo/odoo#30871
Nicolas Martinelli