[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 commit fixes the ribbons used in `kanban` and `form` views.
The SCSS uses the square root of the parent `div.ribbon` to calculate its
diagonal width and applies that width to the child `span`.
After changing the ribbon's transform-origin, we calculate the ribbon's
position based on CSS variables of the view's top padding,the height of
the ribbon and the shadow's size (to avoid it being cropped by
overflow-hidden).
By changing the values of a few of these variables in the kanban view,
we were able to remove all the specific SCSS related to ribbons in the
modules.
Other changes were applied inside some of the modules to make this
work:
- `event`: padding corrections on the kanban's cards;
- `hr_holidays: replaced `margin:0` in the SCSS with negative margin
utility classes on the element to achieve the same visual result;
- `discuss`: moved the ribbon to the parent element;
- this was also done to `discuss`, `survey` and `helpdesk`;
- `crm_team_view` in `sales_team`: the ribbon's height made it overflow
from the kanban's card. We fixed this by changing the value of one of
the CSS variables in the view's SCSS file;
- the same thing was done in `survey` and `appointment`;
- `website_event_exhibitor` had some SCSS that wasn't being used because
it uses `.o_ribbon` instead of `.ribbon`
task-2818586
Part-of: odoo/odoo#116641
Draw attention to the monthly assigned lead count when
it is exceeding the limit by changing the text color
to orange.
Task-3204763
Part-of: odoo/odoo#115326
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 introduces an optimization to reduce the number of read
operations performed in kanban views that are grouped by a field with
a group_by_tooltip. Specifically, we now fetch the required values
from group_by_tooltip only when the tooltip is first opened, instead
of performing a read every time the view is loaded.
Part of Task: 3179751
closesodoo/odoo#117758
Related: odoo/enterprise#39349
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>
The allow_group_range_value option is used in one arch of a kanban in
CRM. We therefore believe that this is not standard behaviour.
So we decided to move this logic to the custom view that uses it.
Part of Task: 3179751
closesodoo/odoo#117023
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: crm
Before this commit, the KanbanColumnQuickCreate receives
the groupByFieldString property as a string.
This commit changes that in order to give the groupByField object.
This change eases the further work in same pull request.
Taskid: 3246042
Part-of: odoo/odoo#115909
The web client has a mechanism to invalidate the action and the view
cache: in the basic model (and the relationalmodel), some code is
looking for updates to some specific models (such as ir.actions) and
trigger a `CLEAR-CACHE` event. This event is then listened by the action
and view services to properly clear the caches. This mechanism was also
used to reload the page after editing a company, or reloading the
currencies after editing some currency.
With this commit, we modify the orm service to trigger an event after
each rpc. This event can then be used by the action/view service, and
also by the currency/company services to perform their specific cleanup.
This work is one step in the future refactoring of the relational model.
closesodoo/odoo#115655
Related: odoo/enterprise#38814
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@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>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@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>
Applies minor fixups to improve owl usage in CRM, following the JS team advice:
https://github.com/odoo/odoo/pull/104975
* remove unused export
* use orm service from model
* remove redundancy for component call
Task-3056665
Part-of: odoo/odoo#109882
This commit makes the kanban group header sticky, it means that when
the user scrolls the headers will still be visible on top of the view.
closesodoo/odoo#109060
Task: 2050014
Related: odoo/enterprise#35611
Signed-off-by: Aaron Bohy (aab) <aab@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>
The purpose of this commit is to add extension points that allow code
to be executed before and after the save of a record.
CallBack:
onWillSaveRecord is a callBack that will be executed before the
record save if the record is valid if the record is valid.
If it returns false, it will prevent the save.
onRecordSaved is a callBack that will be executed after the save
if it was done. It will therefore not be executed if the record
is invalid or if a server error is thrown.
This commit will replace all the save overrides by the onWillSaveRecord
and onRecordSaved callBack.
Observed problem:
We could notice that each of the overrides of save in order to execute
for example a doAction after this one did not take into account the fact
that the save did not succeed.
For example, a required field is invalid and we try to save, then the
doAction will be executed without the "write" of the save.
The callBack onRecordSaved will prevent this common error.
closesodoo/odoo#105180
Related: odoo/enterprise#33710
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to avoid the execution of code depending
on the validity of the save of a Record.
Before this commit, several override save functions in Record execute
code after the record's save without checking if the record's save has
taken place.
Override before:
export class NewRecord extends Record {
async save() {
const isSaved = await super.save(...arguments);
// doAction
return isSaved;
}
}
Override after:
export class NewRecord extends Record {
async save() {
const isSaved = await super.save(...arguments);
if (isSaved) {
// doAction
}
return isSaved;
}
}
How to reproduce the problem:
Go to a form view with a Record having its save override function.
Edit a record in such a way to have an invalid field
Click on the save button
Before this commit:
The doAction is executed
After this commit:
The doAction is not executed
Real use case
- Go to the form view of a lead in CRM
- Change stage
- Clear the name field
- Click on save button
Before this commit:
A call to get_rainbowman_message is made
After this commit:
No call to get_rainbowman_message is made.
closesodoo/odoo#105687
X-original-commit: 46b93da545b52496196624712c44599fd6467f4e
Related: odoo/enterprise#33913
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Introduce the '@mail/model' module that gathers all the stuff involved
in model definitions. This allows us to reduce the number of imports.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website, website_livechat, website_slides
Task-3056971
Part-of: odoo/odoo#105096
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>
Purpose:
In the Forecast view of the CRM module, when recurring revenues are activated,
they are not shown in the progress bar of each stage of the kanban view. Only
the prorated expected revenue (non-recurring) are shown. In the regular
kanban view, they are shown.
To display them, we extended the CrmKanban view, which already possesses this
behavior, since behaviors relevant to the CrmKanban view are also relevant
to the ForecastKanban view.
As for the forecast kanban cards, when recurring revenues are activated,
they show "regular" recurring revenues instead of "prorated" recurring
revenues. Expected revenues are prorated. This is misleading for users.
The goal is to show prorated recurring revenues instead of just
recurring revenues.
Task-2994146
Task-3006404
closesodoo/odoo#102037
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose:
--------
In sales team, the gauge showing the count of assigned leads in the members
kanban cards was not shown (only a number was displayed, the gauge had its
width and height set to 0).
"o_kanban_view" selector has been removed from the gauge's style definiton,
as the class is not present in the dom.
Task-3004227
X-original-commit: 056313dacff9f19e84add4c39b4cebc305a2c5e1
Part-of: odoo/odoo#103257
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>
Before this commit, some functions overrode the save function of the
form controller. The issue is that this function is only called when the
button save is clicked, and not when we save differently (for example,
when clicking on the breadcrumb).
To avoid this mistake the save function on the form controller was
renamed to: `saveButtonClicked`, and the code that overrode the function
now override the save function of the Record, that it's called at each
time a save is perform.
X-original-commit: b6e3d833e6131562084eb13b2955c22f50ad1e79
Part-of: odoo/odoo#102992
Model patches are now defined using the `registerPatch` function. This
function takes an object as argument which keys match those of a model
definition.
Benefits:
+ More consistent shape between model definitions and patch definitions
+ No need to import one function to each type of patch
+ No need to repeat the model name for each type of patch
+ No need to import the original definition
Task-2998282.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website_livechat, website_slides
closesodoo/odoo#101827
X-original-commit: 7d23491b44b7372209057ea2abc565a95710b316
Related: odoo/enterprise#32136
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@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>
A crash would occur when creating new records as the code did not take
into account the possibility of having empty "base" data.
closesodoo/odoo#100973
X-original-commit: 497db878fa3f9303ce33035d5737352289c4f97d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
There was an issue with the computed `read_group` `__range` when grouping on
the same date/datetime field on multiple granularities (i.e. month, week).
Since the range was stored with the field_name as a key, the last evaluated
range would override the previous ones.
Impacted Versions:
- master
(- exists since 15.0 but it does not impact the user directly so it has been
decided to fix this only in master, since the API is modified)
Steps to reproduce:
1. Open a list view and group by a date field with at least 2 granularities
2. Open the chrome debugger (network) and check a web_read_group rpc preview
3. Find the web_read_group for groups related to one of the largest
granularities and check the `__range`
Current behavior:
- `__range = {field_name: false}`
Expected behavior:
- `__range = {field_name: {from: range_start, to: range_end}`
Explanation
Since the smaller granularities are evaluated last, and the condition to update
`__range` is related to the field_name and not the granularity, the range is
always overriden by the smaller granularities (even if their value is False)
when grouping on the same field with multiple granularities.
Furthermore, there is a conceptual problem with the current solution: it does
not allow to store multiple ranges when the read_group is not lazy and when
grouping on the same field with multiple granularities.
Therefore, the proposed solution is to use the full groupby keys in the
`__range` to allow storing multiple ranges depending on granularity. The keys
in `__range` would thus match the group value keys and allow more flexibility
if a domain must be forged from the group(s) range(s).
Task-2894519
closesodoo/odoo#95193
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The logic not identical in BS4 -> BS5
The color contrast system in BS5 relies on WCAG 2.0 contrast algo.
So color-yiq is converted to color-contrast.
Note that there are some "texts/buttons/other visuals" elements
which will not have the same contrast as before.
$yiq-text-dark and $yiq-text-light are respectively replaced with
$color-contrast-dark and $color-contrast-light.
Note that we had to use '$min-contrast-ratio: 2.2' for .o_tag_color_X badge.
Task ID: 2766483
Part-of: odoo/odoo#95450
Co-authored-by: Stefano Rigano <sri@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
This commit revamps the grouped-kanban implementation for smaller
screens (aka. mobile) by making it more "responsive" and avoiding
mobile-specific variation. It makes the implementation simpler and
closer to what the user expects from the desktop version.
In a nutshell:
- columns are displayed individually ; an horizontal scroll allows to
switch to the other ones, "snapping" to the column (aka. carroussel-like).
- each column takes 90% of the viewport's width to give a hint of its
siblings.
- each column scrolls (vertically) individually to avoid being lost when
switching from one column to another.
- folded columns are "virtually unfolded": they takes the same space as
the other ones, but content is loaded on-demand.
- some configuration modals are fullscreen for ease of use.
Part of the SCSS revamp task-2704984
task-2883057
Part-of: odoo/odoo#94134
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>
Prior to this commit branded UI components were styled exclusively in
raw SCSS using the '$o-brand-odoo' variable.
This leaded to unnecessary code repetitions since, to achieve the same
visual result, each module defined its own classes.
Visual inconsistencies were frequent too since each module defined its
own variations for interactive states (eg :hover).
This commit injects '$o-brand-odoo' into bootstrap's default
'$theme-color' map, allowing the framework to automatically generate
odoo utility/contextual classes.
These classes can be used to handle text, backgrounds, borders and
buttons wherever needed.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
closesodoo/odoo#87448
Related: odoo/enterprise#25700
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Earlier in Odoo, JS views were defined by defining 4 elements: View,
Controller, Model, Renderer. This was complex in some way, because we
wanted to inherit behaviour as well, so it was necessary to think along
multiple dimensions to understand how the code was running.
Then, with Owl, we rewrote some views, and simplified them: views were
now just a Component. Most of the common behaviour now came from the
generic View component that instantiated the concrete view with the
proper informations. In practice, views were still split in views
(which was the equivalent of the Controller of earlier views), Model and
Renderer
Now, this commit reintroduce the Controller, and change the way views
are defined: by an object with multiple metadata, and an (optional)
props function to compute the actual props used by the view.
As a result, views are now much easier to extend/modify.
closesodoo/odoo#89889
Related: odoo/enterprise#26728
Signed-off-by: Géry Debongnie <ged@odoo.com>
Pierre Paridans