| Age | Commit message (Collapse) | Author |
|---|
|
- Install the `board` module
- Go to Accounting / Customer / Invoices
- Go to the Pivot view
- Add the view to the Dashboard
- Go to Dashboard
- Click on a cell of the pivot view to open the list view
The list view is the supplier list view instead of the customer list
views.
The root cause of the issue is that in the case of the Dashboard, we
receive an Array of Array, while in the regular access we receive an
Array of Dict. In the former case, the `_findView` returns `false` for
all views despite the fact that the correct list is already provided.
Since the views are `false`, `load_views` chooses the default views for
the model, which are in this case the supplier views.
In the Dashboard, the view is created in:
https://github.com/odoo/odoo/blob/1bdd0cc247d36c869ffdee7d501cb65d36be47a6/addons/board/static/src/js/board_view.js#L267-L274
When switching view, the action is set in:
https://github.com/odoo/odoo/blob/1bdd0cc247d36c869ffdee7d501cb65d36be47a6/addons/web/static/src/js/chrome/action_manager_act_window.js#L895
and the view is created in:
https://github.com/odoo/odoo/blob/1bdd0cc247d36c869ffdee7d501cb65d36be47a6/addons/web/static/src/js/chrome/action_manager_act_window.js#L235
The assumption that a list of dicts is received is used is several
places:
https://github.com/odoo/odoo/blob/7a35515e495d4fb8edbaf252988c8c3c144f4442/addons/web/static/src/js/views/calendar/calendar_view.js#L131
https://github.com/odoo/odoo/blob/7a35515e495d4fb8edbaf252988c8c3c144f4442/addons/web/static/src/js/views/pivot/pivot_view.js#L131
https://github.com/odoo/enterprise/blob/05a78e94073aea88b2314918cadc478a367afef0/web_cohort/static/src/js/cohort_view.js#L93
https://github.com/odoo/enterprise/blob/05a78e94073aea88b2314918cadc478a367afef0/web_grid/static/src/js/grid_view.js#L79-L84
opw-2387417
closes odoo/odoo#62686
X-original-commit: 5fc81820de49b78f70d471d0f9cc99afc874a550
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
Issue
- Install 'Dashboard'
- Try to add something to the dashboard via 'Add to my dashboard'
- Enter custom name
- Click on 'Add'
Cause
The name of the action was taken instead the input content
Solution
Take the input content
opw-2363000
closes odoo/odoo#60240
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
|
|
this commit removes unnecessary uppercase used under the favorites menu
task - 2325684
|
|
Issue
- Install Projects, Dashboard
- Project > All tasks > Graph view
- Add to dashboard
- Refresh & go to dashboard
The graph is small and it's
hard to read it
Cause
We have no min-height & chartJS computes
a height which is too small
Already fixed in previous versions with
9214d7815267d but now the class `o_graph_svg_container`
seems to be used nowhere
Solution
Change the class name & adjust height a bit
OPW-2303224
closes odoo/odoo#55218
X-original-commit: 80a46b9249bd6dada4d462cd7a11a406eb1ceba5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
|
|
Adaptation of the tests to the changes regarding the refactored search
panel and model.
Part of task 2228968
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
|
|
Adaptation of the rest of the environment to the changes regarding the
refactored search panel and model.
This commit includes the following changes:
- Since the control panel model is now part of the search model, the
view widget is responsible of its instantiation with the appropriate
API; creating an ActionModel holding the required model extensions.
- The controller is now importing/exporting the state of the entire
search model as well as the current state of the search panel (given
throught its props). Changes have been made to adapt to this behaviour.
- The multiple components linked to the control panel model have been
adapted to reflect the changes brought to it (they will now listen to
the "searchModel" instead of the "controlPanelModel").
- The `test_utils_create` methods have also been adapted to properly
instantiate a searchModel
Part of task 2228968
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
|
|
In saas-13.3, time range descriptions of a reporting view in comparison
mode were not correctly saved when adding the view to the Dashboard app.
This is no more the case (the bug has been corrected with the
introduction of the comparison menu). The present commit simply
consists in the forwart port of two (adatpted) tests of the original
commit.
closes odoo/odoo#54010
X-original-commit: 9f246a7d8f45203f7b0a9111c0ffd381b5e09052
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
The "board" module has been adapted accordingly to the recently
introduced comparison menu.
Task ID: 2245719
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
|
|
Before this change the map view (the fix could also be in web_map module
but currently all dashboard fixes are at the same location) would have
a zero height so it was not shown at all in dashboard even if it was
loaded.
With this changeset, we set a 100vh height (total height of viewport).
opw-2257146
closes #51610
closes odoo/odoo#51631
X-original-commit: c5bd63f60c8e34d8a947a6e4118ce707a2a894a6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
Issue
- Install Dashboard & Sales
- Add a graph & a list to the dashboard
- Go in the dashboard
Rendering ok
- Click on a list item
- Go back with the breadcrumb
Traceback
Cause
When going back with the breadcrumb
we retrieve the previous view controller.
https://github.com/odoo/odoo/blob/9400059073d7401789eb1a60d6a0ec6f58dfc66b/addons/web/static/src/js/chrome/action_manager_act_window.js#L457
By restoring the board controller, we
restore all the subcontrollers too.
But the actual board renderer is re-creating
controllers. This creates inconsistencies
with the view.
Solution
Remove the restored controllers
OPW-2232713
closes odoo/odoo#49728
X-original-commit: 4f3d818052d689da762d8afbf1789daaa3d39821
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
|
|
Steps to reproduce:
- install calendar and dashboard
- go to calendar > favorites > add to my dashboard
- go to dashboard
Previous behavior:
the calendar view in the dashboard does not show the main widget
because height is 0px (because the structure is different that normal
calendar view where view height is restricted based on viewport).
Current behavior:
calendar views are properly displayed in dashboard
opw-2226565
closes odoo/odoo#49709
X-original-commit: d1218004aa0b4a1840c99346baef73bc5fbb90a1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
|
|
Use of the new control panel helpers to increase consistency and change the assertions
according to the new DOM/behaviour (e.g. components removed instead of turning invisible).
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
|
|
Adaptation of the code throughout all modules to properly instantiate the newly
refactored control panel and update it accordingly.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
|
|
💇 for that button.
closes odoo/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>
closes odoo/odoo#33615
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
|
|
|
|
|
|
|
|
Oversight of previous forward-port.
|
|
|
|
Following f4fbaf1efae11e8bd3b1a2938ab765d391764a1b
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
closes odoo/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
closes odoo/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
closes odoo/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: 40dd121938552d3f88289d2e5fcd1d57a0dd01bb
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 9214d7815267d6bdad954f7e94a4bf187cea35bc is a bit old and made
huge white spaces between graphs
Commit 89931d1749e35231cc054428e1c43801d5ef3ffa 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@1638e5d4818cd459279b6040a711e259156b6f4a
OPW 1944857
closes odoo/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
closes odoo/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.
closes odoo/odoo#31367
|
|
|
|
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>
|
|
Follow-up of task 1904747
closes odoo/odoo#30853
|
|
Improve the dashboard app on mobile by :
- Hide the change layout button
- Force one column view layout
Task Id: 1904747
|
|
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 60f143c8e7b7ea2387031c968dfa0f31a288afb2, 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.
|
|
|
|
|
|
|
|
Oversight of previous forward-port
|
