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.
Before this commit, the xml attributes defined with 'context.get(key)' in the
subviews not inline were not evaluated correctly. This was caused
by the loss of the one context in the '_loadSubviews' method.
This commit fixes this issue and modifies the mockserver in order to be able
to use the parameter 'viewOptions.context'.
Before this commit, when an event had only a date, the event
was set to midnight.
This commit sets the event as all day event if the field used as start date
is only a date and not a datetime.
Before this rev., a traceback was raised when the user clicked on a
many2many tag in a kanban view without color field.
For instance, it was the case in the kanban view opened by clicking
on the Lead/Opportunity section of the activities icon in the
systray.
Before this rev., it was not possible to move a record (in the same column)
at the top and then move another record above it.
There is special class `o_updating` added on record being edited to avoid
moving them. This class is normally removed afterwards when re-rendering the
record.
When resequencing, the record is re-rendered so the class won't be removed ;
this is why it shouldn't be added in the first place (same behaviour as saas-15).
The server response to an `onchange` on a one2many is a list of
commands. In case of one2many update (command 1), the server
returns all fields (and not only the modified ones).
When saving the record, this is the client responsability to
specify which fields really changed.
Before this commit, all fields were sent at `write` and not only
the changed ones. This was causing issues when the user couldn't
write on the field ; an error was triggered even though the user
didn't change anything.
To fix this, we only tag as changed (in the datapoint `_changes`
attribute) the fields that have a different value after the onchange.
* fix typo, widged is actually widget;
* support name coming from context for calendar event quick create;
Support of context could be made generic in quick create mechanism but
in the meantime this fix is considered as sufficient for the use case
we have.
- datepicker doesn't default to current date by default
- date string in the input is now selected when clicking the field
- adapted the existing tests to the new changes
When a x2m field is modified, the 'save' rpc doesn't send 'False' as second
argument of the special command that manipulate the set of records.
From now on, the virtual id of the record is sent to the server as second
argument. This commit fixes the tests making the assumption that 'False'
was sent.
- Force vertical margin to 0 in case the class is added to elements
that comes with a default margin (eg. titles tags)
- Move title & subtitle rules at root level
The goal of this review is to have a layout which is correct to
implement the enterprise side-chatter.
This also removes/fixes deprecated community rules and xml templates.
In an embedded editable list view with the widget `handle`, resequencing a
record and try to edit it afterwards won't work. The selected record isn't the
correct one, as if the resequencing had no impact.
To make this work, the list datapoint needs to be ordered by the field with the
widget `handle` ; if it isn't, resequencing the records won't change the x2many
data order but the list view expects the same order.
In an editable list view with the widget `handle`, resequencing a record
and try to edit it afterwards won't work. The selected record isn't the
correct one, as if the resequencing had no impact.
A small refactoring has been done to fix this because the resequence logic
was placed in the ListController (but should logically be placed in the model).
Several views are using the resequencing ; the code is thus now placed in the
BasicModel.
The list renderer state is then updated after the resequence.
The resequencing and the line edition have been placed in a common mutex to
avoid problems when the user tries to edit a record while the resequence rpc
isn't finished yet.
Setting ir.values for computed fields is useless as the function onchange
in models.py will set to False all the computed fields with a modified dependence.
opw:767942
Before this commit, the scroll was reset to the top of the calendar after
an event quick create.
This commit fixes this by defining the get/set localState for the calendar
renderer in order to keep the scroll and calling 'reinitView' from the
fullCalendar lib instead of always calling 'render'.
Before this commit, we did not really handle gracefully editing a
one2many with many records. The main issue is that if the user was not
on the last page, creating a new record added it to the last page, which
is confusing and actually a bad idea for records with required fields.
This fix requires a way to track the current changes (because we do not
display the current state of the form view: the new record is displayed
in the first page, but is actually added at the end of the dataset).
Note that this probably does not solve all issues with pagination. This
is a quite delicate problem. We will add tests and fixes as needed.
We have a new runbot server which is quite slow. Because of this, it
takes too much time to run this unit test suite (for comparison, one of
the last build by the main runbot takes 126s).
This is necessary for now, until we use chrome headless or something...
- Remove carets
- Fix badges position
- Vertical align user avatar
- If a dropdown is open, the menu-toggle should appear active
- Dropdown menus' widths should be at least as the dropdown-toggle
Before this commit, only the routes which began by '/web/image' were
mocked (simply ignored). This forgot the case were it is a full URL
(http://www.test.com/web/image). Now, also mock the static images
routes (for .png and .jpg).
... sometimes.
When a dialog is destroyed, the last opened dialog (the one which
is just below), if any, is focused. This allows to close it
directly by pressing ESC. For an unknown reason, this was done in
a setTimeout (delay 0).
The problem is that the setTimeout made some JS tests fail
randomly, when a test ending by closing a dialog was executed
right before a test using a many2one inside a dialog. When this
happened, the second test failed sometimes because its dialog was
focused (because of the previous test) while waiting for the
autocomplete dropdown to open, triggering a blur event on the m2o
input, and thus making jquery autocomplete aborting the search,
and the opening of the dropdown.
Use case:
- a tax of 10%, computation method: percentage of tax included
- a account_reconciliation_model with an amount of 90%
- make a statement of 1.31 (or something weird when it comes to digits)
- reconcile it with a counterpart
- prefill that counterpart with the account_reconciliation just created
- push on reconcile
Before this commit, the amount that was computed was not rounded, resulting in making unbalanced account_moves (by 0.001)
This was invisble since the display of monetary is rounded
After this commit, the rounding is done according to the currency's parameters and produces correct move_lines
OPW 751881
This rev. fixes several issues with the sorting of dataPoints of
type list in the BasicModel.
First, only 'static' lists (i.e. x2many lists) must be sorted
client-side, and results of search_read RPCs must remain unsorted
as they are already retrieved sorted from the server.
Second, editable and non-editable x2many lists don't behave the
same with respect to sorting (we reproduced in this commit the
behavior of saas-15). With editable lists, the edited rows are
unsorted, except if the user explicitely ask for a sort (by
clicking on a column header), until the form view is saved. With
non-editable lists (as for x2many kanban), the sort is performed
directly when a record is created or updated (as the edition is
done from a dialog).