[FIX] *: selectors in tours
[FIX][TMP] account: CogMenu selector in tours
[FIX][TMP] web*: Breadcrumb targetting in tours
Adds a `o_breadcrumb` class to target the whole breadcrumb, no matter
how much elements it contains (collapsed parts, visible path, single
name...).
add classname on last breadcrumb item
[FIX][TMP] project: View buttons selector in tours (moved away from CP)
[FIX][TMP] project: Kanban selectors in tours (quick create)
[FIX][TMP] *: SearchBar selectors in tours (toggle menu)
[FIX][TMP] *: ButtonBox selector in tours
[WIP][IMP] web: add toggleSearchBarMenu in search helpers
adapt and unskip 3 list tests
adapt and unskip calendar tests
unskip web_tour test that actually pass
post rebase fix
allow to lose cell focus after multi edition (given to searchbar) - bug reported, to check later
post rebase fixes
fix
Part-of: odoo/odoo#116641
This commits aims to improve the search feature in the export dialog.
Now, the search isn't resetted when a field is added to the export list
anymore. It is also possible to search in the list of fields using the
technical name of the field.
A test has been added for the search feature in debug mode, and another
one has been adapted to verify that the search input still contains the
string previously entered.
task-3266632
closesodoo/odoo#118767
X-original-commit: 83e58a0e7e1a6f50ad03a098829946d56393d496
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes the search feature of the export dialog. Before this
commit, it was impossible to display subfields that would match the
search pattern, since the filter was only applied to look for fields
at the 'root' of the available fields.
Now, it is possible to search and find subfields that matches the
pattern, and they are displayed inside their expanded parent(s).
A test has been added and verify the search feature.
task-3245492
X-original-commit: cd581aa41874dadb5c87605ed49b105959f1b222
Part-of: odoo/odoo#118767
This commit fixes a crash that occured when selecting an existing template
in the export dialog, in debug mode. Since the /web/export/namelist returns
a 'name' and a 'label', the template didn't had the 'id' attribute set on
the element and the key couldn't be set properly in the template of the
component.
Now, the id attribute is added and the list can be displayed as expected,
without any crash. 'label' has been set as 'string', to make the component
use the same naming in the template and reduce potential issues. A test has
been added to verify the behavior of the dialog in debug mode, which displays
the field technical name next to its label.
task-3255591
closesodoo/odoo#117378
X-original-commit: 1aa090c6393a13f02f238c5a569875022e27a4aa
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
This commit fixes the exported fields list used by the export dialog. Since the
list was deducted from the column titles, it was not possible to get the complete
attributes required to filter them. Now we use the real fields fetched from the RPC
in the dialog. It fetches the correct list of exportable fields, and the
defaultExportList props only serves to list fields associated with visible columns.
It is now possible to filter fields correctly, and improve the reliability of the
export feature, to use the data from the RPC instead of using the data deducted from
the visible columns only.
A test has been added to verify the presence of a field that has the defaut_exportable
attribute in the export list by default.
task-3203958
closesodoo/odoo#116003
X-original-commit: 9ea5cf81a2b5ddcb0f19827d4a699193046fafb6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The external button of the Many2one field has been changed with the
"always edit" feature of the form view, s.t. it displays by default
another icon (a right arrow) and when clicked, opens the related
record in another plain screen action instead of a FormViewDialog.
However, this doesn't work for Many2One fields that are already in
dialogs, because
1) if it's an action dialog (target="new"), that dialog will be
closed when opening the related record and the user loses its
working context
2) if it's another type of dialog (e.g. FormViewDialog), the
related record opens in the background and the dialog remains
open, which is obviously a bad UX experiment. This had been
locally fixes at some places [2].
This commit fixes the issue by automatically opening the related
record in a FormViewDialog if the Many2One is itself already in a
dialog.
This commit also fixes an issue with the scenario where the related
record opens in a dialog: if there were changes done in the main
record, those changes where lost when the user clicked on "Save"
in the dialog of the related record. We now only reload the
display_name of the related record, and apply it to the model.
[2] https://github.com/odoo/enterprise/commit/ba0e95fe42696dcf44b8feddeb302f04876fcbdc
Task 3191319
closesodoo/odoo#112959
Related: odoo/enterprise#37213
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
From a practical point of view, it seems better to also add the
dialog service in the service registry when calling
setupControlPanelServiceRegistry.
closesodoo/odoo#113610
Related: odoo/enterprise#37510
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The previous commit has as a side effect to change the value returned by
the create method of the orm service. Here we adapt the code that uses it
and make the test pass.
Part-of: odoo/odoo#111965
This commit fixed the ExportDialog used when there are the same
field used multiple times in a list view. Since those duplicated
elements were given twice to the dialog, there was a bug causing
a crash due to a duplicated t-key in the template.
Since duplicated fields must not be displayed twice in the list
of available fields to export, the defaultExportList has been
filtered to only return unique elements.
A test has been added to verify that duplicated fields are not
given twice by the list controller, by only displaying once the
corresponding field.
ticket #3150866closesodoo/odoo#111884
X-original-commit: 74b09fbd346f5759fc3fa8ed28ec15d5f58a7a42
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes the export when all records are selected (full domain).
Since many records ids might be present when an entire domain is selected,
the request should contains 'false' instead of a list of ids. As a limit
is set in session.active_ids_limit, not all the records were considered.
This means that only the limit was actually exported instead of the full
list that is present. As the legacy implementation of the ExportDialog
allowed to export all records, the behavior has been fixed.
A test has been added to verify the correct parameter during the download
call.
closesodoo/odoo#110126
X-original-commit: 7200e1c5875bc148fb64187fd67d58a7d6c13c7c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, exporting templates were not filtered as
expected. It means templates were visible even on other domains,
polluting the list of templates of a model.
This restores the legacy behavior by filtering the domain in the
rpc and only displaying the desired template list.
A test has been modified to verify the presence of the domain
filter in the parameters of the rpc.
task #3127779
X-original-commit: 30a673c044e53bfb1edc1e6733b2c83c67e0232c
Part-of: odoo/odoo#110126
Since the rewrite of this dialog, some inconsistent behaviors were
present compared to the legacy implementation. This commit fixes some
of them.
First, many2many fields couldn't be expanded as it was the case before.
Secondly, the export list generated by default was wrong, and it has been
fixed by this commit. The defaultExportList that was computed in the as
expected for the direct export is now also used to display the right
fields from the right pane as it ignores the fields that are explicitly
not exportable.
Finally, minor UI issues have been fixed, like a wrong title.
Tests have been added to assert the correct behavior of the dialog when
selecting records.
closesodoo/odoo#109670
X-original-commit: 86b634a120de0843fbd90079e9e457818fd4acde
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
Steps to reproduce:
- install "sale_management" module;
- create a quotation;
- add a product;
- click on "Search More...";
- create a favorite filter;
- leave and return to the Dialog window.
Issue:
No previously saved filter appears.
Cause:
The `loadIrFilters` parameter has a default value equal to `false`.
Solution:
Set the value of the `loadIrFilters` parameter to `true`.
opw-3105096
closesodoo/odoo#108946
X-original-commit: 7b60ee37e31d92d79108bd4e472553a452c2b0be
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
**Issue:**
- Open a list view with `expand="1"` and `limit=<arbitrary small number, say 5>`.
- BUG: The pager shows that it's displaying the limited records, but in reality,
it's displaying all records under each group.
**Solution:**
This is because we are *not* limiting the number of records being fetch in the first
read_group rpc. We are now specifying the expand_limit in this commit.
closesodoo/odoo#106238
X-original-commit: e5bba9f5eb63ee95924c892801fe18feaef6d1fc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, in the list view, clicking on the "export all"
button created an xslx file that did not reproduce the order of the
columns in the view.
Why is this?
The order used was based on the data fetched by a
rpc("/web/export/get_fields".
Solution:
Do not do a rpc("/web/export/get_fields") and use the order of the
columns in archInfo.
How to reproduce:
- Go to a list view
- Click on the "export all" button
Before this commit:
The order of the columns in the created file may be different from the
order in the list view.
After this commit:
The order of the columns in the created file is the same as in the
list view.
closesodoo/odoo#104541
X-original-commit: 734eee368d548fddc6c516ff559d09e853d1ab74
Signed-off-by: Luca Vitali <luvi@odoo.com>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit solves two bugs:
1. In a grouped empty list view, if you click on a sortable column,
then a crash is displayed.
How to reproduce:
- Go to a grouped empty list view with at least one sortable column
- Click on the sortable column
Before this commit :
A crash is displayed
After this commit:
Nothing happens.
2. In a grouped view with at least one open group, columns that do not
have an aggregates value cannot be sorted.
How to reproduce:
- Go to a grouped list view with at least one open group.
- Click on a sortable column that does not have an aggregates value
Before this commit:
Nothing happens
After this commit:
The records are sorted by the clicked column.
closesodoo/odoo#102143
X-original-commit: 537bbc79fe0ce34fe8b4746bf4cc86f9ebfc8a12
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
In the conversion of the FormViewDialog from legacy to wowl, we
forgot the feature allowing to display a "Remove" button in the
footer, and to execute a custom callback when this button is
clicked. This is used for instance by the Gantt view.
This commit restores the feature.
closesodoo/odoo#102149
X-original-commit: 3eb126d0297a7e3db0cb98cd1ad9555eefaa0cfa
Related: odoo/enterprise#32281
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, clicking on view buttons with attribute
`close="1"` in FormViewDialog didn't close the dialog once the
button action was performed. This commit fixes that issue, and
ensures we do not reload the record if we're about to close the
dialog.
X-original-commit: 32d211a6fd5c121fa5f556f1d78b79421edc6f68
Part-of: odoo/odoo#102149
Before this commit, with its default props, the SelectCreateDialog
displayed a "Create" button in its footer, but clicking on it does
nothing.
This commit simply opens a FormViewDialog to create a new record
of the given model, like in legacy. This default behavior can still
be overridden thanks to the props "onCreateEdit".
X-original-commit: 3afaad687e8ca8cb34a7bf7121e75a5a583762ed
Part-of: odoo/odoo#101819
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
*: hr_org_chart,l10n_gcc_invoice_stock_account,mail,point_of_sale,
purchase,website,website_sale,website_sale_autocomplete,
website_slides_survey
Some commit have added old Bootstrap 4 classes after the merge of
Bootstrap 5.
Note that it's not possible anymore as the merge bot is now able to
detect it.
closesodoo/odoo#98349
Related: odoo/enterprise#30551
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Have an editable list view, displaying a many2many tags field. The m2m field
has a context, mentioning `active_id`. (`context="{'default_field': active_id}"`)
"basic context keys" is to be understood as the usual suspects: active_id, active_ids, current_company_id, active_model
Type something in the m2m input, and selet create and edit, in order to create a new record in a dialog form view.
Before this commit, there was a crash because active_id was not present in the evaluation context.
After this commit, the new record opens in its form view, with the right value for the field that must have a default.
closesodoo/odoo#96910
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Doing a `search_count` on millions of records could be very slow. On
large databases, the pager counter "1-80 / 8000000" could take several
seconds just to get the total number of records.
This commit limits the counter in list and kanban views to 10k records,
and shows "1-80 / 10000+" if the limit is reached. If you click on
10000+, it updates with the real count (or if you go up to 10000 with
pager or input value).
The search_count on res.partner of odoo.com takes 4s. With this patch,
it will take ~20ms.
Task 2761165
closesodoo/odoo#95642
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Damien Bouvy <dbo@odoo.com>
When unselecting an export template, the list was empty
instead of just keeping the current list. I also added
some tests for this component introduced in Owl recently.
Some scss changes have been done to remove unnecessary
lines from the file and fix the style in a small window.
With a small window, items from the export list are not
draggable and the list must be placed at the bottom
part of the dialog
closesodoo/odoo#95226
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit introduces the new kanban, list and form views written
in owl. Even though it contains the implementation of those 3 views,
only the kanban view is activated for now (the list and form views
aren't 100% ready yet, so they aren't added to the view registry).
Alongside the views, the fields (<field name="..."/> in archs) and
widgets (<widget name="..." in archs) of web/ have been implemented
in owl as well. Legacy ones remaining in other addons are supported
in our new views, thanks to a compatibility layer. The goal is to convert
them asap though.
Legacy views, fields and widgets are kept for now, which explains the
number of added lines in this PR (around half of them concern tests).
They are still extended by custom code in other addons, that still need
to be converted (a lot of them are already on the way). Moreover,
they are still used in Studio as well. The plan is to lazy load them in
the Studio bundle when all custom code extending them will be
converted. Studio will be converted for v17.
Part-of: odoo/odoo#92475
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
Pierre Paridans