Rev. ee44d23 fixed a usability issue: when a doAction is performed
from a dialog, it automatically closes the dialog (as the action is
rendered in the background, behind the dialog).
However, it also closes dialogs when the action has target='new',
i.e. when it also opens in a dialog, which is not strictly
necessary in this case.
This is problematic in mobile for the product configurator widget:
in the sale.order form view, the order_line field is displayed as a
kanban, and in its form view, the product_(template_)id field has
widget product_configurator. When a value is set, it performs a
doAction (target="new") to configure the product. The widget listens
to the dialog's 'closed' event to update itself. However, with what
is done in ee44d23, the x2many form dialog is closed by the DoAction,
so the flow doesn't work.
This rev. reverts the attempt done in ee44d23, and does something a
bit more brutal: as soon as an action is pushed in target 'current'
(in the main part of the interface), all dialogs are automatically
closed.
closesodoo/odoo#34678
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
In a list/kanban view when applying a default_order on the view, it does not
work with favourite filter
Before this commit,
1) The default_order was not applied to the view when favourite filter is
applied
2) when default_order applied, Click on an element of the list/kanban and
then go back to the list/kanban with the breadcrumbs, default_order has been
changed.
This is because the ```_getOrderedBy ``` returns [] when favourite filter is
applied and it does not have sort value, added check if favourite has orderedBy
and has length then and only then pass orderedBy else pass undefined
After this commit,
1) default_order will be applied to the view
2) default_order will not be changed when going back through breadcrumbs
task-1922576
closesodoo/odoo#34001
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds a new parameter on fields for list view and one2many.
The parameter name is "optional" and its values are "hide" or "show".
Columns of the list view which have the optional parameter set are
listed in a dropdown that can be toggled from the last cell of the
table header. The ones with optional set to "hide" are hidden by
default.
User choice is stored in local storage. If no saved parameter can be
found in local storage then the default value from the view is used.
Due to the overflow behavior of the responsive table, we were forced
to wrap the table-responsive div in yet another div. We changed the
o_list_view class on the table to o_list_table in order to reuse
the more generic o_list_view class on the top-most div. CSS rules
and selectors had to be updated according to this change.
Task-1902765
Since JS refactoring of ActionManager at 32b8cec536, the /apps/<app> controller
was not working anymore as the refactoring dropped the support of `sa` as URL
state.
closesodoo/odoo#33679
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the merge of JQuery 3, the building of systray icons is non
deterministic.
After this fix, the menus are loaded correctly in order.
Task-ID: 1960741
closesodoo/odoo#32382
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce:
1. go on list view
2. open record in form view
3. come back on list view
4. switch to kanban
5. open record in form view
6. click on breadcrumb
Before this rev. we were back on the list view, and not the kanban view.
This is due to the fact that the breadcrumb was not updated when switching view,
(if a controller was already existing) so the form view control panel breadcrumb
was still referencing the wrong (list) controller.
This bug appeared with the control panel refactoring, which is now managed by
the view itself (and not the action manager as previously).
Task 1932646
closesodoo/odoo#31598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Let's assume the following scenario on an action with two multi
records views (e.g. kanban and list). In the kanban view, activate
a domain or groupby, switch to list view, remove the domain or
groupby, switch back to kanban: the domain or groupby is still
applied (even though it's no longer displayed in the search view).
This is due to the jQuery update (ab56e637b7) and the use of
native Promises (always async) instead of old jQuery 1.11 Deferreds
(which where sync when already resolved). In the new version, the
domain/context/groupby were added to the params a 'tick too late',
so the view was updated without that information (and thus the old
domain/context/groupby were kept).
Issue reported on the jquery update pad.
closesodoo/odoo#31859
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The commit 6d3ada178f
aimed to solve problems occuring whith (single or
double) quotes when creating new custom filters.
Unfortunately, the point was missed and bugs were
still present. The present commit solves the
orginial problem satisfactorily.
There was also a problem in the management of
backslashes. Type '\\' in the search bar would
lead to a domain like
[('...', 'ilike', '\\\\\\\\\\\\\\\\')].
This has also been fixed. Note that it is
necessary to input "\\" if one is looking for a
backslash in db (as before).
A remark on the _formatAST function (py_utils.js):
We deescape only the chars `'`, `"`, and `\`
because it does not seem possible to produce a
string in the search view that would intend a
search for a line return or a tab for example.
A general remark:
Domains should always be in normalized form.
In that way they could be manipulated and combined
together without a tokenization/parsing!
closesodoo/odoo#29756
The commit 6d3ada1
aimed to solve problems occuring whith (single or
double) quotes when creating new custom filters.
Unfortunately, the point was missed and bugs were
still present. The present commit solves the
orginial problem satisfactorily.
There was also a problem in the management of
backslashes. Type '\\' in the search bar would
lead to a domain like
[('...', 'ilike', '\\\\\\\\\\\\\\\\')].
This has also been fixed. Note that it is
necessary to input "\\" if one is looking for a
backslash in db (as before).
A remark on the _formatAST function (py_utils.js):
We deescape only the chars `'`, `"`, and `\`
because it does not seem possible to produce a
string in the search view that would intend a
search for a line return or a tab for example.
A general remark:
Domains should always be in normalized form.
In that way they could be manipulated and combined
together without a tokenization/parsing!
closesodoo/odoo#31025
Before the control panel refactoring, whenever a user pressed ENTER in
the search bar (with no text), the current view was reloaded. This
untested behaviour was changed (not on purpose) with that refactoring:
instead of reloading, the search view add a useless filter in the list
of facets.
We restore the previous behaviour in this commit.
closesodoo/odoo#30503
The 'Actions' menu displayed in the control panel (aka sidebar, or
toolbar), wasn't displayed anymore since the control panel
refactoring of 4cd379cf6e. Rev. c1752b834 correctly made it appear
again in list and form views. However, there was another issue as
the additional model-related items (like Print, or custom actions)
weren't fetched anymore. Thus, the sidebar only contained the
default 'Export' and 'Delete' actions. This rev. fixes the second
issue.
fixes#29546closesodoo/odoo#29633
The recent refactoring of the control panel moved the sidebar management
from the action manager to the view itself. However, the sidebar
parameter was forgotten, which resulted in the fact that it was no
longer created.
This fix was a little tricky, because the sidebar needs to be
instantiated in some tests, but not in most of them (in particular, the
document application changes its behaviour, which is annoying).
closesodoo/odoo#29389
There was a traceback when reloading the webclient with an act_window and an
empty id in the URL (ex: after saving Settings). A `read` without id was
peformed when loading data instead of a `default_get`.
Before rev. odoo/odoo@40dd121 the action environment was generated by the
ActionManagerActWindow, which was currently defaulting the `currentId`.
Now that this is not the case anymore, the `loadState` should have this responsability.
Task 1902826
closesodoo/odoo#29411
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>
When activating a filter on a list view,
the environment of the action contained a context with an orderedBy key
which was then used by every controller and model in the various
parallel flows, i.e. changing actions
After this commit, we prevent it by excluding the key when executing an action
OPW 1913190, 1914019
closes#29190
From a standard view with the main menu (what is called a target=current action)
open a target=fullscreen action
Then, go back to the first action, with the breadcrumbs for example
Before this commit, the original view was displayed fullscreen,
which impaired business navigation because the main menu was not there anymore
After this commit, the original view has the main menu
OPW 1906373
closesodoo/odoo#29096
This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.
All the helpers are exposed though testUtils.js.
There are 2 kinds of helpers:
1. Assertions
-------------
* assert.containsNone, containsN, containsOnce check that the DOM
(or a specific part of the DOM) contains a `selector`. It
generates a correct error message automatically.
ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
-> assert.containsOnce(form, '.o_form_editable');
* assert.isVisible, isNotVisible check that the DOM has an element
visible or not. They also check that the element is actually in
the DOM (before most tests didn't verify this).
* assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
properties of a DOM element, and also validate that it is
applied on a single existing DOM element (before most tests
didn't verify this).
ex: assert.notOk(form.$('button').hasClass('btn-primary'));
-> assert.doesNotHaveClass(form.$('button'), 'btn-primary');
2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.
Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
ex: form.$('button').click();
-> testUtils.dom.click(form.$('button'));
New Form utilities: (testUtils.form.*)
clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
the control panel buttons of the form.
`reload` reloads the form data.
New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).
New fields utils: (testUtils.fields.*)
* editInput, editSelect: allow to change the value of a field,
using a selector to identify it. They validate that the input
exists and trigger the change event automatically.
* editAndTrigger: allow to modify a field and trigger specific
events after the value change
* many2one (testUtils.fields.many2one.*)
clickOpenDropdown, clickHighlightedItem, clickItem,
searchAndClickItem: use a field name instead of a selector and
do all the complex mechanism to open, filter and highlight
many2one fields.
Joint work with aab, dam, ged, mge, svs and vsc.
Before this commit, when the user is in a form view (edit mode) and
click on a stat button, a new action is added to the action stack. When
the user then comes back to the form view by clicking on the breadcrumb,
it is supposed to be in readonly mode. Before this commit, this was not
the case.
This bug comes from the action manager refactoring, which removed the
view manager. With this commit, we add a new action lifecycle method
which is called when the action is restored.
Note that this commit implicitely changes the semantic of actions with
'target=inline'. As far as I can tell, this only applies to the settings
form view, which can easily be fixed by overriding the restore hook.
closesodoo/odoo#28663
* barcodes, calendar, partner_autocomplete, web_settings_dashboard
Make the notification system better, using bootstrap toast component,
and make it available in the frontend.
The toast component allowed to remove some JS code and made the
component customizable by themes but it had to be reviewed/fixed to make
it functional (maybe bootstrap will review its work in next versions).
This work should still be improved because there are still too many
ways (deprecated and not deprecated) to instantiate toasts in the
backend. The goal here was however to make the toasts more modern and
make them available in the frontend.
This work is needed for some tasks. @kig-odoo and @fja-odoo made a
pre-work to instantiate toasts in the frontend for their respective
tasks. This commit unifies the system.
Part of https://github.com/odoo/odoo/pull/32793
task-1970731
closesodoo/odoo#32793
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when an element with access key has a CSS
position absolute , pressing the key 'ALT' to show the access
key overlay may break the position of the element.
This is due to altering the CSS position of the element which the
overlay is attached to: it becomes `relative`, so that the overlay
takes the whole size of the attached element.
In case of an absolute element, it should not become relative,
otherwise its position on the document may be completely different.
Since the overlay has position `absolute`, if its parent has also
position `absolute`, then keeping both with position `absolute` will
let the overlay take the size of the parent, without changing the
position of the parent.
Task-ID 1885445
Before this rev. the lazy loading of views was correctly handled if there was
only one action in the action stack (which is usually the case when performing a
F5, the main use case of the view lazy loading).
Nevertheless, it might happen that the lazy-loading is used in top of other
actions (when performing a `doAction` with a form view for an action with
another view as first view, i.e. when leaving Studio while editing the form view).
The controller was `unshift` in the case (put in the first position of the
controller stack), which is not correct.
This causes the breadcrumb to be misordered and a traceback occured when trying
to access a breadcrumb element.
Co-authored-by: Aaron Bohy <aab@odoo.com>
- Change icon and design for dashboard subviews buttons, according to
the new mockup.
- Primary buttons are put into the same 'btn-group' to have better
border jointure.
! The new icon for the 'fullscreen button' requires to update
Font Awesome (currently in 4.7 and need at least the 5.0).
Task #1882571
Due to the route beginning with 'test: ', it was interpreted like a
protocol and on some OS (ubuntu for example), a xdg-open prompt pops up.
So, the window looses focus and some tests will fail because of that.
Up until now, the execution of a report action could not be followed by
any action which prevented, for example, to automaticcaly close a modal
after printing a report from it. This has become an issue when working
on customer's invoices using the new modal introduced in 4cb9194275
This commit allows to close a modal after the download of a report.
Revision on https://github.com/odoo/odoo/commit/3210f108272be89f1a7b01f4e1816b7f04ae0a3b
Before this commit, when doing an action that opens a dialog
(with `target: 'new'`), then triggering 'history_back', the
`on_close` handler of the action was never called.
This was not the correct behaviour, because the dialog closes
without the `silent` option set. Indeed, when this option is
not set, it should always call the `on_close` handler.
The bug comes from closing the dialog without any options, and
this case was not handled correctly in the commit above. This
commit fixes the problem by ensuring that the `on_close` handler
is called even when closing the dialog without any option.
This is a backport of 3210f10827
With this commit, when we perform a close action, we can provide infos to
the `on_close` handler, so that it can handle different cases that caused
the close action.
Aaron Bohy