| Age | Commit message (Collapse) | Author |
|---|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
|
|
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.
closes odoo/odoo#31232
|
|
- Hide the "Remove" button on the create modal's footer.
- Update title when click on "Save & new" button
Task ID: 1924887
closes odoo/odoo#30209
|
|
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
|
|
|
|
On a form view (of model A), define a many2one (model B) with a [form|tree]_view_ref context key
In that view, have a x2m field (model C) with a different [form|tree]_view_ref context key
Before this commit, the second load_views (i.e. on the model C) crashed because
the wrong context key was sent to the server, which returned the view to which the _view_ref points
i.e. the view of the model B
After this commit, we clean the context of subviews loading, because those keys are only useful for the python
and one shot. Hence, there is no crash
OPW 1903780
closes odoo/odoo#28260
|
|
Fixes #26629
|
|
Currently, to remove link of x2m field from any record, sometimes there's no way.
For example, if we are on mobile and open any Quotation, it's linked quotation lines
are automatically converted in kanban, and there is no way to delete a line from
that quotation. However, in some of the manually designed kanban, there is special 'x'
for removing / unlinking x2m record, for example, Contacts of Partner.
This commit makes the behavior more consistent. During edition (mobile and desktop), if
a view dialog is opened on click of x2m field, it will have one 'Remove' button (based
on user rights) on right side of dialog footer, allowing users to delete / unlink the
record. Moreover, in mobile, the modal is opened fullscreen, with sticky header and
footer.
Related Task# : 31641
Closes PR #15857
Co-authored-by: Mohammed Shekha <msh@openerp.com>
|
|
BS4 "btn-default" class was replaced with "btn-secondary", which makes
more sense.
|
|
The pyeval name is quite confusing, given that there is already an eval
and an evaluate function in py.js, and that the web.pyeval exports two
evaluate functions.
Since this file is more about odoo specific customization to py.js, it
is renamed in py_utils to better express its intended use.
|
|
The goal of this commit is to allow fast entry of the same model using
the keyboard for navigating through the form once, by blocking the user
from advancing in the form if there is a required field or once they
went through the form once to get them to a primary action (button)
This commit includes the following changes
1) Enable moving forward from field to field using the TAB key
2) Entering the one to many and many to many using the TAB key
a. When entering it, set the focus on the "add new line" link or
button
b. When adding a new line, set the focus on the field visible
editable field of the new line
c. Discard adding a new line with ESC key
d. If the user leaves the first field empty and uses TAB, we
will cancel the adding of a new line and move to the next
field of the form
3) When a field is required and not filled in, do not allow the user
to move out of the field using the TAB key (the user is still
allowed to use the mouse though), mark the field as invalid
instead
4) After going though the form once, using the TAB key on the last
field will move the focus to the first primary button of the page
5) When the focus is on a primary button (EDIT/SAVE), the user cannot
move the focus forward using the TAB key. Hitting TAB again will
display a tooltip telling to hit ENTER to activate the button.
The mouse is still available to move the focus.
6) When the user saves, the focus is placed on the first primary
button of the form renderer (like VALIDATE for a new invoice)
7) On dialogs, primary buttons should stop the users from moving out
of them, and showing a popup if the user tries
8) When closing a dialog, the focus will be moved back to the widget
that opened it.
This commit does not include the following features
1) Navigation with the keyboard on a selection one to man
2) Navigate between tabs in a form using the keyboard
3) Cancelling the adding of a new line in a many to many using the
ESC key do not set the focus correctly
4) Enhancing the focusses fields (like blue underline)
|
|
|
|
On an editable line with a many2one
Click to create a record
Click on create a record in the many2one
It opens the form view of the object in a modal, which has a many2many list, which choices are domainized
Click 'add an item' on this list
It should open a modal with the filtered choices
Click on any of the existing record
Before this commit:
There was a traceback in JS
That was because the event bubbled up to a parent, when it shouldn't
After this commit:
The whole flow unfolds without errors
OPW 1823205
|
|
This is a manual forwardport of rev. b466b3bc608.
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it crashed because it tried to retrieve the
action's context (to add to the saved filter), whereas there is no
action in this case.
Actually, the action's context should never been used in this case.
What must be used is the controller's context (this mainly makes
sense for Pivot and Graph views).
Fixes #23293
|
|
This is a manual forwardport of rev. b466b3bc.
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it tried to retrieve the context of the active
controller in the closest instance of a ViewManager-like widget
in the SearchView's ancestors.
First, it is wrong as in the given scenario, the requested context
is actually the one of the list controller in the dialog, not the
one of the form controller in the background.
Second, it produces a crash in Studio, when trying to save filters
in the dialog opened by clicking on 'Search More' on the groups
many2many field in the sidebar.
This part of the code can't be tested in this version, but tests
will be added in master.
Fixes #23293
|
|
|
|
*: mail, web_diagram
|
|
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.
|
|
*board,sale_timesheet
This rev. changes the API of load_views, as it now assumes that
the given context has no longer to be evaluated. This is more
convenient that way, as we can now call load_views with contexts
that are dict, and not instances of the Context class.
|
|
|
|
Here is a scenario that could cause an issue:
- open a form view with a many2one
- click on edit button
- click on small external button for many2one. this opens a modal form
view
- click on save in the modal (without changing anything)
- click on save in the main record
- exit form view. this opens a discard dialog
There were two issues here:
- saving the modal dialog automatically marks the many2one field as changed.
This was necessary to force reloading the data, because editing a sub value
in the modal form view could have changed the display_name of the manyone
field. However, this is not necessary when no change was done.
- when saving a record, the _isDirty flag was reset to false only if an
actual rpc was done. However, it may happen that the flag is set to
dirty (for example, when modifying a value inside a many2one), but the
main record has no changed fields.
In this commit, we also remove the on_save handler in the
formviewdialog. This is a small refactoring in a stable version, but no code
currently use it, and I believe that it will make the code much easier
to maintain (the previous code was really awkward), so I think that the
tradeoff is acceptable.
|
|
An error occurred if the domain or context applied on a view
opened in a dialog needed to be evaluated (e.g. if they contained
something like [['some_field', '=', uid]]). For instance, create
a custom filter with such a domain for the Contact model, then go
to Contact, create a new one, and on the parent_id many2one, click
on search more. Before this rev, no eval context was given so the
domains and contexts couldn't be evaluated, and it crashed.
|
|
|
|
When selecting a partner in the reconciliation widget, using the SelectCreateDialog
(Search More), the partner wasn't correctly displayed.
This was due to a difference between the change format of the many2one ; when using
the dialog, only the `id` is sent (while the `id` and `display_name` are sent when
using the many2one dropdown).
These two behaviours are now standardized and both now send `id` and `display_name`.
It has the advantage of sparing some `name_get`s called by the model because the
`display_name` was missing.
This change implies some refactoring where the SelectCreateDialog was used.
|
|
|
|
There were some coding mistakes since some changes introduced by
https://github.com/odoo/odoo/commit/d19671f0d0ff7189055cbe0794afed32f8a387e6
|
|
As its name indicates, the SelectCreateDialog is meant to select and create,
not edit.
If the view is editable, clicking on an element will edit it instead of
selecting it. For this reason, the view is set in `readonly` even if the view
arch uses the attribute `editable`.
Before this rev., you couldn't select a "Close Reason" when closing a
subscription (in "Search More").
|
|
* web_editor, web_planner, website
The 'Dialog' class is used in both backend and frontend. Also, lots of
actions can be done without the use of any modal. It thus makes sense
to lazy load its related xml only when a first modal is opened.
This change also allows to get rid of the "base_common.xml" file as the
dialog template is the only remaining one in there and, in the future
website update, it will allow to not load any static XML file on website
page loadings.
|
|
before this fix: the domain is used when opening the dialog but it is not
used if the user update the filter or the group_by.
|
|
Ultimately, it seems that sending the value of readonly fields
when saving is not such a good idea. Suppose that there is a
computed field displayed as readonly in a form view. This field is
computed from other records, e.g. from a one2many field which is
editable in the form view. Finally, the inverse function of the
computed field creates the one2many records. If the user adds some
records to the one2many, then saves, the readonly computed field's
value is sent to the server as well, and thus the inverse function
is executed, which isn't what we want.
This commit essentially reverts 0494d61274, except that we now take
into account the readonly modifier to determine whether or not a
value is sent to the server, and not only the readonly attribute of
the field (which can be seen as a default). Before rev. 0494d61274,
we made a difference between write and create RPCs, for an unclear
reason. We don't do that anymore: readonly fields are never sent to
the server (same behavior as before the new views).
|
|
The autofocus worked fine when switching from 'readonly' to 'edit',
but not when clicking on 'Create' from the multi-record view. This
was because in this case, we were trying to focus the field while
the view wasn't in the DOM yet. This rev. ensures that we wait for
the view to be appended to the DOM before trying to set the focus
on the default field.
Also ensures that the first visible field is correctly focused.
Before this rev., if the first field was invisible (or simply
not focusable), no field was focused.
Credit goes to @msh-odoo for the preliminary work.
|
|
When clicking on 'Save & New' in the form view dialog, a new default record
is created. The parent was not correctly set in this record, which causes an
error if `parent` was used in context.
|
|
When a SelectCreateDialog was opened with a given domain, this
domain was completely lost if the user wrote a new domain (or
groupby) in the searchview, whereas they should be concatenated.
|
|
With this commit, we prevent view dialogs from changing the 'global'
environment in the view manager. Here is how it could cause a problem:
* open a form view for a bill of material
* click on one of the component, it will open a form view in a dialog
(and will change the environment with a wrong res_id)
* click on the many2one product -> it will open a new action in the
background, and change the environment again
* click on the breadcrumb to come back to the bill of material: the view
manager will try to restore the correct res_id (which is the wrong id
from the component form view), the form view will do a read (when
reloading the data), will get an empty result, will update its
information with no data, then will be in a wrong state which means
that the basicmodel will fetch a x2many with a wrong res_ids list
* boom
|
|
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 is not a complete work, but it introduces the basic infrastructure
to properly edit various more sophisticated editing behaviours.
The main focus of this commit is to handle discarding invalid lines in
one2many, potentially asking the user for confirmation. So, the
relevant methods have to be modified to return some deferred, because
the operation is now asynchronous.
|
|
With this commit, updates of existing o2m records are now
correctly saved in DB when clicking on 'Save' in the main
form view.
|
|
A record of the basic model may need to be displayed in different
views (e.g. a o2m record is displayed in the, e.g., Kanban view
inside the main form view, and if clicked, it is also displayed
in the form view opened in a dialog). However, the fields present
in those views may differ.
The previous implementation of fieldsInfo in the record didn't
handle that, as it was a dict whose keys were field names. With
this commit, the fieldsInfo is dict whose keys are view types, and
the values are dicts whose keys are field names (the fields of
the corresponding views, with they attrs in the view).
This allows to create multiple o2m records in a row in a form view.
|
|
One2Many fields edition (creation of new related records or
edition of existing ones) needs a specific handling, because the
related records aren't saved when the user clicks on 'Save' in
the dialog, but when he clicks on 'Save' in the main form view.
To make this work, the model (instance of BasicModel) and the
representation of the edited record in the model must be given to
the form in the dialog.
Problem is that the fields to display in the kanban or list view
and the form view in the dialog may be different, so when opening
the dialog, the list of fields in the record is updated, and this
list must be reset to its original value when the user closes the
dialog. This last part wasn't done correctly before this commit,
which causes tracebacks when the kanban/list view contained fields
that weren't in the form view.
|
|
* 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.
|
|
|
|
Before this commit, the field properties (attrs, fieldNames, fields)
were not correctly given to sub views in many case
expected:
* use widget many2many on one2many field
* create record when click on save in formDialog
* do not send create command to the server
* use the fields defined in the field node (instead of tree view fields)
* use the fieldNames instead of the record to get field values
|
|
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
|
|
For this change, I had to pass the handle to the parent datapoint all
the way from the controller to the new form view.
|
|
Before this commit, the form view opened by a one2many did not check
that the required fields were properly set, so it could lead to pretty
strange results.
|
|
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
|
