Follow-up of https://github.com/odoo/odoo/pull/134277
This reverts commit 91b80fbb5c as it adds some unwanted visual
effect. In other words, the "block UI" is never unblocked when some
actions are triggered. this is specific to the mobile app when the
URL is outside of the webview scope ("/web" or "/pos"). Even if
the target is self, the mobile app forces a new tab because opening
something else that the backend in the webview could disturb users.
Steps to reproduce:
- Open "Field Service"
- Choose a task and start it
- Stop it and confirm time spent
- Sign report
=> A new tab is openened in the mobile app and the block UI is
never unblock in the app.
To fix this, we simply decided to avoid to use the block UI for
act_url actions. this is consistent with what we did previously:
See https://github.com/odoo/odoo/commit/ebe64aafacec8eaa69a5a1781fc159ff77bc884a
We will only use `BlockUI` when really necessary and not by default.
Note that this commit will also remove the block UI when you do
some operations on apps like installing it. For now, we consider
that is OK. This means that the user will be able to continue his
work during installation. Also note that if the user navigates to
another application during the process, the page will not be refreshed
at the end. He will have to do it himself by pressing "F5" to be able
to see the app in the home menu.
In the future, the idea should be to better notify the user at the end
of this king of background operations but we will see...
closesodoo/odoo#142656
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
Before this commit, if the value of an image/sign field is modified by an
onchange and the record is saved manually, the old image is displayed.
Why:
ImageField's rawCacheKey, which is used to know if the image has been updated,
is not updated. So we will reuse the old image.
Solution:
rawCacheKey becomes a getter that always returns the current value of __last_updated.
How to reproduce:
- Go to a form view with a char field and an image field
- Edit the char field
- An onchange is performed and modifies the value of the image field
- The new image is displayed
- Click on the save button
Before this commit:
The old image is displayed
After this commit:
The new image is displayed
closesodoo/odoo#142471
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Using the OdooEditor, the following use case arises often:
- create an Element with document.createElement.
- append that node into the DOM tree of an iframe.
- spawn a popover with that node as target.
The spec (https://developer.mozilla.org/en-US/docs/Web/API/Document/importNode) considers this a malpractice:
`Before they can be inserted into the current document, nodes from external documents should either be:
cloned using document.importNode(); or
adopted using document.adoptNode().
Note: Although Firefox doesn't currently enforce this rule, we encourage you to follow this rule for improved future compatibility.`
Before this commit, in debug mode, there was a crash because the class of the new Element
did not match the class of the element's ownerDocument defaultView.
After this commit, we keep the check that says that the target should be an instance of
the iframe's document's Element class, but we fallback onto the main Window Element class as well.
closesodoo/odoo#142464
X-original-commit: 0cdd8cf9354e494c3e56d9eefe81c3fb6a59ac09
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps:
- Open Projects
- Go to Tasks
- Open Activity view
- There is a button to assign a new user
Issue:
- The button to assign a new user should only be visible on hover
Cause:
- There was no css class added for button in activity record.
Fix:
- By making button visibility hidden by default and should be visible only on
hover.
closesodoo/odoo#142381
Task: 3522113
X-original-commit: d60519ae4cb3c9c7d83e8143c3015c28b2a929ad
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Prior to this commit, the alignment of the `priority` field star inside
the header of the `kanban card` was not perfect.
Adding `margin: auto` fixes this issue.
task-3586924
closesodoo/odoo#141506
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
- Install eLearning
- Create or go to an existing course.
- Add Content
- Fill the name and use Save & Close
- Click again in the same content we have just created.
- Click on website preview.
Issue:
Saving a record from a form view that is part of an x2many field would
only reload the fields present in the list view. This led to incomplete
data being loaded into the model.
Solution:
- Pass the `viewType` option to `_fetchRecord` to ensure that the record
is reloaded in the context of the form view, thereby including all
fields.
- Add `viewType` to the `saveOptions` in the `basic_relational_model.js`
to ensure the correct view context is used during the save operation.
This ensures that all fields are reloaded into the model, providing a
complete view of the data.
opw-3330010
closesodoo/odoo#139968
X-original-commit: 3cec34e659222073b0fba36983eaec9f7bf5514f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Be logged in multiple companies (A and B).
Be on a form view of some record which is visible only on company B via ir.rules.
With the company switcher, unlog from company B.
Before this commit, the user received an AccessError and arrived on a blank webclient.
To say the least, it was rather inelegant.
After this commit, the user ends up on the multi-record view of that model, provided that it is available for use.
Task-3029616
closesodoo/odoo#141796
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The cog menu in the control panel (displayed next to breadcrumbs)
has a shortcut, so it is available in the command palette. However,
as is has no text content and no title/tooltip, the command palette
displays "No description provided". This commit adds a tooltip on
the icon, which is thus also displayed in the command palette.
closesodoo/odoo#141913
X-original-commit: 991e2e75d20bbb56b080c97e6b5ca96b746de3f3
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, if we have x2many fields which contain a virtual
record with the many2many_tags widget, a server error will occur during
a search because the "name_search" will be performed with a domain containing
a virtualId.
This commit will therefore filter the virtualId when generating the domain
used by the "name_search".
closesodoo/odoo#141269
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a form view with an x2many in non-editable list mode,
creating a record by clicking on "Save&New" allows it to be edited inline
despite the list view not being editable. The purpose of this commit is
to prevent this from happening.
How to reproduce:
- Go to a form view with an x2many field in non-editable list mode
- Add a record
- Edit the new record
- Click on Save&New
- Edit the new record
Before this commit:
The new record is in edition in the list view
After this commit
The new record is not in edition in the list view
Part-of: odoo/odoo#141269
Before this commit, in an editable list view (or in x2many), you need
to click twice on a boolean field to change its value. The first to set
the record to edit and the second to toggle the value.
The purpose of this commit is to simplify this flow by only requiring one click.
How to reproduce:
- Go to a form view with an x2many in editable list mode that contains a boolean field.
- Click on the boolean field of the first record
Before this commit:
The record goes to edition and the value of the field has not changed.
After this commit;
The record goes to edition and the value of the field has changed.
closesodoo/odoo#141153
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The recent use of owl AutoComplete component in the website builder
broke some things (see [1]). This commit handles this bug:
Steps to reproduce:
- Go to /web?debug=1
- Go to the website app
- Enter edit mode
- Drop the text-image snippet
=> Traceback
This was because the AutoCompleteWithPages extension of website was
inheriting the AutoComplete props whose "value" prop was not optional
but was not used for this case.
This commit goes the easy way: make the original prop optional with the
default value being the empty string.
[1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bedclosesodoo/odoo#141751
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When there are multiple broken XML files in an assets bundle. During the
bundle processing, a template containing the parsing error message is
returned for each XML file that is broken.
Before this commit, each of the returned templates had the same name,
raising another error ("Template already exists in module").
Now, all the returned templates has unique names.
closesodoo/odoo#141568
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Administrators sometimes machine-translate Odoo into their own language.
In this respect, we should avoid ambiguous wording* that could be poorly
machine-translated.
\*: in this case, the onomatopoeia "Poof!" was misinterpreted by a
machine-translation as a British slur.
opw-3590503
closesodoo/odoo#141723
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Since [1], when an error exists in an asset, the assets raise a not
found exception. The issue, is that, there is no feedback for the
developer to find the error.
Now, a new console log with the error details is shown.
[1] : bf3b6b0b8bclosesodoo/odoo#141705
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
If a .map is missing (outdated) the error message will report
'min' expected in extension in non debug mode
when the problem is actually that map are not generate through this
route.
If the attachment corresponding to a .map is not found, it
was most likely garbage collected.
Change the message to:
.map should have been generated through debug assets, (version
5eff983 most likely outdated)
closesodoo/odoo#141469
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit fixes the missing caret in some of the selection fields inside
the settings.
It is not possible to fix it another way than adding a `:not` targeting
the settings `formView`, because the `formView` css rule is overriding any
css in settings.
The caret was also hidden in the `datepicker` field.
This commit also change the `$-down-arrow` variable to a global one,
`$o-caret-down`.
task-3451370
Related to task-3326263
closesodoo/odoo#141672
X-original-commit: e01d4211cd36bd1a7d4ad190c89d3c966ec3e41e
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, a component couldn't be mounted on a public widget
that wasn't yet attached in the dom.
closesodoo/odoo#141665
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, a grouped kanban view with create="0" on the
root node would still allow to quick create record in columns (i.e.
the "+" icon would still be displayed). However, clicking on it
would most likely raise an AccessError as the user isn't allowed to
create records.
This commit restores the pre 16.0 behavior, which is to disallow
quick creation if the user can't create.
Task 3559638
closesodoo/odoo#141631
X-original-commit: 775475aaed6ea88f54a6530b81f35f3114431716
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Impacted versions:
16.0+
How to reproduce:
- create a lot of articles in Knowledge (i.e. 3000+)
- click twice on the `Search Articles` fake search bar in the Knowledge Form
view
Current behavior:
- the command palette does not open
- the command palette is broken and won't open again (even with the `CTRL+K`
shortcut)
Expected behavior:
- the command palette open once and should not break even if the user clicks
multiple times.
Technical explanation:
- The promise given to the `onWillStart` hook of the `command_palette` can
sometimes never be resolved by design (see `KeepLast`). i.e.:
- `setCommandPaletteConfig` is called `onWillStart`
- `setCommandPaletteConfig` is then called as a result of the `SET-CONFIG`
bus event
- the first promise will never be resolved since it uses a `KeepLast`,
therefore `onWillStart` will never be resolved either.
- In `command_service`, the variable `isPaletteOpened` is set to `true` before
the command palette dialog is actually mounted.
- If `onWillStart` is never resolved, the component will never be mounted, and
as such the dialog can never be closed, therefore `isPaletteOpened` stays
`true` forever resulting in a deadlock preventing any further opening of the
command palette.
The issue can be resolved by adding all `KeepLast` promises in a race, which is
what `onWillStart` should actually be waiting for, since it will be resolved as
soon as any `KeepLast` promise is resolved.
task-3554068
closesodoo/odoo#141613
X-original-commit: 6b5fc71e67569b93b699090b225eea147ef463d2
Related: odoo/enterprise#50466
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
Before this commit, in the settings page on mobile mode, when swiping
between the different apps, on the app selector the current app stay
selected on the right corner. The selected app will stay on top of the
other apps, and the app selector itself didn't move.
Now, when swiping between the different apps, the app selector moves to
force the current app to be in the center of the selector.
closesodoo/odoo#141524
Task-id: 3489756
X-original-commit: d35bddfc2cab706d19d33c3335bbae54acd27fbf
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This reverts commit 9682cfa174fb39ec9d9874951ea9ee2884058d96.
The reverted commit introduced more issues than it resolved.
The original issue [1] will still be present but
we will take time to fix it properly after the OXP2023 event.
[1]: https://github.com/odoo/odoo/assets/1159815/8d4c75c7-cb5f-4a84-8333-389971ab436dclosesodoo/odoo#141550
X-original-commit: a07e3c6aeacbfea6da249b794c05295461d20036
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
On "small screen" (especially on Mobile), all dialogs are in fullscreen,
so we don't allow moving the dialog as there is no enough space
available on the screen.
This commit disallows the use of `useDialogDraggable` on "small screen".
Steps to reproduce:
* Open Odoo in "small screen"
* Go to Sale App
* Create a new SO
* Click on the Customer field
* Use the mouse to move the fullscreen dialog (modal's header) => BUG
closesodoo/odoo#141482
X-original-commit: c5f2bd38a3175d7a4ce471dbb91a54f0c3378d10
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Commit 70f853aab9 introduces `oi-smile-add` UI icon but it also
removes by mistake `oi-text-effect` icon.
This commit reintroduces `oi-text-effect` icon.
task-3586386
closesodoo/odoo#141408
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Have the model field selector popover open, modify the path in the
debug input (bottom input available when isDebugMode=true), then close
the popover by clicking away. The model field selector is correctly
updated but its parent does not receive the right path. This happens
because onClose is called before the function update passed to the
popover is called.
Here we make the popover communicate its current path on each input
event so that if the popover has to be closed, the model field selector
knows which path to communicate to its parent.
closesodoo/odoo#141362
X-original-commit: 6a4e4221a1daa474217070f6a78602a962bbcf65
Related: odoo/enterprise#50337
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Since the refactoring of the model selector [https://github.com/odoo/odoo/commit/ebf646b44f747567ff8788c884f7f18dffd453e0], it is now more possible
to clear a selected field name (i.e. reset the path to "").
This has lead to an unsatisfactory situation when creating filters in a
spreadsheed. Indeed, the proper functioning of the interface was heavily
relying on that possibility.
In this fix, we introduce a new prop "allowEmpty" that if set to true
allows to clear the selected path and improve the display of falsy paths:
for a falsy path, the model field selector is empty and does not have a
warning message.
X-original-commit: 0244b0a7092b4c68e9f5cd4926b3017ea32b91de
Part-of: odoo/odoo#141362
The date/datetime values produced in the domain selector for
date/datetime fields are not localized (like they are in the date
picker) when presented in :
- the domain selector in readonly mode
- the facets edited/created from the domain selector dialog
Here we make sure that the localization parameters are used when we
display date/datetime values in the domain descriptions.
closesodoo/odoo#141304
X-original-commit: bd1f5dc017a2549889002d5ff5382cbd3be6580b
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Steps to reproduce:
- Create a form view with a `div` with class `oe_button_box` and an
invisible modifier inside a `sheet` tag
- Open the form view
=> The invisible modifier is not applied on the button box.
Since https://github.com/odoo/odoo/pull/116641, the invisible modifier
set on a button box inside a sheet tag is **replaced** by a condition
that check if the form is displayed in a dialog. This is not correct,
the invisible modifier should be **extended** with the dialog condition.
closesodoo/odoo#141259
X-original-commit: 570a1a9bf3e7c3012c516beb8850f320a6cc8f63
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
In many situations, when you click on a button, you want to disable all
the other buttons while it is running.
Currently, in each of these situations, we duplicate the same code that
disabled all the buttons and enabled them afterwards. Unfortunately, in
many cases, if the code executed crashes, the buttons are not enabled.
In this commit, we're going to create a helper so that we have a single
version of the code that correctly handles crashes. This helper will
disabled all the buttons, then execute the click code and enabled all the
buttons afterwards. If the code crashes, it will also enbaled them.
The problem has been reported for the Settings Form view:
When you edit this view and click save, if an error occurs in the save,
all the buttons remain disabled.
closesodoo/odoo#140938
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a many2many_tags field with onchange and on a slow network, quickly
add or remove tags several times. Each call to update sends a command 6
(SET) based on the current state of the record (typically here,
the very initial state). For example, if there're 2 tags [1, 2] in the
relation and I add 3, a command 6 with ids [1, 2, 3] is sent. If I
quickly add 4 before the onchange returns, another command 6 with ids
[1, 2, 4] is sent. At the end, 3 would not have been added to the
relation.
With this commit, we don't use the command "set" anymore. Instead, we
use a combinaison of commands "link" and "unlink" to add and remove
records from the relation. This way, we don't need to know the current
state of the record, and we can be sure that the final state of the
relation is the one we expect.
Task-id 3522153
closesodoo/odoo#140644
Related: odoo/enterprise#49995
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce
==================
1. Open marketing automation and select any campaign.
2. Click 'edit' on activity or click 'add new activity'.
3. Select existing mail template and open it to edit the template.
4. Select template on mail body page and click fullscreen from snippet.
The activity modal dialog appear at top of everything.
Technical
=========
In prior version, the 'owl_dialog.js' file includes a 'display' function that
applies the 'o_inactive_modal' class to the inactive dialog, adjusting its
z-index. However in master, the commit https://github.com/odoo/odoo/commit/036307ba260ef1a08e80a14f7cffe1ef9a24021c removes the'owl_dialog.js'
file, resulting in the class no longer being applied.
After this commit
=================
The 'o_inactive_modal' class is applied based on the state 'data' to
position the dialog below the fullscreen editor.
Task-3512850
closesodoo/odoo#139165
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Prior to this commit, "Add a Reaction/emoji" and "View Reactions"
buttons had the same icon, which was confusing.
This PR adapts the "Add a Reaction/emoji" icon to make it more
recognizable.
task-3577008
closesodoo/odoo#140481
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When a request to the server takes more than 3 seconds, the blockUI
then prevents the user from taking another action. For example, when
you want to apply several filters quickly, the blockUI appears and,
in the end, you may want to apply yet another filter.
In this commit, we remove the blockUI because we believe that blocking
the user makes little sense. This only makes sense when installing
a new application.
task-3279095
closesodoo/odoo#140042
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When discuss is not installed, hovering a facet in the searchbar makes
the cog overlap the icon/text.
This is due to the `o-bg-inherit` class which is set in the mail module.
Therefore if discuss is not installed, the SCSS for the background
doesn't exist.
This commit moves the `o-bg-inherit` as a new utility class `bg-inherit`
, allowing it to be used even if no apps are installed.
Therefore also renaming the occurences of `o-bg-inherit` into
`bg-inherit`.
task-3575837
closesodoo/odoo#140334
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In f0b7838f the event_barcode was moved from enterprise to community, so
the menu for the registration desk changed. As this menu was blacklisted
in the clickbot, it started to fail in the nightly tests.
While at it:
* remove useless and noisy log
* log when a menu is skipped instead of telling that it was tested
closesodoo/odoo#140805
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit fixes a contrast and readability issue on the active tab
within Settings on small devices.
Prior to this commit, an active tab on mobile view would use a primary
background, while nothing would be declared for its text color.
This would cause readability issue, with a dark text on a primary
background.
To avoid this kind of issue, we set a `text-bg-primary` class to our
button to ensure it gets readable, and also set a `shadow-none` to
prevent the `tip` of the tab to appear in mobile, since it would use
another color.
task-3580676
closesodoo/odoo#140751
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
This commit, fix the issue that some tests fails on other month than
October, this occurs because the current date wasn't patched on the
tests.
Moreover, this commit removes the log "Clicking on: Control Panel menu",
this log is not very important, and can increase significantly the size
of the log.# with '#' will be ignored, and an empty message aborts the
commit.
closesodoo/odoo#140728
X-original-commit: 3538513c87098aab21bd2224fbf6a338ffd5b577
Related: odoo/enterprise#50046
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The MacroEngine has a stop function that allows to completely
disable it. Before this commit, it correctly disconnected the
"main" mutation observer, but it didn't disconnect the mutation
observer for iframes.
In web_tour tests, we mock the MacroEngine to stop it at the end
of tests, but this didn't stop the iframe mutation observer.
This had an highly undesirable side-effect in tests: the qunit
suite stopped during mass_mailing tests, because the iframe
mutation observer detected a change which produced the log of
"test successful", which ended the whole suite. Some tests were
thus never run anymore (fortunately, we're only talking about a
few qunit modules).
closesodoo/odoo#141143
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
**Before this commit**
Open within a dialog a popover that has a child
using the useAutofocus hook.
As the dialog has become the UI active element,
and as the popover's element tree is a sibling
of the dialog element (since both use the overlay
service): the autofocus mechanism wanted by the
popover's child does not work at all.
**After this commit**
The popovers now can also become the UI active
element, leading to the above use case to work properly.
closesodoo/odoo#140885
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
**Good to know first**
The UI active element takership system is
directly bound to the focus trap mechanism.
**Before this commit**
If an element become the UI active element but has no
tabable elements in its tree, we force its tabindex
to the -1 value to make it programmatically focusable.
That way we ensure the focus is effectively trapped.
**After this commit**
The tabindex is no more forced at all.
Instead, if we detect that there are no tabable elements
inside the UI active element candidate, it simply does not
become the UI active element.
In other words, this commit kind of weakens the focus trap.
But this is perfectly fine for our use cases, i.e.:
- dialogs always have at least one focusable button (close, ok...)
- the website wysiwyg-adapter has a ton of focusable elements
**Why ?**
We need this change to permit other UI pieces to make use of
the active element takeover mechanism, i.e. popovers.
Part-of: odoo/odoo#140885
**Before this commit**
If a UI active element taker has its first or last
tabable element rendered conditionnaly, the focus trap mechanism will
not work properly.
**After this commit**
It works as intended.
Part-of: odoo/odoo#140885
Adrien Dieudonné