Calendar tests did not go into US for a timezone problem, making it more difficult to correct errors.
To do: pass all the tests js in US (with simplification for the calculations of the times)
Before this commit, buttons in form view with the confirm attributes had
a peculiar behaviour:
- < saas-16: they saved the record as soon as you clicked on them, so
the warning was basically ignored
- in saas-16+ (the new views): the button did not save the record before
calling the method, at all.
This can be a problem, obviously. Also, it does not seem consistent to
have a different behaviour when the user clicks on OK in the confirm
dialog, compared to a button without the confirm attribute.
So, with this commit, we just make sure that such buttons save the
record before calling the method, just like other buttons.
1- When viewing for example journal items.
2- Now activate a filter that would display no record
Before this commit, the column aggregates of case 2 were the same as case 1.
After this commit, we recompute the aggregate, which ever case we are in.
OPW 777660
closes#20452
A list view can display the sum of all values for one field, using the
'sum' attribute. Before this commit, this sum was not updated whenever
a field was changed (but it worked when adding a line).
If the user change a filtered field, the record is not always displayed.
Wrong domain construction. The automatic filter must be use to filter and
remove items from the view for the unselected and not display the selected.
With this commit, we allow an onchange coming from a field to modify the
same field. This was not working for field widgets derived from an
input field.
For instance, open a list view with enough records so that there is
a scrollbar, scroll, open a record of the bottom of the list and go
back using the breadcrumbs: the scroll position should be restored.
Before this rev., it wasn't the case: the scroll position was reset
to the top of the list (i.e. to 0).
This was due to the form renderer which manually triggered the event
DOM_updated on the main bus to ensure that textareas were correctly
autoresized. However, this wasn't done at the right place, and it
impacted the way scroll positions of views were saved/restored.
Indeed, this was only necessary when switching from readonly to edit
mode, i.e. when the form view was actually already in the DOM, but
not at each rendering as they may be performed outside the DOM (and
in this case, the DOM_updated event is triggered by the view_manager
when the view is really appended to the DOM).
Note that this whole scroll mechanism relying on the DOM_updated
event will probably change soon in master, with the refactoring of
the upper part of the webclient.
With the new views, we mainly focused on making them work. But we also
need to be able to handle unusual cases, such as some RPC failing. An
example of such a problem was the following:
- a form view with a one2many with an onchange
- edit mode, change a field in the one2many, click elsewhere
- the onchange triggers, calls the server
- it may happen that the server fails with a ValidationError
- the onchange deferred fails, the line in the one2many is restored to
the value known by the list renderer, which is the previous value (but
the new value was applied to the model)
- we now have a 'corrupted' state: clicking on save will send the
invalid value, even though the UI displays the previous one.
We solve this problem in this commit by making sure that the onchange
deferred returned by the _performOnchange always succeed (or stays
pending). If the rpc fails, the deferred will succeed with an empty
dictionary. This means that the list renderer will be updated with the
value from the model.
Note that it may not be intuitive that a failure in the onchange is not
seen as an error from the perspective of the _performOnChange, but I
think that it still makes sense:
- the validation/network errors are not really a concern of the UI. The
UI just display the values entered by the user.
- if an onchange fails (for example, because of a coding error), we do
not really want to prevent the user from working.
Also, when the onchange is performed, the initial change was already
applied to the local data. Rollbacking them would be a more difficult
task.
Note that we also improve the mock server in this commit, to allow
mocking failures.
Opening a record in a calendar view always showed the default form view when it is not a popup.
Example in CRM: opening an opportunity will always show a lead view.
The fix aims to use the "get_formview_id" method to find the right id of the view that must be shown instead
of using a default id.
opw-774272
Opening a record in a calendar view always showed the default form view when it is not a popup.
Example in CRM: opening an opportunity will always show a lead view.
The fix aims to use the "get_formview_id" method to find the right id of the view that must be shown instead
of using a default id.
opw-774272
Before this commit, two variables were used to store the current
position in a list view: currentCol and currentRow. This made it
difficult to handle incremental moves (eg: tab, shift+tab) inside a
row, since we have to ignore all buttons. Previously, this was done by
converting 'currentCol' to 'currentFieldIndex', but the conversion
between the two variables was incorrect and does not appear to be
that easy to fix. As an example, it was not possible to TAB-navigate to
the last column of the components list when creating a BoM.
This commit removes all mentions of 'currentCol' and uses
'currentFieldIndex' instead, removing the need for conversions. The TAB
navigation code is simpler as a result, and should now be correct.
The sum is already used in views for
<field name="foo" sum="Total" />
Where "Total" is translatable and extracted in source terms export.
The progress bar kanban widget expect a field name (untranslatable).
Avoid to translate a field name by changing the attribute
When a record was added in a kanban thanks to the quick create, column
tooltip and column progressbar were not updating the values they showed.
Now, adding/deleting records updates the whole column as the update
operations.
Thanks to @kig-odoo for the test.
Note: to backport (partially)
When using quick create to create a kanban record, if this record was
then updated thanks to a field widget, the view crashed. This was
because it tried to update the whole column but the newly created
record was not properly attached to it in the model.
Thanks to @sja-odoo for the test.
Note: to backport (partially)
Kanban records with 'global click' feature activated should open
the record in a form view when the corresponding card is clicked.
Before this rev., it wasn't working if the user clicked on a tag
of the kanban record, because of an unused click handler defined
on the Many2ManyTags widget (preventing the global click feature
from actually performing the global click).
This rev. removes that handler in the KanbanFieldMany2ManyTags.
This reverts commit b6ef149b as it seems that we don't want this
feature ultimately (was confusing for users trying to open the
record, but it filtered instead).
Note that opening the record by clicking on a tag still doesn't
work, but this is fixed by the next commit.
Before this commit, pressing tab then enter was generating a traceback because
the event creation and modal deletion was done twice.
This commit adds a protection to be sure that we are doing only one event
creation.
This commit introduces a new way to hide a column in a x2m list view.
The attribute 'tree_invisible' can be add in the field attrs in the x2m
view definition. This attribute can use the 'parent' key to make a reference
to the parent record (e.g. 'parent.id').
This reverts commit b94939377a.
The commit was breaking most of the backend checkboxes trying to fix a
frontend one.
On top of the revert, this commit adds frontend-only style to fix the
frontend checkboxes.
Before this fix, trying to create a column in a kanban view where there
were progressbars was opening a traceback. This was because the newly
create column is made from data which are guessed in the client (no RPC
is done), so this guess had to be adapted to progressbars.
- Kanban colors and tag colors are now the same
- Tag color 0 (default) is now back to be the invisible kanban one
- Same colorpicker for kanban and tags
- Define correct number of colors (12 not 13)
- Color 0 should be a neutral one (gray)
- ...
This commit refactors the JS and LESS of the new mobile version
of the grouped kanban views. It ensures that the touchSwipe
library is lazy-loaded (only in mobile, when entering a kanban
view).
This commit aims to improve the UX of grouped Kanban views on
mobile devices. Only one column is now displayed, full width. The
columns' records are lazy-loaded. The user can swipe horizontally
to navigate through columns (thanks to the touchSwipe library).
Before this commit, the label was into a display block that add a return line
between the cehckbox and the label.
It was not visible in backend, because label by defaut is displayed without
renderCheckbox. (no options.text provided)
Now renderCheckbox render correctly with the same code in frontend and backend
- correctly update the pager when a record is added or removed
- destroy the widgets of the removed row when the user clicks on
'Cancel' when creating a new record
- ensure that the list always contains 4 rows (before this rev.,
in list views with less than 4 records, if the user created a
new record, then clicked on 'Discard', there were only 3 rows
left
- properly destroy field widgets when removed from the DOM
Note that the change of parent.parentID to parent.static is not a
bug fix, but it's better to use the key that indicates the type of
list element, instead of implying it from other attributes.
- correctly update the pager when a record is added or removed
- destroy the widgets of the removed row when the user clicks on
'Cancel' when creating a new record
- ensure that the list always contains 4 rows (before this rev.,
in list views with less than 4 records, if the user created a
new record, then clicked on 'Discard', there were only 3 rows
left
- properly destroy field widgets when removed from the DOM
Note that the change of parent.parentID to parent.static is not a
bug fix, but it's better to use the key that indicates the type of
list element, instead of implying it from other attributes.
Before this commit, there was a crash when sorting a one2many in a form view.
This is due to the fact that the event from the one2many bubbled up to
the main form view, which basically assumed that it was supposed to sort
some sub one2many.
It could be seen for example when editing a 'attribute' in a product
form view (need to activate variants), then sorting the 'attribute
values' sub one2many.
With this commit, we simply stop the event propagation at the correct
level.
KanbanColumn instances are saved in an array in the renderer. The quick
create widget is always put in the first column found in this array.
Unfortunately, the array elements' order was broken after some
operations where column(s) are rerendered (like moving records).
* crm, project
Add a new feature which allows to put a progressbar in the kanban
columns. The progressbar shows with the same color the amount of
records whose value of a given field are the same in the column.
It also indicate the sum of another given field or simply the total
number of records. It also allows to subgroup the column content.
To define a progressbar, add this as a direct child of the kanban
arch:
<progressbar field="<name of the field to use for subgroups>"
colors="{<one possible value for the above field>: <success, warning or danger>, ...}"
sum="<name of the field to sum or nothing to use total number of records>"/>
Also:
- Properly update record model data's parentID when moving a record
- ...
Previous kanban header was a div with `flex-flow: row nowrap`. So if
someone tried to add some stuff in it, it will be forced to stay on
the same row as the title and config buttons. This commit wraps these
row elements in a new div to allow kanban header customization (this
prepares for the kanban progressbars).
Move a record from one column to another in a kanban grouped by a selection field
leads to a traceback.
A selection field value is composed of a tuple ('value', 'String') and the write
command must send the `value` and not the `String` as it was done before this rev.
Clicking on a cell that contains a button (but not ON the button) leads to
a traceback (see "Scrap" button in Stock Operation for example).
This is due to the fact that a button is not registered as a widget so it can't
be activated.
This commit ensures that the next line is selected if the last column is a
buttton.
With the new views, we lost a (almost unused and undocumented) feature:
the ability to instantiate custom widgets in a form view, not linked to
a particular field. For example:
<widget type="weekly_timesheet" attrs="{'readonly': [['state', 'not in', ['new', 'draft']]]}"/>
We reintroduce this feature in this commit, with a nice twist: it also
works for the list view and the kanban view.
Christophe Simonis