Before this commit, a studio qunit test ("edit/delete menus")
sometimes failed on runbot, because it tried to click on a button
in a modal footer, but it found 3 of them, because another dialog
which was expected to be closed at that moment, was still opened.
There was no guarantee for the dialog to be closed because of the
way browser.fetch was mocked. The fetching part was ok, but the
function returned a Response object, whose `json` method is async
(setTimeout-like async, i.e. "real" ticks).
This commit mocks some functions of the returned Response instance
to ensure that, by calling nextTick after a click or whatever, the
fetch operation has been done, the body has been decoded, potential
renderings are finished and the DOM has been patched.
Runbot error 23054
closesodoo/odoo#143980
X-original-commit: 66ef3ae730a233dc510425e0a5baca2973de493e
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes an issue where the quickcreate button was missing from
the kanban view when it was grouped by a non many2one field and contained
no record yet (so that no column is shown yet).
Steps to reproduce:
-Go to a kanban view on a model with no record
-Group by as scalar value (eg: Description)
->The "New" button disappears
OPW-3459808
closesodoo/odoo#143793
X-original-commit: 112ba1cb64b5170fdefd267de8e765f87b444b56
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
When opening the calendar view in, for example, the timesheets app, the first
day of the week used for the number calculation is provided by the localization
service, which in turn requests it from the database. Because the first day of
the week is stored as a number between 1 and 7 in the res.lang model and a
value between 0 and 6 is expected by the DateEnv, offset errors can occur.
The error is fixed in various components (for example, the CalendarDatePicker
and CalendarCommonRenderer) but not in others (CalendarYearRenderer). Instead
of patching each component separately, a better solution is to require the
CalendarModel to expose a 0 to 6 firstDayOfWeek value as part of its public
interface.
opw-3389617
closesodoo/odoo#142056
X-original-commit: aea22a46515304df41dfaf427f5955824fe342f5
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Due a typo, sortedKeys were not always cleared when pruning the
new trees after an update. Consequently the method _getTableRows could be
called on a inexisting sub tree. Here we simply fix the typo and a test.
opw-3584675
closesodoo/odoo#143714
X-original-commit: 3fa2d6e418daa2b1fa0df3c8d1ca643fac4cbaa2
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Since the module loader rewrite, it now reports errors directly in the
DOM. The error alert also has the class "modal" so that in case a tour
comes accross a page with module loading errors, it will only look for
elements inside it and fail. But in the QUnit test suite, modals are
invisible by default, causing the page to be blank in those cases.
This commit adds a css rule to make sure that this error alert is shown,
and updates the code that was previously used to report these errors in
the qunit suite to instead simply check for errors reported by the
module loader.
closesodoo/odoo#143589
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, the datetime field read the value for readonly directly in
the attrs when extracting its props when available. This resulted in 2
separate bugs:
- in debug mode, props validation of the datetime picker would fail, as
it expects to receive a boolean for the `range` prop. This was caused
by the fact that required was the raw attribute (a string) instead of
the boolean and ended up being propagated to the `range` prop
- outside of debug mode, the value for required did not cause a crash
but any value for required that was not empty would be interpreted as
truthy, causing the field to always be display itself as though it is
required. In non-range mode, this is invisible, but in range mode, it
would always show the second datetime input and the arrow between the
beginning and end date, even with required being 0/False, or a python
expression that may evaluate to false
This commit fixes that by instead reading the value for required from
the dynamic infos provided to `extractProps`, which will always be a
boolean and contain the value of the evaluated expression when
appropriate.
closesodoo/odoo#143509
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The component ExpressionEditorFieldSelector used by the expression editor
to allow the selection of a field has several drawbacks:
- the fields are not alphabetically ordered
- there is no possibility to (fuzzy search) a field
- the field types are not indicated in debug mode.
- the style is different from the classical style to be found in the
domain selector.
Here we make the expression editor use a version of the ModelFieldSelector
component where the debug input is not shown. Indeed, this would require
some validation of the input value in order to prevent complex path like
user_id.company_id that are forbidden in studio for instance. Anyway,
there is not real need for such an input since it is easy to find/select
a simple path with the fuzzy search.
Task ID: 3599699
Part-of: odoo/odoo#142483
This commit fixes an issue where if one sets no_create_edit and
no_quick_create to true on a m2o while no_create is unset, no dropdown
is shown to tell the user that no record was found. Since the quick create
and create and edit options are disabled by default when create is false,
we no longer need it in the condition and can only rely on quick create
and create and edit.
task-3599696
closesodoo/odoo#143202
X-original-commit: 9da78c1b2bdd85f06e8682b99c8c481e91546ec7
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Before this commit, the modified test sometimes failed on runbot
because it couldn't click on "Create and edit..." in the many2one
dropdown. Here's what happened:
1) call editInput to write something in the many2one input
2) call selectDropdownItem to select "Create and edit..."
This was done without mocking setTimeout.
The problem is that editInput triggers the opening of the dropdown,
but as setTimeout wasn't mocked, that opening was delayed. Then,
selectDropdownItem first clicked on the input to open the dropdown,
and then clicked on the requested item. It might happen that the
click on the input actually closed the dropdown instead of opening
it, if it had been already opened via editInput. In that case, the
test failed because it couldn't click later on on "Create and edit".
This commit also improves the test utils to better log what really
happens: in this case, the dropdown isn't open at all, so we
detect that specific issue and log it with a proper message (which
is different than "the dropdown is open, but I can find the item
you're looking found).
Runbot issue 28207
closesodoo/odoo#143044
X-original-commit: 220d4325866330235ceccd61b8d1d00d8c919ba8
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the refactoring to owl, the stats in the left zone were not shown
anymore and the hover was missing.
This was because the method that fixes the xpath to match line by line
the qweb, was done on a getter and not on the data itself.
Now we replace in the prop value, from this way, in every place we use
the getter, we have fixed the data with the xpath.
/t/div -> /t[1]/div[1]
closesodoo/odoo#142912
X-original-commit: 2124057052255d86591b9f3345bf7e62fcd8d3b3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, some tests of the SwitchCompanyMenu sometimes
failed:
- "companies can be logged in even if some toggled within delay"
- "can toggle multiple companies at once"
They failed because the debounce delay between the first click to
toggle a company and the moment the company service is notified to
actually select the companies was sometimes too short for the 2 or
3 clicks on the menu to toggle companies to occur, as those clicks
are separated by nextTick(), i.e. a mix of calls to setTimeout and
requestAnimationFrame.
In tests, we patch the debounce delay to 0 by default, and before
this commit we set a delay of 50 in the two faulty tests. This
commit fixes the issue by keeping the real delay in those tests (1s),
as they aim at testing the fact that the user has the time to do
multiple clicks before committing the company changes and reloading.
Fixes runbot error 29962
closesodoo/odoo#142904
X-original-commit: 2ec65691ac11cb4216d873dcab77a84e2c35ba17
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The test 'buttons with attr "special" in dialog close the dialog'
sometimes fail on runbot because it can't click on 'Create and edit...'
inside the many2one dropdown. Before this commit, the test edited
the many2one as follows:
1) edit input to write a new value (with editInput)
2) click on the input to open the dropdown
3) click on 'Create and edit...' in the input
But calling editInput opens the dropdown (even though the opening
is a bit debounced, which is why it only failed sometimes). So it
might happens, in rare cases, that the dropdown is already opened
when we click in the input (step 2), which closes it and makes
step 3 fail.
This commit changes the test to do something similar as what we do
in many2one_tests.js: we patch setTimeout to execute the callback
directly, and thus remove the opening delay. We call editInput
which triggers the opening of the dropdown, and we click inside
the dropdown.
Runbot issue 24739
closesodoo/odoo#142863
X-original-commit: 4a011149cba968585d5e74ee4f4fff7212c729e3
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When we save a many2one in a dialog opened by the external button, we
trigger a "read" of the "display_name" to update it if the changes made
in the dialog have had an impact on it.
Before this commit, the context used for this "read" was completely wrong,
it was an unevaluated string. This commit will therefore allow you to use
the evaluated context.
closesodoo/odoo#142862
X-original-commit: 7e9c8d41f5d035a00117198539ddebdbd8b4aa7c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Since commit 3d218e1, clicking outside
a popover closes the popover and performs a preventDefault on the event.
As a consequence, changes made in the property definition popover are no
longer applied when the popover is closed by clicking outside.
Problem:
The preventDefault has the consequence of cancelling the input change
event allowing the change to be applied to the property definition when
the popover is closed.
Solution:
Remove the preventDefault by default and only use it in the case of the
calendar view, which is the only use case that wants to prevent the click
event so as not to open a record creation dialog (see commit 3d218e1).
How to reproduce the PropertyField bug:
- Go to a form view with a properties field
- Click on the edit property button
- A popover opens so that you can edit the field definition
- Type a few characters in the label input
- Click outside the popover
Before this commit:
The value inserted in the popover is ignored
After this commit:
The value inserted in the popover is applied to the property.
It is not possible to write a test reproducing this native browser behaviour.
closesodoo/odoo#142842
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Steps to reproduce:
- Purchase -> Open any RFQ/PO.
- Click on the cell containing the "forecast" button, without clicking
on the button itself.
Following 28f2622, it will generate a traceback when clicking on a cell
list from a button column.
Since button columns don't have a `name`, no `record.fields` will match
and throw a traceback, as we try to access `type` from nothing.
closesodoo/odoo#142597
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently mounting an owl application using the Odoo web framework takes
a good bit of boilerplate. This is both annoying but also creates the
opportunity to misconfigure created applications. This commit exctracts
the application creation logic to a helper function which will make it
much easier to create Owl applications correctly.
task-3580007
closesodoo/odoo#142498
Related: odoo/documentation#6493
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Open Field Service
- Go to gantt view
- Create new task
- Leave the title and customer field empty
- Save the form dialog
Issue:
- The customer required notification show in the gantt view instead of form view
dialog.
Cause:
- When we save the form 'saveRecord' method triggered and this doesn't return
anything.
Fix:
- Add the return statement in 'saveRecord' method.
task-3502839
closesodoo/odoo#142698
X-original-commit: e7d999429dcf91501b0803d32639a181277cb5f0
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
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 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>
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>
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>
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>
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>
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>
**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
Before this fix, a condition of the form (field_name, "in", expr) would
be "stringified" in such a way that expr would be wrapped in a list, e.g.
we would get by expressionFromTree the expression
field_name in [expr]
Here we prefer to keep expr as it is since we have no information on its
type at evaluation. That is we transform the above condition into
field_name in expr
closesodoo/odoo#140966
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
This commit fixes an issue with the domain field where a traceback would
be launched when an invalid domain is received. It also changes how
invalid domains are displayed in foldable domain fields so that only the
content of the domain selector component is displayed in this case.
closesodoo/odoo#140719
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit changes the behavior of the domain field such that it
performs a quick validation of the domain after it has been edited in
the debug input. This solves an issue where the isValid state was not
properly updated after debug input edition.
Part-of: odoo/odoo#140719
The clickbot test fails after October because of a hard coded month. It
needs to be refactored but let's skip it in emergency.
closesodoo/odoo#140641
X-original-commit: f9ec63dc3d865a24ec7da3f9389ce6b46fb66a83
Related: odoo/enterprise#49990
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In views with a searchbar, we want the filters to be displayed
directly when they are activated, without waiting for the view to
be reloaded. This is to provide a direct feedback to the user.
Before this commit, this didn't work in grouped kanban view with
progressbar. The regression has been introduced by [1] which moves
the progressbar logic out of the model. With [1], the rendering of
the KanbanController waits for the progressbar data to be loaded
in onWillUpdateProps, thus delaying the rendering coming from the
WithSearch when a filter is toggled.
This commit applies the same logic as for the model: we do not wait
for the loading promise in onWillUpdateProps. That way, the
rendering coming from WithSearch is synchronous, but a reload is
initiated and another rendering will be scheduled by the Controller
itself when the data will be loaded.
This commit also adds a test for the model case, as it appears that
this wasn't tested.
[1] 58ca40b032closesodoo/odoo#139967
X-original-commit: 47cf6e326f5a795984bac2138b169503c3dd099c
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Purpose:
-------
The "StockMoveX2ManyField" custom field has given rise to a new need,
that of being able to edit a record in an x2many directly or from a dialog.
This is the first use case to require the ability to do both at the same time.
This particular use case highlighted a bug preventing a change from being saved.
How to reproduce:
- Go to a form view with an x2m using a custom widget
- Open an x2m record in dialog mode
- Close the dialog
- No changes have been made to the record, so the save button is not displayed
- Edit a field in the same record
Before this commit:
The save button is not visible
After this commit:
The save button is visible.
closesodoo/odoo#140298
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Aaron Bohy