When we haven't provided a custom action, the tour step runs the default
action. In the final step of the tour, when there is no `run` or
`isCheck` provided, It shows warnings of 'ignoring action (auto) of last
step' as it can lead to a race condition.
This commit resolves the warnings: `ignoring action (auto) of last step`
task-3429500
closesodoo/odoo#129239
Related: odoo/enterprise#46683
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
According to the ECMAScript 2023 Language Specification:
> Module code is always strict mode code.
Odoo Modules mimic this behavior and automatically add “use strict“ at
the top of the file, so there's no need to do it yourself.
This commit removes all the useless occurrences of use strict.
closesodoo/odoo#132235
Related: odoo/enterprise#45908
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
before this commit:
after #109858
The method `update_field_translations` won't directly call the `write`
As a result, when changing the translation of fields from translation dialog,
the orm cache won't be cleared, and translations won't be updated in views
even after refresh the page
after this commit:
when users translate fields and refresh the page, the new translation can be
updated in new views
opw-3267024
closesodoo/odoo#120602
X-original-commit: 8d8dbab203fe7c153522dcb2a420d97dc4adaadb
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
*hr_timesheet,point_of_sale,website
This commit moves the settings form view implementation from base
to web, and converts it to owl.
The setting's search has been improved to take into account more
elements. Before, it was possible to only search on the field's
labels. Now, we can also search on the field's description, and
the titles of setting's group.
Part-of: odoo/odoo#78221
Co-authored-by: Samuel Degueldre <sad@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
In the settings view, we need to display the technical tip below the
setting header (h2 tag). For example, we display such tip under the
'Developer Accounts' header in social media settings.
However, when we search something in the settings, this tip is not
hidden. It happens because the hiding and showing parts of the settings
page are managed with js using some special classes or tags (like h2
tag, `.o_setting_box` class etc).
This commit fixes the issue by introducing a new class `.o_setting_tip`
specific for such technical tips, and with help of that we now hide or
show the tips based on the user search.
Note: We could have used .o_setting_box without any side-effect, but
rules linked to this class can be changed in the future and can mess
with layout of the technical tips. As those are usually small blocks of text
that give a hint to the user and not directly associated with setting box
styling, making the overall code more robust / flexible.
enterprise PR - https://github.com/odoo/enterprise/pull/25907
task-2810617
closesodoo/odoo#88117
Related: odoo/enterprise#25907
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce
- Install procurement_jit
- Go to settings
- Search for 'serv'
-> Re**serv**ation is highlighted but also ba**se**d
closesodoo/odoo#87611
X-original-commit: 8bbfbfbf0eb6c2238542166984b558b5734c7a2a
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This commit splits the 'getActionManagerTestConfig' helper into 2:
'setupWebClientServiceRegistry' and 'getActionManagerServerData'.
The first one is now automatically called by the 'createWebClient'
helper, as it properly setups the service registry with all services
required by the WebClient component.
The second one generates a few data (menus, actions, views...) that
can be used in tests. That helper is mainly useful for action tests
(formerly ActionManager tests) in web. With this refactoring, they
are no longer generated for each test in the whole codebase that
spawns a webclient, as before this commit.
closesodoo-dev/odoo#906
Related: odoo-dev/enterprise#161
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit adapts the community codebase to the rewriting of the
/web application in owl.
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>
This commit adds the auto save for editable list and form views
but not for settings.
Now with auto save, changing the pager, going back in the breadcrumb,
going to an other action or clicking on a menu item won't ask to
confirm changes if any but will automatically save them.
In settings, the confirm dialog has been revamped.
We can now decide to "Save" or "Discard" the changes or "Stay Here" to
do nothing.
task 2330101
Before this, a one2many relation in a settings view would not work.
After the save, the added data in the field would be cleared.
Now, the data is still present.
With the change made to BaseSettingsModel the 'base_settings_tests' need
to only use the res.config.settings as fake data model. (relations towards
other models are still ok though). The test file is therefore altered
to comply to this new rule.
Note that this commit only validates the good behavior on the frontend side,
as a one2many relation towards a res.settings can't be done simply in
python as it is a transient model (forbidden).
Task ID: 2274168
closesodoo/odoo#57401
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adapts the BasicModel to combine calls to `default_get` and
(first) `onchange`. When creating a new record, we now only call
`onchange`, which thus return default values and potential onchange
values.
Tests (and the MockServer) have been adapted accordingly.
NOTE 1. If the `default_get` within the `onchange` returns a value for
a field that is not in the view, we ignore it, and it won't be saved.
Before, that value was kept and sent upon save. This change in behavior
may prove problematic, although the overall risk is small. Decision has
been made to keep heavy comments and code snippets if we were to revert
back somehow to the previous situation.
NOTE 2. Putting a context on a many2one field may change the value
returned by `name_get` for that field. By default, the calls to
`name_get` are done by `onchange`. If the context on a field must be
used for `name_get`, one has to set the option `always_reload` to `True`
on the field. In that case, every `onchange` that changes the value
will trigger an extra `name_get`.
NOTE 3. Suppose that a one2many field has a list view with field A, and
a form view without field A. When adding a line, we now send all known
fields (main view and inline views) to the `onchange`, which may return
a default value for A. The value will appear on the list view, but not
in the form view. The former behavior was to call `default_get` with
the fields that occur in the form view only, and therefore field A would
be left to value `False`.
NOTE 4. A test surprisingly adds an extra call to `read`. The test was
actually wrong before. With the changes in MockServer, we now correctly
receive a command `[6, false, [1]]`, whereas before we received `[1]`,
which isn't a valid command, and which was ignored. As a consequence,
an extra `read` is done, whereas the test asserts it shouldn't. But it
already didn't work before (I checked by sending the correct command).
This needs to be bugfixed elsewhere (task-id-2323491): in a o2m with a
onchange and default order records on an other page than the first
should not trigger a `read`.
Task 2261084
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, when being in a settings form view with at
least two items in the breadcrumbs (the settings view preceeded by
another one), clicking on a button to execute an action didn't
properly work: an history back was done instead, thus returning to
the previous action.
For instance, go to Sales (without demo data), click on 'Set
payments' in the onboarding banner, click 'Go to the configuration
panel', and in the settings view click on 'Install More Packages'.
The issue has been introduced by [1], but we couldn't find a
scenario to reproduce it before saas-13.3.
[1] a3845ae3f0
Issue spotted in task 2277314
closesodoo/odoo#55351
X-original-commit: 6ccb108e9a621a672fde715ea78656ffeb6834e5
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a settings form view, do some changes, then click on a button
or link in the form (e.g. 'Manage Users' in General Settings).
We now ask if the user wants to discard the changes before leaving
the page.
Task 1921574
closesodoo/odoo#34799
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
When user will modify something in settings, there will be a message
shown that will tell the user that he/she has unsaved changes.
task-1917637
closesodoo/odoo#31900
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Before this rev., we searched for 'label' tagname into the DOM, but
the fields labels are not always inside <label> (sometimes <span>).
However, they always have className 'o_form_label', so we use this
instead.
task 1961427
closesodoo/odoo#33487
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Why reverting ?
The fact that the control panel changes width on first edit is confusing to the
user. The whole form shifts down. We want to avoid having elements appearing
and disappearing. The issue that the user does not know if he has to save is
still up to date, and will be addressed in the next saas. We will most likely
use what has been done in this task to only display 'There are unsaved
changes'. Thank you all for your work here!
Original task and revert discussion can be found on task ID 1917637 .
This reverts commit 514d6fb90d.
closesodoo/odoo#31622
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
It only makes sense to display 'Save' and 'Discard' if the user actually
changed something in the settings.
So after this commit, the 'Save' and 'Discard' buttons of statusbar in
general settings will only appear when you make any changes.
Also when there are changes, there will be a message shown that will tell
the user that he/she has unsaved changes.
The commit is related to Task ID: 1917637
Co-authored-by: Mohammed Shekha <msh@openerp.com>
closesodoo/odoo#29726
This reverts commit 01173f3745.
This commit added improvements in search and ordering of settings. However
due to DOM manipulation some events are not bound correctly. Notably saving
settings could be broken if several different tabs are modified before
saving.
After checking more in-depth settings code it appears it will be difficult
to ensure a proper re-rendering and re-ordering of settings without having
to modify deeply the code. This is therefore more a task for JS framework
team.
closesodoo/odoo#29285
Allows users to not only search on settings name but on their description too.
Improves search results relevance :
Instead of the actual fixed order, top results should be about the module
selected in the left panel
Task : #1893252
closes : #28094
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 this commit, when the user is in a form view (edit mode) and
click on a stat button, a new action is added to the action stack. When
the user then comes back to the form view by clicking on the breadcrumb,
it is supposed to be in readonly mode. Before this commit, this was not
the case.
This bug comes from the action manager refactoring, which removed the
view manager. With this commit, we add a new action lifecycle method
which is called when the action is restored.
Note that this commit implicitely changes the semantic of actions with
'target=inline'. As far as I can tell, this only applies to the settings
form view, which can easily be fixed by overriding the restore hook.
closesodoo/odoo#28663
If no value is specified on the datefield, do not set a warnfuture message
Remove code comment that was referring the condition present at b51b0d66c2
but no longer present.
Add tests
Fixes#27551closesodoo/odoo#27593
If a deferred field, for example with auth_user_policy installed:
<field name="f" password="True" widget="password_meter"/>
is inside the res_config_settings view, the rendering will be deferred
which is not taken into account when initializing the content
(_initModules) or attaching to DOM (after start).
Thus we would would get an error and have no access to settings.
The issue that happened in 12.0 was solved with 23bec7fb7 and refactored
in between in 5bbbd25ed, but the heart of the issue was not solved in
the case of a customization.
With this commit, we do not lose the deferred when it is necessary to
keep them in the case of deferred while rendering.
Without fix, the added test fails with a traceback and message:
TypeError: Cannot read property 'settingView' of undefined
opw-1890343
closes#27589
Before this commit, something strange could happen after reloading a
settings form view: all 'sections' were displayed. The issue was caused
by the fact that the state of the view was read from the arch of the
form view at render time. Also, as a form of optimization (I suppose), the
settings did not call the initModules method twice, when it rerenders.
This is unfortunate, because the very same method is actually
responsible for removing unused sections.
This fix is the safe fix, but definitely not the perfect fix (this would
involve a larger change, something like reading the state from the arch once in
the view (factory), then only rendering what is necessary).
divy-odoo