| Age | Commit message (Collapse) | Author |
|---|
|
This rev. is the first part (out of 3) of the refactoring of the
ActionManager and ViewManager layer of the webclient.
The main changes are:
- there is no ViewManager anymore, its work is now handled by the
ActionManager itself, but isolated in a specific file ; this
eases a lot of things, as the breadcrumbs handling for example.
- the ActionManager code is converted to the new coding principles
and guidelines ; mainly, children widgets communicate with it by
triggering events up, and not by function calls anymore.
- the ActionManager layer is now testable, and a lot of tests have
already been written.
- the code in other addons has been adapted consequently.
What's coming next:
- introduce the 'AbstractAction' Widget, and make client actions
and view controllers inherit from it ; this widget will
implement a common API that could be used uniformly by the
ActionManager (e.g. restore(), canBeLeft(), renderButtons(),
getTitle()...).
- move the ControlPanel handling from the ActionManager to the
AbstractAction.
|
|
Before this commit, there were an error when you tried
to change the view_type directly from the url in debug mode.
The controller of the view wasn't defined and a crash happened
when we tried to render the DebugManager.View.
To fix this, we now wait for the 'switch_mode' which sets
the controller to the active view.
'do_load_state' is now chained to 'switch_mode'
|
|
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.
|
|
This commit lays the groundwork for the new work order tablet view,
which is a fullscreen form view that requires to be started in 'edit'
mode.
|
|
|
|
|
|
when coming back using the breadcrumbs.
The settings form view should always be displayed in 'edit' mode.
Before this rev., it was re-rendered in 'readonly' when the user
clicked on a link in a setting view (opening another view stacked
in the breadcrumbs), and then came back to the settings view using
the breadcrumbs. For instance, go to 'General Settings', click on
'Activity Types', come back.
|
|
|
|
|
|
Scenario: Go to any list or kanban view: go to next page and set a
filter that matches less that 'limit' record (e.g. less than 40),
but at least one. No record will be displayed, because the offset
is kept for the search_read.
This rev. ensures to reset the offset to 0 when a search is done
using the searchview.
|
|
Fix a bunch of ill-documented/incomplete/incorrect method docs
Without this, the automatic doc generation does not work.
|
|
This commit adds a feature to the widget Many2ManyTags for kanban
views. When a tag is clicked, records are filtered on the given
tag, in addition to the active filters in the search view.
|
|
|
|
The key `form_view_initial_mode` can be set in the action context, to
open the action in edit mode, mainly.
This key wasn't supported since the new view refactoring so this commit
restores its support.
|
|
|
|
Currently, the 'environment group by', if previously empty, is set to a
view-specific default value when filtering in a Kanban view. This then
causes an unexpected 'group by' when switching away from a Kanban view,
since the expected behaviour is to only take a Kanban 'group by' into
account if it was explicitely set by the user.
This is caused by the fact that the 'search' event triggers a view
reload which takes the environment as parameter, while the Kanban view
reload overrides the group by (arrays are passed by reference).
Both result in an undesired modification of the enviroment.
We fix this bug by giving a shallow copy of the environment as parameter
when triggering the view reload.
|
|
|
|
*account_asset
When a button of type 'action' is clicked (execute a given action),
special keys must be set in the context (active_id, active_ids and
active_model). They must be computed regarding the record containing
the clicked button, i.e. if we are in a modal, it must be the id
and model of the record displayed in the modal.
Before this rev., we always sent the id and model of the record
displayed in the background (i.e. the id and model of the url).
This caused a bug in MRP that could be reproduced as follows:
- open a manufacturing order in form view
- click on edit
- click on one of the line of the one2many, and click on the green
icon to edit a product
- click on the update product quantity button on top of it
- the product field must be correctly filled, which was not the
case before this rev.
|
|
|
|
Before this revision, double-clicking links in a modal triggered a
traceback. This is because the second click attempts to change the
active view while it is still being changed by the first click (more
precisely, the controller of the active view is undefined on the second
click).
This commit ensures that on_attach_callback is called only if the
controller is defined.
Steps to reproduce the issue fixed by this commit:
1. Open a sales order;
2. Click on a product line;
3. Double-click on the product.
|
|
Previously, we had to filter the context values to exclude some
erroneous values we propagated earlier.
This commit removes the earlier propagation of wrong values (the
current record context when executing an action) and thus also
removes the filtering of those values, which was actually removing
useful values from the action context.
The bug could be seen by following these steps:
- Install crm and sale
- Go to My Pipeline
- Open an opportunity which has a customer set
- Click on "New Quotation" action button
- See that the customer is not set on the new quotation, it should
be set by the default_partner_id value in the action context
|
|
|
|
Clicking on the discard button in a form view whose previous view is
another form view wouldn't do anything.
This is fixed by making the view_manager trigger_up a history_back event
and then the history_back callback will handle cases in which there is
only one view and only one action, which used to be rejected
|
|
Indeed pyeval that evaluates the context explicitly handles null value
differently from undefined values. Let us therefore avoid crashes when
it manipulates the context.
Example of crash
* click on forecast in project kanban view without having already created
forecasts;
* click on 'Assign' to create a new forecast;
* selecting a task crashes because of the domain on task field that is
evaluated using pyeval with an undefined active_id in context that
pyeval cannot handle;
|
|
This commit introduces the 'rainbowification' feature to the web client
(and to some affected addons). This feature is essentially a way to
display a nice friendly message when some business event happens. For
example, a encouraging message is displayed when the user clear her/his
inbox, or when a salesman closes a deal.
The mechanism currently only displays a 'rainbowman', but could be
extended later to add other kind of animation.
There are a few different ways to display a 'rainbowman':
- any JS code can simply trigger_up an event ('show_effect') with some
options: for example
this.trigger_up('show_effect', {
type: 'rainbow_man',
fadeout: 'no',
message: $done,
click_close: false,
});
- an action returned by the server can have an 'effect' key, with some
options
- the do_execute_action method accepts a 'effect' option. This is
useful when one wants to specify a rainbow on an action button in a
form view
Joint work with: dbh <dbh@odoo.com>, ged <ged@odoo.com>
|
|
|
|
|
|
A traceback occured when trying to create a BOM by going to
Inventory > Master Data > Products, on a product form view clicking
on the BOM stat button, and then on 'Create'.
This was a context problem: the context of the 'Products' action
was passed to the 'BOM' action without removing action specific
keys like 'default_*' or 'search_default_*'. For instance, it
contained a 'default_type' key, and as type is also a field of the
mrp.bom model, the python tried to interpret it, except that the
given value wasn't a correct value for mrp.bom.
When a button is clicked, we mix contexts coming from different
places to execute the new action. For some of them, we already
filtered out those action specific keys. This fix is simply to
make the piece of context adding the problematic keys pass though
the filter as well.
|
|
The mock server had to be modified in order to test this behavior
since it used to throw an error for invalid ids, while the actual
server just ignores it and continues forth with the other ids.
|
|
|
|
Add support for value 'save' to attribute 'special' for buttons in
form view. This is useful for form views in dialogs. When clicked,
it saves the form view and closes the dialog (the default 'Save'
button doesn't close the dialog). Without this, the only way to
achieve that was to define a dummy python method and call it with
<button type="object" name="dummy_method"/>.
|
|
Passing multiple ids wasn't correctly handled as the argument `record_id`
was wrapped in a list of list, which is not hashable.
The wrapping is now handled by the caller.
|
|
Before this commit, the parameter ´searchview_hidden´ was not used anymore
when it was defined for some views.
After this commit, the search view is hidden when it needs to be, e.g.
the helpdesk dashboard.
|
|
Since the new views, the editable list view lost some behaviors. These
behaviors were indeed implemented in the form controller/renderer but
as the new editable list view does not use an inline form view, these
behaviors had to be implemented in the basic controller/renderer.
For this to work, the list editable renderer had to be changed as it
was doing work that should be done by the controller.
The problem is even more complex because the x2m fields are using a
list renderer but not a list controller. So moving code from the
renderer to the controller obviously broke the x2m fields. Right now,
the problem is solved by catching renderer events and forwarding new
ones to the form controller (which handles the x2m specifically).
The initial goal of this commit was to share the validation of records
on save. Indeed, the fields were marked as invalid in the form view but
not in the list view. Also, before the new views, the editable list
view had different behaviors if they were used for a x2m field or not.
As these behaviors are making sense, this commit tries to restore them.
Basically, what we want is:
- When a record is saved (form view save or list view line leaving),
the invalid fields are marked (in red), the names of the related fields
are notified to the user and the record is not left.
- When a record is discarded (form view discard or list view discard),
the user is asked to confirm if the record is dirty before making the
record readonly.
- When a record is discarded, if the record is a new one, then the
record should be abandoned (removed as if never existed). In the form
view this induces to go back in the history and in the list view, to
remove a row.
- For x2m fields, the notification of invalid fields is not triggered
but the user is instead asked if he wants to discard the changes made
to the row (indeed, this replaces the list "Discard" button, as non
existent for x2m lists).
- ...
Saving, discarding, marking the fields as invalid and other behaviors
are thus now shared behavior of basic views.
The management of the dirty flag has also been moved to the model
as it was handle by the controller for the form view but by the
renderer for the list view. Now this flag is directly managed in the
basic model (the model can have changes thanks to the `_changes`
property but not be dirty (this is the case for creations)).
This change however created a problem. The view manager is currently
keeping asking if there are changes to discard at each action which
might lead to leave a dirty record (appswitcher / url change / ...).
It however did not discard anything as leaving if the user is ok with
it will lead to an implicit discard. However, as the view manager might
ask for this discard multiple times by second, the controller was
marking the record as not dirty the first time but without discarding
the changes. This is more complex to do now, as the dirty state is
part of the model and that the renderer should match the model data.
To solve this problem, the view manager now actually discard changes
explicitely when asked to. Even though this had been optimized to not
cause any rerender in some cases where it is not needed, this could
cause some performance decreasing. However, this makes some cases more
logical (opening the app switcher on a dirty form view then going back
to the form view by hitting the "go back" button left the form view
untouched although the user asked to discard it). This solution will
be improved with the view manager refactoring.
This commit is also making use of the `commitChanges` system which had
been implemented for HTML fields. Indeed, these fields cannot know
about all of their changes, so when hitting the save button, we asked
those fields to commit their value. Using this system is a great way
to make the `isValid` method of x2m fields synchronous. Indeed, before
this commit, the method was sometimes asking the user if he wants to
discard an invalid line before save. That case can be handled by the
x2m `commitChanges` method: we consider that saving the lines of x2m is
an operation that has to be done before considering the save, so we ask
all the x2m fields to do so at that time. Also, the system was broken
since a recent commit: we indeed protected the changes - save order
with a mutex but unfortunately, the `commitChanges` method was part of
the save and the changes it triggered were not able to be considered
because of this mutex. This had not been detected by tests as there is
not current way to test html fields.
|
|
This commit actually fixes a few problems:
1. the _visitChildren method in the basic model was not following the
changes, only the data, so it was not correct (for example, the isDirty
method was wrong for relational data, when no other change was done)
2. new records could not be discarded, because they had no data in their
data key. What we do here is to add a savePoint, so it is safe to
restore them (it caused a crash)
3. the save method was not properly following children when it was
called with the option savePoint=true
4. when the user tried to discard a form view, in an action with only a
form view, it was redirected to the previous url (via the history_back
action), instead of simply discarding the current form view
|
|
Mode 'readonly' is a concept of list and form views. When
switching from a graph view to another view, then switching back
to graph, there was a crash because 'readonly' is not a known mode
of graph (in graph, mode is used to determine the type of graph to
display (pie, chart or bar)).
This is due to commit odoo/odoo@ef6b330 which aims to reset the
mode to readonly when coming back to a form view using the
breadbrumbs.
|
|
Before this rev., some keys were added to the context of a record
if there were x2many fields in the form view with a context
defined on their node (containing *_view_ref keys, specifying the
fields_view to load to display the relational data). Those keys
should not be added to the main record's context, and it may cause
errors (e.g. click on the 'Procurements' stat button in the Product
form view).
|
|
When creating a new record (form view without `currentId`), the form
view should be rendered in edit mode and not readonly.
|
|
When clicking on a button in a form view, the current data should be
saved but the form view shouldn't be re-rendered in readonly.
Before this commit, the view was re-rendered, causing a weird glitch
in dialogs as buttons that were supposed to be moved to the dialog's
footer appeared inside the view when the button was clicked.
Also forces the default mode in form view to readonly, so that it is
correctly redrawn in readonly when coming back using the breadcrumbs.
|
|
Before this commit, it could happen that a crash at the wrong time (for
example, while loading a view) cause the web client to crash for various
reasons. For example, it assumes that the active view always has a
valid controller. Or the action manager could not detach the previous
view, so we had the 'double view' rendering in the web client.
With this commit, we add some protections at various points. Those
safety measures should help the user keep working even if a specific
view did crash.
|
|
As `create_view` is asynchronous, it is possible that there is an
active view without any associated controller.
We thus test here if there is a controller before calling its method.
|
|
In some cases, the view manager do_load_state method can receive an
empty string as id. This was the case when we refresh the dashboard for
example.
This is not a perfect fix (the do_load_state and the url mechanisms
should be improved), but it makes things more robust.
|
|
Before this commit, we did not check if the changes can be discarded
when opening the app switcher. This is now done. Note that this check
was formerly done in the form view, and we moved this to the view
manager. This now means that all views have the power to decide if they
can be discarded.
|
|
* Data manager load_view returns a viewInfo object
* ViewInfo contains: the arch, fields and fieldsInfo objects, and some extra informations
* The fields come from the server and are frozen, without any view attributes (depend of the model).
* The fieldsInfo contains every view attributes and informations.
|
|
When reloading a view by clicking on its icon in the view switcher,
some params of the view (e.g. limit) were reset to their original
value. So if the user previously updated that param (e.g. by
editing the pager), these changes were lost.
This rev. ensures that those original params are only given to the
view at its initialization, but not on reload.
|
|
We share the basic model record between views, and we have to make sure
that everything is properly coordinated. The main issue solved by this
commit is the fact that we can now edit a one2many record, then close
the dialog, then edit it again and finally cancel the changes, which
bring us to the previous step.
Also, we had to slightly improve the AbstractView API
|
|
We want to remove data.js, but we still need the CompoundContext class,
so we take it out, and rename it 'Context'
|
|
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
|
