[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
Before this commit, the field node id (`field_id`) uses the field name
for the first occurrence on the arch, and add an underscore and a number
for the rest of the occurrences. This can create inconsistencies when
sombody assumes that the field_id is equal to the name, and don't take
into account the possibility of multiple occurrences.
Now, a unique id is created since the first occurrence, this remove all
ambiguity between the id and the name.
Part-of task-id 3179751
closesodoo/odoo#117799
Related: odoo/enterprise#39511
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before 16.0 and the "always edit" form views, some fields allowed to
be edited in readonly (e.g. the statusbar in crm lead or project
task). Users could thus change the stage of a record in readonly and
the change was saved directly. If the field was tracked, the change
was even logged in the chatter directly. Since the form view is always
in edition now, we loose that behavior and the user must click on the
save cloud icon to manually save and see the tracking messages. To
mitigate this, those fields that were editable in readonly could save
the record directly when edited, like buttons do.
Changing the values of the following fields should automatically save
the record.
- BooleanToggleField
- PriorityField
- StateSelectionField
- StatusBarField
To accomplish this, we now unconditionally save the record when the above
mentioned fields are changed.
closesodoo/odoo#115500
Task-id: 3175672
X-original-commit: c9b7c43c69eaf87e7900801b926d3868adc36d8c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
The `forecast_filter` facet (aka Upcoming Closings) would have been combined
with other filters from the same group with a logical 'AND' while displaying an
'OR' combination. Fortunately it is currently the only item of its group so it
does not cause a problem.
This commit fix the inconsistency so that `forecast_filter` using the
forecast_search_model won't have this issue in the future.
Task-2657578
closesodoo/odoo#109996
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Replace moment calls by their equivalent with the luxon library in CRM, and make
use of date utils from the l10n module.
Task-3056665
closesodoo/odoo#109882
Related: odoo/enterprise#35777
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, there was a crash if you quickly dragged&dropped
twice the same record from a column to another (i.e. before the
first write was done). This was because we couldn't find (yet) the
record from the column we were dragging it.
This commit prevent the crash from happening.
closesodoo/odoo#109694
X-original-commit: b57238b577342d9a4c824b90eb7fa2a4b8e00a8e
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit moves some parts of the code used by the progress bar of kanban
to its own component. It is now clearer to distinguished its code from the
renderer code (see crm_kanban_renderer). Also, it allows to re-use this
component in other views without making a direct use of 'kanban' elements.
The KanbanAnimatedNumber component has simply be renamed to AnimatedNumber,
as this naming suggested the element was only used as a Kanban element. This
more generic name now indicates that the element can be imported and used in
other places.
Part-of: odoo/odoo#107916
Co-authored-by: Florent Dardenne <dafl@odoo.com>
Currently, adding members in a sales.team without the multi-company group is
not possible, the selection does not show any users.
This is because the domain field for the users search ("member_company_ids") is
not computed as none of its triggers are present in the view.
To fix this, we add the 'name' field as a fake trigger to force the
computation.
Side-note: the tour was added into the CRM module as we require this module to
have entry menus into crm.team form views.
Task-3088861
closesodoo/odoo#107352
X-original-commit: 11d24d8757a74cdf4af433bdc735460e68ba6cd2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adapts the codebase to match its enterprise counterpart
where calls to legacy cookie api (cf. web.utils.cookies) are replaced by
cookie_service ones.
closesodoo/odoo#104080
X-original-commit: 724469e19ff83e91a41c6721e334df1ad8d1c02c
Related: odoo/enterprise#33189
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Remove the field `crm_statusbar` as it dosen't have a specific
behaviour, and we can use the classic `statusbar` field instead.
closesodoo/odoo#102992
X-original-commit: 386fa0a5e448f149e75da68a02ad94dd88cc4d08
Related: odoo/enterprise#32669
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
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>
This commit shows the sum of field 'recurring_revenue_monthly' on
leads' kanban progressbar next to the sum of 'expected_revenue',
if the recurring revenu is enabled for logged in user.
taskID-2414576
closesodoo/odoo#66237
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
closesodoo/odoo#85631
Related: odoo/enterprise#24902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit orders the records coming from the mock server the same
way they are ordered by the ORM, while also allowing it to support
multiple levels of orderby.
This has been done to increase consistency in the test suite and provide
a more accurate representation of how records would be returned by the
actual server.
Some tests performed their assertions based on this previous
undeterministic system and have been adapted, either by altering
the base setup or the assertions themselves.
closesodoo/odoo#84718
Related: odoo/enterprise#24509
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
If we
1. Open a lead with an email but without partner
2. Set a partner without email on the lead
3. The warning "The email will be propagated" is visible
4. When saving the form, the email is not propagated even if the
warning message was visible
Solution
========
The reason is that, as the email was not changed, the inverse method
of this field was not called and so the email was not propagated.
The best solution would be to use "force_save" on those fields. But
this feature only works on readonly fields.
So, we simulate a real "force_save" on the email / phone, directly in
JS. That way the inverse will be called, and if necessary, the email /
phone will be propagated.
Task-2704904
closesodoo/odoo#84618
X-original-commit: 1d548c7eadcd25b97856c4769759358f86e00640
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: flch-odoo <flch@odoo.com>
Purpose
=======
When we group the record based on a boolean fields, we want to show
"Yes/No" instead of "True/False".
This has been done for the list view, the pivot view and the kanban
view.
Task-2648390
Part-of: odoo/odoo#79911
Before this commit, those tests sometimes failed because we didn't
correctly wait for the load and reload promises.
X-original-commit: f62503a56c4ec5c3de6638c5fe2138330d217eac
Part-of: odoo/odoo#78698
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit handles the adaptation of any component using the search
model's 'action' and/or 'view' key, now replaced by the environment
keys 'actionContext' and 'viewContext'.
Affected modules are:
- base_import
- board
- crm
- google_spreadsheet
- project
X-original-commit: 40f1ae87e1436192a70a8a7432eb72d379cfa6dc
Part-of: odoo/odoo#77463
The fix ff28db335fa77dadc did introduce some differences in the way
forecast filters work for a legacy or a new view. For example, let us
assume we have two filters F1 and F2 active in the same group with F2 a
forecast filter. In that situation, a legacy view would load with
domain = F1 domain AND F2 domain, and a new view would load with
domain = F1 domain OR F2 domain.
In the present commit, we harmonize the behaviors of ForecastModelExtension
and ForecastSearchModel as much as possible. We also make ForecastModelExtension
use a state received when it loads for the first time.
We have also taken the opportunity to normalize the states of the
extensions: it was not necessary to memorize forecastField (constant)
and forecastFilter (determined by the rest of the state).
closesodoo/odoo#77159
X-original-commit: 37aeb048c286f2f1a78370213635341c32ea621b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit replaces the control panel dropdowns with the new <Dropdown/> component, in order to get consistent through the new/legacy views (because the current Odoo version is in a state where some views uses the new infrastructure and some others are still not converted - see odoo/odoo#73311).
The diff seems massive, but it is mostly due to tests adaptations.
closesodoo/odoo#77001
X-original-commit: d679cd0d8ba9a2420e81a42a698763e9be2327e1
Related: odoo/enterprise#21077
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
After the conversion of the graph and pivot views done in https://github.com/odoo/odoo/pull/73311,
it was no more possible to open the forecast_graph and forecast_pivot views.
This is due to the fact that the new View component cannot manage a legacy
view: every extension of a converted view must be converted. We thus
convert forecast_graph and forecast_pivot.
closesodoo/odoo#76793
X-original-commit: ff28db335fa77dadc3198e754f1e0649811fba7b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Add a new submenu "Forecast" in "Reporting" for CRM
The Forecast shows 4 views:
1. Kanban
2. Graph
3. Pivot
4. List
Objective
Shows the short term forecast for opportunities (crm_lead) based on their
expected closing (date_deadline) and have an overview of the prorated
revenues for each period (defaults to month).
Implementation
1. Kanban
- the progressbar is using the prorated_revenue
- the forecast_field is date_deadline
- the default groupby is date_deadline
2.3. Graph, Pivot
- the measure defaults to the prorated_revenue
- the row defaults to date_deadline
4. List
- shows the prorated_revenue
The special filter "Forecast" is defined to be used by the
forecastModelExtension (JS). (define the forecast_filter context key)
The forecast_field context key is defined in the action to be used by the
forecastModelExtension and the forecastService (JS).
The demo data for opportunities is updated to spread date_deadline over 4 months
Enable drag&drop and quickCreate features for the kanban view with the use of
the allow_group_range_value <field> xml attribute
Add a "Won" flag for the forecast view to better distinguish opportunities that
need to be worked on
Test tour
Task-ID: 2243913
PR odoo/odoo#69380
ENT PR odoo/enterprise#18547
* Currently located in CRM as it is its only use. After Owl-ification of Web
Client it will probably be added as a core feature.
* Objectives:
- Kanban view:
- Kanban groups on a specific date/time field should be contiguous and show
a short term vision. Empty groups should be shown
-> FillTemporalService
-> ForecastKanbanModel
-> context.forecast_field
- Add the next period (i.e. month) with one click in the kanban view
-> ForecastKanbanRenderer
-> ForecastKanbanController
-> ForecastColumnQuickCreate
- Store specific time ranges for each granularity (year, month, ...), so
that when the user switches back to one his progress will be recovered.
(reset on page refresh)
-> FillTemporalService
- Graph, Kanban, List, Pivot views:
- Filter out data from the past (previous periods), while keeping every
records from the current period even if we are in the middle of it
-> ForecastModelExtension
-> context.forecast_filter
-> context.forecast_field
* context key `forecast_field`:
- Used to set the date/time field name, on which the forecast logic should be
applied
- This key will be used by :
a js model (for a view) / ForecastModelExtension / FillTemporalService
* ForecastModelExtension and context key `forecast_filter`:
This extension will use a filter, the groupBy value, and the
context.forecast_field to apply a custom domain constraint.
This domain constraint can also be applied by default with the
FillTemporalService, but it was decided to extract it to a filter for the user
to be able to disable it, to see "old forgotten records" and update them if
necessary. In other words, this filter enables or disables the first bound of
the domain for the read group.
- Filter "Forecast":
This filter should set the context key `forecast_filter:1`, in order
to only get future records starting from the start of the period
containing "now".
example:
now: 2021-04-26
groupBy: month
=> all records starting from 2021-04-01 match the filter
- If none of the groupBy values are the forecast_field, filters the records
on the forecast_field starting from "now"
* FillTemporalService:
This service will be used to generate or recover `FillTemporalPeriod`.
Depending on the configuration, it will return an instance handling a
certain `forecast_field`, with a certain `granularity` (hour, day, week,
month, quarter, year), for a certain `modelName`. This can be used in
multiple views to always get the same object, if it concerns the same model,
the same field and the same granularity.
The generated `FillTemporalPeriod` object is used to compute the final domain
and context to be provided to the backend `read_group`.
The objective was to limit the amount of desired groups regarding a specific
time period (cycle). Here are the cycles depending on the granularity:
granularity - cycle
-------------------------------
hour - one day
day - one week
week - one week
month - one year
quarter - one year
year - one year
In order to get a minimal amount of groups after a read_group, we can provide
an integer in the configuration : `min_groups`, which will guarantee this
amount of groups, regardless of the rest of the configuration
The default maximum amount of groups returned depends on the end of the
specific cycle reached after guaranteeing `min_groups`
We can always alter the result by directly modifying the `start` and `end`
properties of the `FillTemporalPeriod`, using the dedicated methods to do so.
Configuration of the domain with the keys `force[Start|End]Bound`
- true: applies a lower|upper bound for the domain, which means that
the subsequent read_group will search for groups [from the
start|until the end] of the FillTemporalPeriod
- false: no domain constraint applied, which means that at least every
groups with records in the database will be returned
Configuration of the context with the keys `forceFilling[From|To]`
- true: set fill_temporal.fill_[from|to], which means that at least
every groups [from the start|until the end] of the
`FillTemporalPeriod` will be returned as contiguous groups
by a read_group
- false: does not set fill_temporal.fill_[from|to], which means that
read_group will only return groups from|until the first|last
one with at least one record
The `expand` method can be used to add one interval to the end of the
`FillTemporalPeriod` depending on the granularity (add one group)
* any "forecast" view :
- should define a `forecast_field` in the context
- should use the `forecast_model_extension` with the searchModel to be able to
filter "future" records correctly
- could make use of the `FillTemporalService` to maintain a consistent domain
and context when grouping by the desired date field. The domain and
context are to be applied on __load and __reload calls in the MODEL, on the
provided domain and context, to further filter the groups returned by a
read_group.
* forecast views: graph, kanban, list, pivot
* kanban
uses: forecast_model_extension, fill_temporal_service
has a custom `column_quick_create` limited to the forecast_field which
allows to add the next group (period depends on granularity)
works with the sample_server even thought the domain and the context are
modified during the __load/__reload processes.
* graph, pivot, list
use: forecast_model_extension
Task-ID: 2243913
PR odoo/odoo#69380
This commit fixes a nondeterministic issue during the rainbowman tour.
We make sure that the record is properly created and the kanban reloaded before
moving on to the next step, ensuring that the tour completes without race
conditions.
Task-2426257
closesodoo/odoo#64921
X-original-commit: f332541bc84d6110c90d4c5e736892f185fff3df
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
This commit fixes the display of the rainbowman message when leads go through
the "won" stage.
Currently, some flows don't show the message when they are supposed to or show
the message when they are NOT supposed to.
This is because the case when the form is saved through the regular "Save"
button is not handled at all.
The CRM form controller extension was completed with the missing use case and
fixed.
An additional QUnit test ensures the correct behavior.
Task-2418294
closesodoo/odoo#63599
X-original-commit: c5cbb9975897935e9ed4e1bce80335207758fa24
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When you mark an crm.lead as "won" using the "mark as won" button, the user
will be shown a rainbowman under certain conditions. This happens notably
when you win your first lead.
This commit fixes the 'ir.actions.act_window_close' model to allow the
'effect' key within its readable fields (even if it's not a real field) which
is in turn picked up by the web client to display the infamous rainbowman.
At the same time, we add the tour that is testing the rainbowman of the crm app
in the test suite, since it was missing and never actually executed by the CI.
Some fixes were also necessary to make the test run properly.
Task ID-2394745
closesodoo/odoo#63259
X-original-commit: 47079f67f586adf45da15fc98dbc81571f7a9100
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Make sure the Rainbowman animation is rightly triggered whichever way the user
marks the opportunity as won. Especially relevant for the onboarding as we want
to show the first rainbowman to users completing the tour.
SPECIFICATIONS
Now the rainbowman and its finely-tuned message are displayed to the user when
he uses the statusbar, mark lead as won using action buttons or drag and drop
a lead in the won stage in kanban view.
LINKS
Task ID-2287758
PR #54553
CRM still holds code dead since more than 2 years about sales / crm dashboard.
Custom ugly un-onboarding not-wow headers have been removed at ea66192276.
LINKS
Related to Task ID 2092799 (not really spec, spotted while working on it)
PR odoo/odoo#42015
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.
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
*board,crm
Before this rev., the dashboard panel (e.g. of the sales team
dashboard) wasn't displayed when there were no record to display,
whereas it should. Only the nocontent helper was displayed.
This was a bug introduced with the new view: the views' controller
was in charge to display the renderer (if there were data to
display) xor the nocontent helper. As the dashboard panel was
rendered by the renderer, it couldn't be displayed alongside the
nocontent helper.
This rev. moves this logic to the renderer. So now, the controller
always contains the renderer, which decides what to render (the
data or the nocontent helper). This way, the dashboards can display
their panel and the nocontent helper.
With the new JS test framework, we had experimented with an autodestroy
feature, meaning that all views/widgets are automatically destroyed
after a while. By default, it was 50ms, because we could not hook some
code to run after the end of the current test.
For various reasons, this was not a good idea: some side effects, such
as modifications of the session or of the DOM (with modals) could
interfere with other tests. This commit disable the feature.
From now on, we will have to destroy each widgets created in a test.
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
Pierre Paridans