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
Have a model A with a o2m to B.
In the list have a field B > m2o > C
Also have a sequence field (widget handle) on B
Then Create a record A
Arrange yourself to have two new records B popping right away (through an onchange)
in the o2m. Their C field have to be empty
Resequence those two B lines with the handle
Before this commit, there was a traceback when trying to do an name_get on the C fields
Since both of them are empty, there is no record in the localData
Hence, no model. And also no records anyway, so no need to do a name_get
After this commit, there is no traceback, the name_get is avoided when no data is to be fetched
OPW 1853088
closes#24988
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.
This commit introduces a new widget to be used for selection-based fields.
Valid choices are displayed using rectangular badges and not like the
standard list. This widget is valid for selection and many2one fields
like selection or radio widgets.
Co-authored-by: Siddarth Gajjar <sga@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
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.
Before this rev. the `column_invisible` and `default_order` attribute, set in a
x2m list view were only taken into account for inline views.
The technical reason behind is because non inline views are fetched after the
main view processing.
Non inline x2m list views now correctly handle these two attributes.
Before this commit _mockReadGroup method support only day and month aggregate
function and return invalid domain for date type field.
With this commit _mockReadGroup method support week and year aggregate function.
And return correct domain having start date and end date if date type field.
Model A has a o2m to model B
Model B has a m2o parent_id on B
In A's form, add a B item,
then in the m2o, create record
Save and New
Click on the m2o
Before this commit, the python crashed on name_search.
This was because we sent the virtual ids to it
After this commit, there is no crash
OPW 1850212
closes#24948
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.
Have a decorated (conditional on field) editable list, with a default_order.
Have more records than the pager allows.
Add an item, and hit escape to cancel addition.
Before this commit, the cancellation crashed because the first record on the other page
was trying to evaluate the decoration for its row, which is wrong in the first place.
This was because creating a record increases the limit of the list, to be able to see the record
being created.
At cancellation though, that limit was never decreased.
After this commit, the whole flow happens without problem.
OPW 1844495
closes#24682
Let's assume the following scenario: in a kanban view with a
domain, remove that domain and quickly click on a record to open it
in form view. On a slow network, it may happen that the reload of
the kanban view (triggered by the domain change) returns after the
load of the form view.
Before this rev., when this happened, the form view was correctly
displayed but the control panel contained the buttons, searchview,
pager... of the kanban view.
Note that this fix is quite ugly, but it won't be necessary anymore
as soon as the control panel won't be shared between actions and
controllers, i.e. as soon as each controller will have its own
control panel.
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.
With this commit, we introduce a better screen to manipulate the search
view in a mobile device.
Note: most of this work was initially done by suh-odoo, then was adapted
and moved to community by myself.
task 31464
Revision on https://github.com/odoo/odoo/commit/9a9da5763b38a3bce54e9c4870af0032e38cacc3
The intent of the commit above was to no abandon records in a list on
discard when these records have been created from a `default_get`.
Also, the `default_get` may also perform an `onchange` that could create
more records. The records from this `onchange` must also be included in
the "do not abandon" rule.
However, the rule was too relax, so that any following `onchanges` from
a user interaction was also considered into this rule. As a result, it was
not possible to abandon such records.
With this fix, we restrict the rule to `default_get` (already the case) and
only the `onchange` right after a `default_get`. Any record created on an
`onchange` from a user interaction after a `default_get` should be abandoned
on discard.
Representation of creating the list:
savepoint
|----------|-----------|-------||--------|------->
create default_get onchange1 onchange2
record in the list is created by default_get or onchange1
=> do not abandon on discard
record in the list is created by onchange2
=> abandon on discard
Before this commit, some records in a list did not show the name of their
many2one fields.
This case occurs when the records in the list are created from a default_get,
and the records do not fit in a single page. In that case, the records in the
first page correctly display the names of their many2one fields, but not the
records in the other pages.
Fixes#24547
Before this commit, when a list contains records with many2one fields that
contain the same values, duplicate ids were passed to the server on rpc
`name_get`.
For instance, if 40 records in a list refer to a Unit of Measure with id "1"
whose displayed_name is "unit(s)", the server receives a long list of ids with
simply the value "1". Also, the server responds with a list of displayed_name,
in this case a list of 40 strings "unit(s)".
With this commit, we always pass unique ids to the server on rpc `name_get`.
When sorting records according to a many2one field in a list view
embedded in a form view, the js would sort according to their ids,
in a seemingly arbitrary order.
Thus sorting records according to a field with values in ("a", "b", "c")
could be sorted as "a", "a", "c", "b" instead of "a", "a", "b", "c".
We make the comparison on the name of the field instead.
opw 1838860
content_subtype was a parameter to message_post allowing to give plaintext
content instead of html content. It has been removed at 74d4b3902d. This
commit cleans some leftover bits referencing this now removed parameter.
... in session_storage.
The current action is stored in the session_storage (stringified),
so that it can always be restored on F5 (useful for dynamic
actions). Before this rev., it was stored with it's 'raw' context,
i.e. before its evaluation. However, when this context is an
instance of a CompoundContext, it is meaningless once restored.
So this rev. ensures that the action is stored with its evaluated
context.
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
Assume a one2many field inside a form, displaying field A in its
list view, and a field B in its (dialog) form view. Moreover, there
is an action button in the dialog, which updates the value of B.
Before this rev., B wasn't correctly reloaded when the button was
clicked, because the BasicModel reloaded the fields on the list
view (i.e. field A), whereas it should reload the fields in both
views.
This fix is twofold. First, we force the viewType to 'form' when
the record is reloaded, instead of the default ('list'), so that
fields in the form view are correctly reloaded. Second, when we
open the form view in the dialog, we add the fields of the list
view to the dict of fields of the form view, so that the form
is aware of those fields and can ask the model to reload them
(still without displaying them).
Fixes#24189
Mathieu Duckerts-Antoine