💇 for that button.
closesodoo/odoo#37801
X-original-commit: bdb4896fb310920195ed6a1f13322f91f94d3350
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
*:board,hr_skills
Hold on tight, this is a tricky one.
Allows *any* readonly list view (only plain lists, not x2manies) to
become partially editable when checking records.
This means that once checked, a record line acts just like it was
in an editable list. You can click on it, edit any of its values as long as
they're not constrained by readonly modifiers, and save them on the fly.
Clicking on an unchecked record will have the same effect as before:
it will open the record, regardless of the other selected records.
You can also check multiple records and edit them all at once by
changing the value of one selected record (just like standard multi edition).
Keyboard navigation is also allowed between selected records (TAB and SHIFT+TAB
to navigate and ENTER to save).
/!\ If a list is only made of records having all of their fields locked by
readonly modifiers, checking a record and clicking on it will do absolutely
nothing. This is to keep consistency with the rest of the specs.
Task 1967602
The main aim of the present refactoring is twofold:
- simplify the code that was largely complexified at the time of the
introduction of comparisons in the pivot view (Time Ranges menu),
- factorize the method expandHeader and _loadData that were too much complex.
Along the way, the pivot model structure has been simplified
and many tests have been added.
Performances in mobile mode have been improved by avoiding
unecessary operations due to useless column groupbys in that
mode.
It should now be easier to understand and modify the pivot view in future.
Co-Authored-By: Aaron Bohy <aab@odoo.com>
closesodoo/odoo#33615
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Following f4fbaf1efa
which changes the label/checkbox structure into:
```
<div class="custom-control custom-checkbox">
<input type="checkbox" class="custom-control-input" id="customCheck1">
<label class="custom-control-label" for="customCheck1">...</label>
</div>
```
So, before this commit, there may have been multiple input with the same Id.
The consequence is that, when clicking on a label, the browser would take the first Id it found
which was erroneous, because all checkboxes in Favorites menu had the same Id
In reality, the use case goes as:
- open a x2m,
- search more
- Favorites > Save current search
> click on one the two checkboxes
> The dropdown closed, without checking the box
After this commit, when clicking on the checkbox in the favorites menu
the checkbox is toggled and the dropdown stays. Also, the checkboxed have now unique ids
OPW 1974587
closesodoo/odoo#33032
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The `read` done by `_fetchRecord` in `basic_model.js` expicitly set a
`bin_size: true` in the context. That context option tells the backend
to send the size of the binary payload instead of the payload itself
thus slim the response size. Frontend widgets are then responsible to
fetch the actual payload in a separated http req.
The `search_read` done by `_searchReadUngroupedList` didn't set the
context option thus all the binary fields were sent b64 encoded along
with the `search_read` response.
opw-1963842
closesodoo/odoo#33014
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
the group by key in action context can be a single string
containing the name of a single field or a list of string
reprenting a list of field names
Before this commit, the board did not take this into account
After this commit, it does and supports both expressions
OPW 1956130
closesodoo/odoo#32471
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Several cases:
- on a dashboard viewtype, put a group by on the chart
- on a list viewtype, apply a group by and an ordered by
In both cases the parameters were not taken into account when
rendering the view in the board app
ref: 40dd121938
This was because, when saving an action for the board app
we tried to fill the "action's context" with only the contexts of:
- the search query (where context is just one of attributes)
- the ownQueryParams of the controller
Doing that, some other vital attributes, like group_by and orderedBy
where forgotten in the process. "C'est ballot!".
Also, the "real context" of those attributes was saved
as a context within the context.
But (!), the action's context will behave as a "real context" when spawning
views and controllers down the line.
After this commit, we flatten as much as possible all those nested
contexts at the time of saving the view
OPW 1944857
Commit 9214d78152 is a bit old and made
huge white spaces between graphs
Commit 89931d1749 introduces
a dedicated svg container, on which we can set a fixed height
The 250 px comes from what is being done in the web_dashboard app
with commit odoo/enterprise@1638e5d481
OPW 1944857
closesodoo/odoo#32522
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The board created out of a tree view wasn't taking the default domain of
the view.
opw-1958349
closesodoo/odoo#32240
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this rev., when there are a lot of groups in a grouped list
view, groups are displayed under several pages, whereas they were
all displayed in the same page before.
This is especially interesting with the new 'expand' attribute, to
ensure that we don't read records for a large number of groups.
By default, the groups limit is set to 80 (like records), and to 10
is the 'expand' attribute is set to true. This limit can be
overriden with the 'groups_limit' attribute.
Part of task 1915702
Before this rev., it crashed when the user clicked on a pivot cell
in the dashboard, whereas it should have performed a do_action to
open the records in a list view.
This was due to a leftover event handler (with the handler function
being actually removed) in commit 38dc5c18b.
Issue reported on the saas-12.1 migration pad.
closesodoo/odoo#31367
This rev. adapts the code of the 'Add to Dashboard' entry of the
Favotires menu, according to the large SearchView refactoring. It
also does some tweaks for the dashboard app due to the move of the
ControlPanel from the ActionManager to the controllers.
Part of task 1893568
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 commit 60f143c8e7, the dashboard
parameters did not use the parameters from the action, so some important
information could be lost.
However, in this same commit, the action context overrides the context
from the user defined views, which means that some information is lost.
For example, customized group bys are ignored.
This commit fixes the issue with some careful context manipulation.
Some special care was done to remove the groupby from the action context
if it is not empty, because that same logic is used in views.
forward port of 62cbc5f
Have a user in English, put a sale report as "favorite" (pinned to dashboard app)
Change the user's language
Before this commit, the pinned view was in English (because it was recorded that way)
After this commit, the pinned view is in the user's language.
OPW 1890664
closes#27799
Have a user in English, put a sale report as "favorite" (pinned to dashboard app)
Change the user's language
Before this commit, the pinned view was in English (because it was recorded that way)
After this commit, the pinned view is in the user's language.
OPW 1890664
closesodoo/odoo#27574
That div has been given an absolute position, which does not work inside another
div on the dashboard.
If there are other dashboard elements below, there are unusable since they are
covered by the no_content_create div.
Moreover, there is no create button on the dashboard, so we shouldn't even see
it.
It also spares us from seeing that hideous clippy-inspired smiling paper sheet.
opw 1907650
closesodoo/odoo#29076
Add a search containing a domain to dashboard. Remove that domain.
Do a new search with a different domain.
Add that search to dashboard;
the domain sent would be the concatenation of the two domains.
We make it so that only the last domain is sent, with a test.
opw 1907650
closesodoo/odoo#28843
The view_mode attribute is automatically set to the 'action' nodes
when the action is added to the dashboard using the 'Add to
dashboard' button in the searchview. However, other dashboard views
can be written by hand (see openacademy tutorial), and in this
case, we don't want to hardcode action's params (like context or
domain), as the dashboard can directly retrieve them from the
action. Same applies for the view_type, as the first view of the
action can be used, by default.
Before this rev., the second usecase wasn't handled, and it crashed
when no view_mode was specified. This rev. also ensure that the
context and domain are correctly retrieved from the action.
Closes#24088closesodoo/odoo#27519
The view_mode attribute is automatically set to the 'action' nodes
when the action is added to the dashboard using the 'Add to
dashboard' button in the searchview. However, other dashboard views
can be written by hand (see openacademy tutorial), and in this
case, we don't want to hardcode action's params (like context or
domain), as the dashboard can directly retrieve them from the
action. Same applies for the view_type, as the first view of the
action can be used, by default.
Before this rev., the second usecase wasn't handled, and it crashed
when no view_mode was specified. This rev. also ensure that the
context and domain are correctly retrieved from the action.
Closes#24088closesodoo/odoo#27517
fw-bot