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).
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>
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>
On a form view:
- we open a modal form view
- in this modal we open a modal form view
- we close that second modal
=> the modal is closed and the first one is still opened, but on mobile
we can't scroll to above or below the modal.
This is because bootstrap remove .modal-open class on body when we close
the second modal, but this class is necessary to scroll (this is not
much an issue on desktop since scroll is often not necessary).
We already had a fix that was weakened in 02a063fd73.
With this changeset, we keep .modal-open as long as a modal is opened.
Without the change, added test failed with:
10. Modal is said opened (expected: true, result: false)
opw-1948423
closes#32106
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, there were a crash if you tried to add an optionnal
product in a new sale order without saving it.
Apply same logic as in the ListRenderer: buttons with type="object" are
disabled for no saved yet records, as calling the python method with no
id would make no sense.
To avoid to expose this logic inside all Kanban views, we define a
specific KanbanRecord Class for the One2many case.
This could be refactored to prevent from duplicating this logic in list
and kanban views.
Original Task ID: 1945006
closesodoo/odoo#31695
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The issue is manifesting for example in the Contact kanban view where the
company image should be displayed in small. Before this fix, the person image
was displayed twice instead.
Following PR #30881 and commit: f78b7a76d6
The fix introduced by the above commit highlighted another issue with the
method: if the `model` and `id` given in parameter are different than the
current record, the method returned the url for the current record instead of
the requested record.
To fix the issue, we return the `raw_value` only if the requested record is the
current record. Otherwise, we return the manually built url.
PR: #31842
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The widget handle was displayed on x2m fields in form views, even when
the field was readonly, which makes no sense.
It is now correctly hidden.
Fixes#30580
opw-1937833
closesodoo/odoo#31743
Signed-off-by: Aaron Bohy (aab) <aab@odoo.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>
To reproduce:
1. go on list view
2. open record in form view
3. come back on list view
4. switch to kanban
5. open record in form view
6. click on breadcrumb
Before this rev. we were back on the list view, and not the kanban view.
This is due to the fact that the breadcrumb was not updated when switching view,
(if a controller was already existing) so the form view control panel breadcrumb
was still referencing the wrong (list) controller.
This bug appeared with the control panel refactoring, which is now managed by
the view itself (and not the action manager as previously).
Task 1932646
closesodoo/odoo#31598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
In the recent control panel refactoring, selecting '(no result)' (when using the
autocomplete on a many2one for example) was no correctly handled and was leading
to a traceback.
It is now correctly handled and the search bar is correctly re-rendered.
Task 1936745
closesodoo/odoo#31438
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
Let's assume a many2one field with a lot of possible values. The
user clicks on 'Search More...'. In the opened dialog, only 160
records are available (their ids have been obtained with a
name_search, with the optional text the user could have typed in
the many2one input).
Before 4cd379cf, that extra domain on ids was removed automatically
as soon as the user interacted with the search view in the dialog.
This was especially useful when there were more than 160 records.
However, this was rather an happy coincidence than a designed
feature.
From 4cd379cf, the ids selection was added to the initial domain
of the list, so they couldn't be removed from the domain
afterwards. The user was thus stucked with its preselected 160
records.
This rev. doesn't restore the former behavior, but rather improves
the current one, as follows:
- when there is no text in the many2one input (i.e. no value to
filter on), we bypass the name_search, s.t. all records are
available in the dialog
- when there is some text in the input, we perform a name_search (as
before) to get a list of record ids, and we add a special filter
to the search view in the dialog (the filter on those ids), s.t.
the user can remove it if he wants to access the remaining records.
- finally, the limit is now set to 320, to mitigate the problem
Issue reported on the saas-12.1 migration pad.
closesodoo/odoo#31232
The widget has been moved in rev. odoo/odoo@15f3bbe but was not very generic.
In particular, there was a traceback when clicking on the button if the field
had no value (the button was displayed for readonly fields in create mode).
The button is now only appended in readonly mode (a `button` inside an `input`
or a `textarea` is not very DOM friendly) if the field has a value.
Task 1941996
closesodoo/odoo#31635
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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
1) Remove the total record tooltip from kanban group.
2) Remove progressbar help from kanban view.
3) Improvements in testcase since we have removed total record tooltip.
When evaluating js tests using the browser_js method, they are
considered a success when 'ok' is found in the console log and a failure
if 'error' is found instead.
This is not very robust and recently failed with this commit : 7410de111f
It adds a filter named 'Error' in a view, when the 'click_all' test
clicks on this filter, a message with the name of the filter is written
in the console, wrongly leading to a test failure.
With this commit, the browser_js method expects a log message in the
browser console with the explicit text "test successful".
On the other hand, any error in the console log will lead to a test
failure but a test can be forced to fail with the explicit error message
in the browser console "test failed".
As a bonus, the python logger should now also log browser js trace messages.
closesodoo/odoo#31158
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>
Active currencies are given in session_info, in the page source.
When the user activated a new currency, he had to reload the page
to make the browser aware of that new currency (without reloading,
there was no currency symbol displayed next to the amounts).
This rev. forces a reload of the currencies each time a currency is
edited.
Task #1838654closesodoo/odoo#31192
Before this rev., it was possible to specify default values for
categories (fields with attribute select="one") in the context
(e.g. searchpanel_default_fieldname: 5). It is now possible to
specify default values for filters (select="multi") as well
(e.g. searchpanel_default_fieldname: [1,2]).
closesodoo/odoo#31107
Christophe Simonis