This commit fixes a bug where the value of an autocomplete with autoselect
could go into an undefined state where the model value doesn't match the
input value but no change is detected. This would happen on escape press,
scroll and more recently due to https://github.com/odoo/odoo/pull/159333
on click out. To fix this issue, the commit introduces some change in the
autocomplete behavior so that it will no longer select the active option
on click out (blur) when autoselect is active and instead it will revert
the input value to the one stored into the model. Also applies this
behavior on escape key press and scroll for the before mentioned reasons.
Steps to reproduce:
- Go to CRM form view
- Edit the salesperson name to some non existant one and click out (or
scroll or press escape)
Before the fix, the name was stuck to the invalid one but no change was
detected so we couldnt save it. Before https://github.com/odoo/odoo/pull/159333,
click out would select the active option of the dropdown instead (and
launch a dialog for quick create). This is removed because the behavior
is neither intuitive nor practical. After the fix, the name is reset to its
previous valid value instead. This applies to all autocomplete components
with autoselect prop set to true.
closesodoo/odoo#162040
X-original-commit: 9d9026ed0c7bb0af6cf910cc206cf8b55d1b7a36
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
This is a followup on [1].
In Chrome the event's currentTarget is cleared after events such as
"scroll" are handled. For asynchronously called methods to be able to
access it, the current value of currentTarget needs to be kept.
To help developers that might stumble on this issue when using
`throttleForAnimation`, this commit emphasizes the fact that usage of
that function is not limited to event handlers, and it adds a test case
that illustrates a solution for tracking the lost scroll event target.
No scenario was identified in 15.0, but this could be used as an
alternative solution for [1].
[1]: https://github.com/odoo/odoo/commit/0ba601d2ef5c4e2f846818e78dcd23966d6f563d
task-3449843
X-original-commit: 6cc4cbf2b91d624368c489460a90795921985f6b
Part-of: odoo/odoo#161850
Since [1] positioning of popovers targeting an element contained in an
iframe is permitted.
This commit will ensure the popper's element positioning is correct in
the following case: have a popper
- outside an iframe
- targeting an element that is inside it
- and no container element has been given (default is used)
**Before this commit**
The default container that is used is the target's owner document
element, a.k.a. the iframe's html element.
**After this commit**
The default container that is used is now the popper's owner document.
** Side notes **
This bug has been found when working for the following taskid-3603843
It is required for this task and will get fw-ported through the master
branch.
[1]: d6afa9f325closesodoo/odoo#161568
X-original-commit: e664b2367f482aa6edc492db16ec92ffff1ac0a1
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Previously, methods on python objects such as sets and strings were
implemented as functions returning a function returning the result.
While curried functions can be a great tool, they're also confusing at
first glance and in this particular case they can be easily replaced by
a simple function and the usage of Function.prototype.bind to bind it to
the correct argument. We also add a simple whitelist for pyjs functions
as a sanity check as it makes no sense to call JS functions from python
code.
With this change, we can also treat functions and methods from any
object more uniformly instead of having many return points that are
treated like special cases.
task-3762958
Part-of: odoo/odoo#139451
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes an issue regarding unwanted interaction between the
regular autocomplete option click selection and the onChange handler
from the input field hook used in the PartnerAutoCompleteCharField
component. This became an issue starting from https://github.com/odoo/odoo/pull/154203
because of the disappearance of the t-on-mousedown.prevent handler
placed on the autocomplete options list which would prevent the onChange
event from being triggered when clicking on an option. The issue would
be that the onChange handler from the input field hook would take
precedence over the option click handler of the autocomplete which would
most of the time be ignored afterwards. The solution found for This
problem is to prevent the immediate propagation of the change event
in the autocomplete handler when an option has been clicked on so that
it will never be propagated to the input field hook handler in this case.
Steps to reproduce:
- Go to contacts and open a company contact
- Type in the name field a few characters (at least 3)
- Click on any autocomplete option
Most of the time, the option will not be applied and the name won't change
closesodoo/odoo#160561
X-original-commit: aa1e5eabb67800fbf4155c9cae12b90d97bb75db
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
this commit fixes an issue introduced by https://github.com/odoo/odoo/pull/154203
which could keep the autocomplete options list opened even after a click
away when the user would "drag and drop" an option out of the list instead
of simply clicking on it. This is caused by the fact that the onInputBlur
code is directly terminated in this case (because of ignoreBlur) while
it is the only way for the autocomplete list to be closed in this case.
The solution is therefore to add an external listener on pointer down
which will always close the autocomplete list when clicking away from it.
Steps to reproduce:
- go to any autocomplete (crm salesperson for example)
- click on the input
- drag and drop a result outside of the list
- try to close the autocomplete list by clicking away
Before the fix, the autocomplete list would only close by scrolling
or clicking on the input once again.
X-original-commit: 57801ab7292e3d369615740a5f67aac9a4b9a521
Part-of: odoo/odoo#160561
Open the code editor (wrapper around aceEditor) with an initial value -- in Odoo, that is any instance of the code editor.
Press Ctrl+Z.
Before this commit, the value disappears -- is undone -- even though no real change happened.
This was because we used editor.setValue, instead of editor.session.setValue. The latter resetting the undo history.
This behavior is "documented" [here: Common Operations](https://ace.c9.io/#nav=howto) with:
```js
//Set and get content:
editor.setValue("the new text here");
editor.setValue("text2", -1); // set value and move cursor to the start of the text
editor.session.setValue("the new text here"); // set value and reset undo history
editor.getValue(); // or session.getValue
```
After this commit, the initial value is not undoable.
opw-3793546
closesodoo/odoo#158548
X-original-commit: b33086599383a4c0ab43126598a63e8721f682fc
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
User settings is used to store user's preferences, in web we use it
to store the home menus apps order and in mail for various settings like
push to talk key, discuss sidebar preferences, etc.
Before this commit, the `setUserSettings` method from the user service
overrided all the previous key that has not been changed because it
kept only the changed keys returned by the backend.
Leading to preferences being lost during the session when reordering the
home menu apps.
With this commit, we keep the previous keys that have not been changed.
Steps to reproduce:
- Go to the home menu
- In the Owl devtool check the settings object from the user service:
```JavaScript
{
"id": 1,
"user_id": {
"id": 2
},
"is_discuss_sidebar_category_channel_open": true,
"is_discuss_sidebar_category_chat_open": true,
"push_to_talk_key": false,
"use_push_to_talk": false,
"voice_active_duration": 0,
"volume_settings_ids": [
[
"ADD",
[]
]
],
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"project_todo.menu_todo_todos\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]",
"voip_username": false,
"voip_secret": false,
"should_call_from_another_device": false,
"external_device_number": false,
"should_auto_reject_incoming_calls": false,
"how_to_call_on_mobile": "ask",
"is_discuss_sidebar_category_whatsapp_open": true,
"onsip_auth_username": false,
"livechat_username": false,
"livechat_lang_ids": [],
"is_discuss_sidebar_category_livechat_open": true
}
```
- Reorder an app in the home menu and check again the settings object:
```JavaScript
{
"id": 1,
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"project_todo.menu_todo_todos\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]"
}
```
closesodoo/odoo#155902
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Current behaviour
- when we access the daterange picker it was observed that the apply button
appeared flatter and was not vertically centered.
Expected behaviour
- add h-100 on buttons container to ensure they are vertically centered and no
longer appear flatter
- add close button in which action is similar to pressing ESC or clicking
outside the popover
Task-3624556
closesodoo/odoo#148812
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes a pretty specific issue within autocomplete behavior
where the change event after clearing the value is prevented.
Steps to reproduce:
- go to an empty autocomplete and click on it
- start typing a search with results
- click on the first result
- without focusing out, clear the input and finally click out
No change event is triggered on click out in this case so the cleared
value is not updated in the end and saving the record will keep the
non cleared value.
The t-on-mousedown.prevent in the dropdown was mainly used to keep the
focus on the input after selecting a value for the autocomplete. This
introduces a side effect: when one starts typing on the initially empty
autocomplete, the browser keeps the initial value of the input in memory
until it is focused out (and therefore blurred). When the input is
focused out, it will compare the current value of the input with the
stored initial value and decide to trigger a change event based on the
comparison between the two values: if these are different, the change
will trigger. In our case, since the mousedown event on a search result
is prevented, no focus out will happen and therefore the browser will
still wait for the next focus out to trigger the eventual change event.
But since we clear the input before focusing out, the two values are
empty and no change event is triggered which introduces the issue.
To fix it, we remove the t-on-mousedown.prevent of the template and
manually avoid triggering the onInputBlur method with a flag to keep
the previous behavior and we finally focus on the input programatically
after selecting a value.
task-3734818
closesodoo/odoo#154448
X-original-commit: 9d3d5d937e37ab6ef0c393e11cfb449f2897f6c1
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Steps to reproduce:
1- Install Sales module
2- Activate developer mode
3- Navigate to any storable product
4- Click on 'Replenish'
5- Click on 'developer bug' and Choose 'Set Defaults'
6- Choose 'Scheduled Date' from the 'Default' dropdown menu and Save
Current behavior before PR:
When trying to set a default value for scheduled date in 'Replenish' for a product it will display an error for 'Invalid type' this is happening because when converting the string value to a datetime value it does not handle iso format date and this is the format that gets passed from the UI.
Desired behavior after PR is merged:
It is handled now from the UI side that the format that is been sent is the server valid format of datetime.
opw-3692472
closesodoo/odoo#154209
X-original-commit: 6dc46639935fdc175b2d094b58ef4e66c68466b0
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
This commit fixes an issue caused by the way we use onInput props in Knowledge to
fetch articles depending the current search value. Since we start from an empty
string in the input again, it make no sense to display the choices previously
fetched with a search value no longer displayed in the UI. The only way to display
the correct items is to update the input value, then put an empty search to fetch
accordingly.
This is clearly an issue, when the onInput props is used to fetch the content of
the SelectMenu, depending of the search value. The UI obviously display an empty
search, and filter accordingly, but without fetching the items corresponding to
the empty search value.
A test was added as well to assert SelectMenu can be used for this purpose without
forgetting to call onInput again when clearing the search value in beforeOpen.
closesodoo/odoo#153072
X-original-commit: ca417f171b1bd2dd567beed7bc0e1fcaba6c8a4c
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Steps to reproduce
==================
- Use a laptop with touch or apply the following patch
```diff
diff --git a/addons/web/static/src/core/browser/feature_detection.js b/addons/web/static/src/core/browser/feature_detection.js
index 21c6294b1b0e..64c4bc9b899c 100644
--- a/addons/web/static/src/core/browser/feature_detection.js
+++ b/addons/web/static/src/core/browser/feature_detection.js
@@ -62,6 +62,7 @@ export function isDisplayStandalone() {
}
export function hasTouch() {
+ return true;
return browser.ontouchstart !== undefined || browser.matchMedia("(pointer:coarse)").matches;
}
```
- Enable debug mode
- Go to contacts
- Hover the mouse over a question mark next to a field
=> Nothing happens
Cause of the issue
==================
The function `shouldCleanup` returns true when the device has touch and
the popover has been triggerd with the mouse
opw-3694156
closesodoo/odoo#152629
X-original-commit: 27242a0f1070b6b16c16e479e22dc0ccad0d9659
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, in the command palette, during a search, it is possible
that the value entered is modified. The problem only occurs if the namespace
has a debounceDelay bigger than 0 and at least one of its command providers is async.
How to reproduce:
=================
- Go to the command palette with the @ namespace.
- Type a few characters
- Re-enter a few characters
If you repeat this operation several times, some characters may disappear.
Why:
====
The value of the input is modified at each "input" event, but the searchValue
in the state is only modified when the debounce trigger "search".
Since the command palette template is contained in a slot, each state
change causes a complete rendering of the command palette. When the search is executed,
the commands are added to the state after each provider has generated them,
so a rendering takes place and it is the value contained in state.searchValue
that is used for the input and not the value contained in it before the rendering.
Solution:
=========
No longer modify state.searchValue during the search, but at each input event.
closesodoo/odoo#151906
X-original-commit: f4e1350e3a03c8a3a2b6bab8f4f74e278b1d2905
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Sorting is being computed on each mounted select menu during the useEffect() hook since this commit: 8a44857.
This can lead to long wait times or browser crashes when there are many select menus with many options.
Before this commit, all of the select menu were sorted when the user select a value in one of them.
This is not necessary as the sorting is already handled in beforeOpen.
After this commit, no sorting is being computed in useEffect() anymore to avoid unnecessary computation.
A test has been added to verify the sorting happens when needed.
opw-3616438
closesodoo/odoo#151318
X-original-commit: f58b88383ce6a7439c02dbe761dc9025ddfe3b0a
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Co-authored-by: Luca Vitali (luvi) <luvi@odoo.com>
This commit fixes the behavior of the SelectMenu component when an option
is being used with an empty string or a null value.
Let's suppose we have the following choices:
{ label: 'Empty', value: '' },
{ label: 'Full', value: 'full' }
Before this fix, when selecting 'Empty', the value would be selected in the
menu, but the toggler would still be empty, as if no value was selected.
Now, any value corresponding to a choice value can be selected.
A test has been added for each value supported (null and empty strings).
Part-of: odoo/odoo#151276
Before this commit, a component that uses the `usePosition` hook could
trigger multiple position update in the same tick and the update would
be call as much as it was called.
In this commit, the hook batches the calls to the update to call it
once.
closesodoo/odoo#149655
Task-id: 3673493
X-original-commit: 12fbf33aca2e9efafbb94337d9c3b538779d9f6c
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Before this commit, the searchbar menu was misplaced after opening the advanced search dialog.
After this commit, the searchbar menu is always at the correct position.
Task-id: 3673493
X-original-commit: 19d40f48fb98b28b7fd49b79581ac0ac5fcecc87
Part-of: odoo/odoo#149655
This commit fixes an annoying issue when using Odoo on a tablet or a PC when using
the touch screen primarly. The virtual keyboard popped way too much when navigating
in between views and screens, since the focus is often set on inputs (mostly the
search bar with useAutofocus).
Steps to reproduce:
- on a Windows laptop or tablet with a touch screen, open any view
- the virtual keyboard appears
- you must touch out of the keyboard to use Odoo
To fix the useAutofocus hook, hasTouch is now being used instead of relying on the size
of the screen.
Autofocus test with isSmall has been adapted to specify that touch isn't modified, and
that the autofocus is still present. And another test has been added asserting the
behavior on a touch device.
In the form renderer, the autofocus set manually on the first element is now prevented as
well, reducing the popping effect of the keyboard when opening a view. A test has been
added as well.
task-3627697
closesodoo/odoo#148925
X-original-commit: 1f2ab6d5dda61a6aad6e0e9bd282195cdd990f15
Related: odoo/enterprise#54074
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
The original issue (in saas-16.4) has been fixed in 17.0
by refactorings.
This commit only fw-ports the test
Steps to reproduce:
- Open the Subscription app
- click on the list cog wheel
- Spreadsheet > Insert list in spreadsheet
- Select the blank spreadsheet and insert the list
- right click any cell with a list function
- click on "See list properties"
=> boom `undefined is not iterable (cannot read property Symbol(Symbol.iterator))`
The list domain has the shape `["subscription_state", "not in", ["2_renewal", "5_renewed", false]]`
`false` makes the domain selector crash.
opw 3670344
closesodoo/odoo#148727
X-original-commit: cfdc9c6d62050e3aac4bf18f374e4772ce18a504
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
This commit ensures that elements returned by the getTabableElements
method of the ui utils does not return invisibe elements. This fixes an
issue with the trapFocus method of the ui service which could set an
invisible element as lastTabableEl therefore making it impossible to
loop back to the firstTabableEl when the actual last tabable element is
focused and the client presses tab. Also fix a side effect of these changes
in list renderer where focusCell would be called before the cell width
computations which would work by chance before since getTabableElements
took into account elements with 0 width but is now no longer the case.
This is fixed by moving down the onPatched method which calls focusCell
underneath the useEffect method which performs column style computations.
Steps to reproduce:
- Go to any dialog with mail installed
- Press tab multiple times
- At some point, the address bar should be focused instead of the dialog
buttons
Explanation: the chatter is present in the DOM but not displayed so the
last tabable element that is detected by getTabableElements is a child
node of the chatter which cannot be reached.
OPW-3584847
closesodoo/odoo#148382
X-original-commit: c631bf09b927003edc4c2b85e8790e8e2e8c044a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Before this PR:
Previously, when the command palette was opened and a navigation command
("/") was being executed with single or multiple dialog boxes behind it,
only the command palette would close. This left the dialog boxes open.
After this PR:
Now, when a navigation command ("/") is being executed from the command palette,
all the dialog boxes and the command palette close simultaneously.
Task-3441132
closesodoo/odoo#147956
X-original-commit: 7b32b235ec488d347285a9f47aa9d4b04b0b186c
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Isssue:
=======
When using a language with twelve-hour format (arabic) and open
datetime_picker it will raise an error.
Steps to reproduce the issue:
=============================
- Change lang to arabic
- Create a task in a project an try to modify the deadline
Origin of the issue:
====================
When we have `props.focusDateIndex != 0` and `props.range = False` we
will have only that index in the array `this.state.timeValues` ,
iterating over the array in `handle12HourSystem` function will result in
error because it starts iterating from index 0 which is undefined.
Solution:
========
Skip the undefined indexed;
opw-3629657
closesodoo/odoo#145424
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, the equality check performed by the datetime service
relied on a JSON-strigified version of the value on one end, and on an
array of ISO strings on the other end. This meant that the value was
never equal to itself and that the `onApply` callback would be called
even if the value remained unchanged.
This commit fixes that by ensuring that the compared values have the
same shape.
closesodoo/odoo#145929
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Exports the sortableDrag function, so it can be used in other modules (like account_reports for example).
closesodoo/odoo#145027
Related: odoo/enterprise#50283
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
In [1], an automatic scroll feature was introduced in order to always scroll to
the bottom of the hierarchy view after each patch.
The `isAnchor` option is removed, because in `Knowledge` it has the side effect
of completely scrolling the article down to the last card of the Hierarchy
view, hiding the rest of the view. Also, that option was not useful in the
standard configuration since there is only one scrollable parent.
Another issue is that the `scroll-behavior: smooth` css property also affects
the scroll speed of the `draggable_hook_builder`, which means that drag scroll
speed is extremely slow and does not follow the speed computed in that file.
This style is therefore removed, and `scrollTo` is refactored:
- Make use of the native `Element.scrollTo` method, which has a `behavior:
"smooth"` option.
- Move and rename methods to compute the closest scrollable from the
`draggable_hook_builder.js` to `scrolling.js`.
- They check if a scrollable has a client[Dimension] greater than 0 for
eligibility.
- They check the proper `overflow-[axis]` from the computed style (`auto`
and `scroll` are eligible).
- A test of `scroller_service_tests` was updated because even if an element
has `max-height: 0`, its children still can have a height and make their
scrollable ancestor have a `scrollHeight` greater than its own height.
- If the `scrollable` option is given to the function and the provided
element is not actually scrollable, compute a `scrollable` ancestor instead
of doing nothing.
- This is more flexible in a situation where a supposedly "scrollable" is
computed with a selector and ends up not "scrollable" in some custom
configuration (i.e. embedded view in Knowledge).
The `scrollable` option is removed, since `scrollTo` is already able to compute
the correct closest scrollable element, no need to hardcode a selector for that.
Finally, the draggable speed and threshold for the Hierarchy view are set to
the same values as a Kanban view for user experience consistency.
[1]: https://github.com/odoo/odoo/commit/3489a0d28fdbaf607d18b00d144bb00bae2727c3
task-3562116
Part-of: odoo/odoo#143941
__Current behavior before commit:__
The logic to regenerate assets bundles is located in the frontend (i.e.
the JS is making the calls to retrieve and unlink them) which is not
very clean.
Furthermore, when doing so, the old assets might still be included on
cached views that called them with `t-call-assets`.
Therefore, regenerating assets bundles can break the CSS or the JS as
long as the view cache is not cleared.
__Description of the fix:__
A new backend method is implemented for regenerating asset bundles.
This provides a dedicated and maintainable approach. Additionally, the
cache is explicitly cleared during the regeneration process.
__Example of steps to reproduce the issue on runbot:__
1. Check `Disable cache` in chrome dev tools.
1. Little bug icon > Regenerate Assets Bundles
closesodoo/odoo#145279
X-original-commit: b8e1f9f880e4723ddbe595043d22b565ad735832
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
When a dropdown open a dialog and on the dialog there is a new dropdown,
before this commit, when clicking on the second dropdown, the first one
will close.
This is an issue with closing the first dropdown, is if the dialog is
opened using useOwnedDialogs, the dialog will also close.
Also, if the dialog is open to throw a "find more" of a x2many field,
even if the dialog is not close, as the dropdown will close, the
original field will also be destroyed and it will raise an error.
Now, we avoid closing dropdown's, when opening new dropdowns that there
are not on the same active element.
opw-3464528
closesodoo/odoo#144238
X-original-commit: 6fec387d258dfd945dbbd48a9aab91ce6113ccaa
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@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
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>
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>
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>
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>
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>
**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>
Before this commit, cliking on a popover that was open inside another
popover closed both of them.
After this commit, the popovers are not closed. them will close only if
we click out of them and the popovers they opened.
closesodoo/odoo#140258
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
When foo is not an x2many, a condition of the form
("foo", "in", [])
was transformed by the ExpressionEditor into
"set([foo]).intersection([])"
while it can be better expressed as
"foo in []"
In this commit, we improve the conversion of conditions of that kind and
similar other conditions.
Note that we also ideally want domains and their corresponding expressions
to be evaluated the same ways on records (at least on good examples).
For this we want for instance, the condition
("foo", "in", 1)
to be translated to
"foo in [1]"
and not
"foo in 1"
which is an invalid Python expression.
closesodoo/odoo#140140
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Before this commit, a test in the "objects" test suite failed because
the 2 dates generated to verify equality could potentially be created
in a different millisecond, which would make the test fail.
A first fix simply assumed that patching the date would suffice, but
this did not solve the issue since the time advances normally even for
patched dates.
This fix ensures that the dates have exactly the same values (and
removes the patch which was not necessary anyway).
Runbot task 25596
closesodoo/odoo#139953
X-original-commit: b02d7fe6c4eaee09066cf58d0e9bad91e3a3234d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Since https://github.com/odoo/odoo/pull/137098, `display_name`
can be false (from the default behavior in BaseModel). It isn't
handle correctly in domain_selector Component, which trigger a
traceback trying to `split` false.
closesodoo/odoo#139450
X-original-commit: 06f3cbb95b2e4cfb271039a19660991c743c2ba8
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Co-authored-by: Polymorphe57 <dam@odoo.com>
Now that some field attributes like invisible are given by Python
expressions that can involve set operations, we want to be able to easily
edit those expressions in the expression editor. For this we have to
improve a bit the mapping expression <-> condition tree, in order to
have simple rewrittings like
"set(user_ids).intersection([1, 2])" <-> condition('user_ids', 'in', [1, 2]).
Part-of: odoo/odoo#139451
We make py_js support sets and the operations intersection, union, and
difference.
Part-of: odoo/odoo#139451
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Julien Carion (juca)