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>
This commit solves an issue where sample data would be erased when the
user switches from a view with no sample data to another that should
contain them. This commit also removes unnecessary usage of nextTick in
assets loading.
Steps to reproduce:
- go to project and open one
- enter a no match filter and save it as favorite
- reload
- switch from kanban to calendar view and switch back to kanban
- after the fix, sample data should no longer be erased from kanban
task-3701143
closesodoo/odoo#152666
X-original-commit: a8ff1465c6c31240d06c98fa5d61e146b3908cf0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Steps to reproduce the issue:
1. Open Menu Items
2. Open the form to a menu
3. Select an action type (e.g. ir.actions.report)
4. Select another action type (e.g. ir.actions.act_url)
5. Click on the field next to it
6. Click on "View all"
7. The results displayed match the first action type selected (report), not the second (act_url)
Explanation:
`res_model` is initiated in two functions: `useOpenMany2XRecord()` and `useSelectCreate()` in the `setup()` of the `Many2XAutocomplete` class. The value is never updated for as long as this instance of the field exists.
Suggested fix:
Everytime the key changes, a new instance of the field will replace the current one, calling its own `setup()` with the updated values.
opw-3628017
closesodoo/odoo#151495
X-original-commit: d4078d783717986189f9fbc1b6dd6b264e41e49e
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@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, there was a race condition with the statusbar
field, and more specifically with useRecordObserver.
The issue could be reproduced in the form view of project.task. In
an existing task, belonging to a project with some stages, change
the project to another project with its own stages. It might happen
that the displayed stages weren't the ones of the newly set project.
If this didn't happen directly, this happened upon saving (i.e. the
correct stages are displayed just after switching the project, but
as soon as the user saves the record, the former stages are back).
This happens because useRecordObserver used an outdated version
of the props to get the domain (i.e. the props of the component
have been updated, but useRecordObserver still used the old version,
in particular the old props.domain).
This commit fixes the issue by ensuring that we always use the last
version of the props.
opw 3693113
closesodoo/odoo#152433
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
In form views, when the user closes the tab while having unsaved
changes, and if those changes are valid, we want to save them
automatically before leaving.
Before this commit, there could be situations where the changes
weren't actually saved. For instance, if they involved an heavy
payload for the write rpc, or if the network connection was poor,
it might happen that the xhr is killed. Or at least, browsers do
not offer any guarantee to wait for those xhr to reach the server.
Instead of a classical xhr, we thus use navigator.sendBeacon which
ensures that the data will be sent reliably [1]. There's a drawback
though, as its payload is limited. When the payload is too heavy,
sendBeacon simply returns false and does nothing. In this case,
we prevent the page from unloading and display a notification
suggesting the user to manually save his changes before leaving.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
Task 3537838
closesodoo/odoo#151834
X-original-commit: 0b53daa60ee5b370def21c8e0e30a6819597a0e4
Related: odoo/enterprise#55457
Signed-off-by: Francois Georis (fge) <fge@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>
To reproduce
============
- On a project, on a task
- create a subtask give it a name and from the list view click on the
"view" button
- you get redirected to form view to create a new task that is not related
to the parent task or the project
Problem
=======
When you click on the "view" button, the task is not saved yet, so the
subtask doesn't exist yet to be viewed in Form view
Solution
========
We prevent the redirection to the form view if the record is not saved yet
same logic as : https://github.com/odoo/odoo/commit/9b136383c2599301413e6770cc0ff204273b589d
opw-3681471
closesodoo/odoo#149753
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a form view in a dialog with an action button (e.g. a stat
button). Click on it. Before this commit, the action was executed
in the background, but the dialog remained open, which could
confuse the user and was definitely weird UX-wise.
With this commit, we automatically close all dialogs when we
execute an action which will update the main action container.
Note that this was working in previous versions thanks to legacy
compatibility code [1], but this code has no impact on the new
(wowl) dialogs, so as of 16.0, it has very limited impact.
Here's a specific scenario to reproduce the issue:
- go to the project task gantt view
- click on a pill
- in the task for view (in dialog), click on the external button of
the project many2one
- in the project form view (in dialog), click on a stat button (e.g.
"At risk")
-> before this commit, the 2 dialogs remained open.
opw 3644904
[1] https://github.com/odoo/odoo/blob/15.0/addons/web/static/src/legacy/action_adapters.js#L42
X-original-commit: 03fa39738c4f81ae30caaaa032c099797ecba9e7
Part-of: odoo/odoo#149543
Co-authored-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>
Recently, a new option 'always_range' has been added to the datetime
field (task 3628069, commit bc98aad). This option forces the display
of the arrow between the two dates from the start. Before that, you
would add a first date, click a button to add a second date and then
only would the arrow appear.
The oversight here is when the field is empty AND readonly. In that
case, you have an visible arrow next to the label but you can't do
anything with the field anyway. So better not to show it.
This commit makes sure to not display the arrow in this case.
task 3690523
closesodoo/odoo#149912
Signed-off-by: Aaron Bohy (aab) <aab@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
issue:
- calendar mobile view (month) > pressing on a day or timeframe to create a task doesn't work
if the view does not have the "day" calendar scale set up
Fix:
- We are removing the condition preventing the renderer to use the createRecord callback when
the view is Mobile and in monthly scale
So now a record will be directly created when a user clicks on a timeframe in monthly view even
if he's in mobile view
Task-3677216
closesodoo/odoo#150624
X-original-commit: da23aa3d68e0f8b833d085c09bcf81d8aa2a4285
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The decimal property crash when added in a list view, if some records
have False as a value.
Technical
=========
Since fe797a03285ec9c81d29ed631839c91e2b9957a4 , we use the wrong
Formatter in the Float field.
Task-3698415
closesodoo/odoo#150682
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce
==================
- Enable analytic accounting
- Go to customer invoices
- Open a record
- Open studio
- Click on the Invoice lines > Edit list view
- Set the analytic field as required
- Close studio
- Create a new record
- Add a new line
- Click on the analytic field
- Close the popup
- Save the record
=> Even though we didn't set a value for the field, it is saved
Cause of the issue
==================
The actual field value is an empty object.
The validity of a field is checked here [0].
An empty object is considered a truthy value.
When setting the required attribute directly on the python field
declaration, an empty object does not pass the check
Solution
========
Add a specific check for json fields. When the value is either false
(not set) or an empty object, the field is considered invalid.
---
[0]: https://github.com/odoo/odoo/blob/23f01c533512cbfb33e90509e22cd3c3c4f99d40/addons/web/static/src/views/basic_relational_model.js#L284
opw-3659763
closesodoo/odoo#150677
X-original-commit: 51b538b3f678298f27bbbf458de5696706c18349
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
When creating a new column in kanban view, the user should be able to
either hit enter or click the add button. This launched the validation
process to add the column.
There has been a fix in owl that would force a t-model.trim to be lazy.
This was causing problems in this case as the "enter" pressed by the
user was detected through the hotkey system. This was causing the
change event not to fire, resulting in the behavior of the feature being
broken.
We fix this by using the t-on-keydown directive instead of the hotkey.
We also remove the t-model directive as it is no longer of any use.
The trim is done in the validate function.
task id 3691208
closesodoo/odoo#150297
X-original-commit: e3ad26632b00d0b0dded25282e4dc910983ef9dc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before this commit, the datepicker was not displayed entirely on small
screens if the current view wasn't tall enough.
This commit adds a margin (supposedly) big enough to render the entire
picker even on small screens.
Task 3585878
closesodoo/odoo#149510
X-original-commit: 47c0627d218bd846596c9deb84720fc289047365
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, when a kanban card has cover image set and the user
would like to remove it, he does not have the "Remove Cover Image"
button displayed when he goes to KanbanCoverImageDialog. The reason
is because the condition on `t-if` set on that button is always
falsy because `coverId` is undefined in the component.
This commit defines getter called `hasCoverImage` to return true
if the record displayed in the kanban card has cover image set.
task-3623759
closesodoo/odoo#150033
X-original-commit: c5d1894804c590dec208755e93d21f249714721d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to Reproduce:
Navigate to Project.task kanban view.
- Attempt to set a cover image.
- Observe the non-functional 'upload and set' button.
Issue:
- The 'upload and set' button in the Project Task Cover Image is unable to click
Solution:
- Resolved the issue, ensuring the 'upload and set' button functions correctly
for a seamless cover image setting in Project Task.
task-3623759
X-original-commit: fc531640dedf7c8a576ed43d8e27a0c1054ec512
Part-of: odoo/odoo#150033
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
Fix the rounding of the percentpie field value as it was sometimes
displaying a very long number due to python rounding precision.
The value is now displayed rounded to 2 decimals without trailing zeros.
Task-3648755
closesodoo/odoo#149226
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a nested (2 levels) form view with a footer.
On the main view, add a record in the one2many in form view (dialog).
Before this commit, the footer of the nested one2many form (within the dialog) was
put inside the footer of the dialog, which is wrong, as the footer originates
from a subview, hence has nothing to do with its parent.
After this commit, each subview's part that should be rendered elsewhere than
in the main formRenderer doesn't pollute the main view.
opw-3681966
closesodoo/odoo#150010
X-original-commit: 4891753cc3ef1a6a1daa36ecd70e79e7410e9bb0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps:
- Open the Project module.
- Open any project.
- Add a subtask.
- Without manually saving the subtask beforehand, click on 'View'.
Form view of sub-task opens that doesn't have any of the fields it should
inherit from its parent task.
- Go back to the parent task using the breadcrumbs.
- Click on 'View' again. Now, the sub-task has all of its fields set as it should.
Issue:
- After clicking on 'View', the form view of the sub-task opens, but it doesn't
have any of the fields it should inherit from its parent task.
Cause:
- On clicking 'View', the switchToForm action is called, and this action
doesn't save records before switching to the form view. Also, it should load
that record into the Parent task after saving. In other modules, when clicking
on 'View', the openRecord action is called, which is also not saving data.
Fix:
- Records should be saved when the action is called on clicking 'View'.
For the project module, when the action is called, after saving the record,
it should also load records in the parent task.
task-3631285
closesodoo/odoo#147665
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When clicking on a filter on a progress bar of a group, the aggregates
need to be recomputed. To do this, a web_read_group is called.
Since [1], the key groupDomain was removed, with the result that, the
web_read_group is called for all the groups and not only for the needed
one. This can be a performance issue.
Now, the key groupDomain was reintroduced and the web_read_group is done
only for the modified filter's group.
[1]: https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3closesodoo/odoo#149695
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With the last realease of owl, .trim now implies .lazy. This means that
if t-model.trim is used, the value will be updated in the state only when
the change event is triggered. Here we adapt the helper editFavoriteName
which was supposed to update the state value.
X-original-commit: 7a16b75a35a5bd60190ee5b437b925a2fa99fb70
Part-of: odoo/odoo#149507
The kanban's create button ("New") is usually displayed in the
ControlPanel. But in the select/create dialog (like many2one dialog),
the create button is moved to the footer.
On small screen, the Many2X fields' selection view switches from a list
view to a kanban one but a different condition was used to display (or
not) the create button in the ControlPanel, which explains why the
ControlPanel's create button appears only on small screen (and not in
the same dialog open on desktop-like screen size).
This commit fixes it by reviewing the condition applied in both the list
and kanban views and normalizing them to be based on the (existing)
`showButtons` prop that controls the additional buttons added to the
ControlPanel.
Steps to reproduce (with a smartphone like screen size):
- open Contacts app
- open a contact
- open the company's selection
=> two "New" buttons are displayed (top and bottom)
opw-3431221
closesodoo/odoo#149329
X-original-commit: c21c600189b36b7b4b352f8017467c8ef7d07c87
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce
==================
1. Install event
2. Go to Events
3. Configuration > Event Templates
4. Click on any event
5. Click on Communication
6. Add a line, change type to SMS
7. Type anything in Template
8. Click on Create "..."
9. The operation cannot be completed
Cause of the issue
==================
For many2one and many2many editable fields, the server sets the
can_create and can_write attributes on the field nodes. [1][2]
In some cases [3], those attributes are missing even though the fields
are actually editable. They are also absent for reference fields.
The `canQuickCreate` props was set to the following value:
`canCreate && !noQuickCreate`. When canCreate was absent, this was
evaluated to undefined, thus ignoring the noQuickCreate option.
Solution
========
When the permission attributes are missing, we have to assume that the
user has the appropriate permissions.
We also have to cast the extracted props to booleans as if you have an
props with a value of undefined, it will fall back to the default value.
In the test `no_quick_create option on a many2one when can_create is absent`,
we set the field as readonly and then cancel the readonly on the view.
This reproduces one of the bug of [3] which causes the permission
attributes to be missing.
-----
[1]: https://github.com/odoo/odoo/blob/fa6da3d63a3a4cce4e8ca788a49772925d318764/odoo/addons/base/models/ir_ui_view.py#L1296-L1297
[2]: https://github.com/odoo/odoo/blob/fa6da3d63a3a4cce4e8ca788a49772925d318764/odoo/addons/base/models/ir_ui_view.py#L1080-L1086
[3]: https://github.com/odoo/odoo/pull/138032
opw-3609799
closesodoo/odoo#148163
X-original-commit: efcb2a820bb57f1fae809725e799b3145fbbe599
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Have a fieldWidget using useRecordObserver. In its callback, have a line that will
throw an error.
Before this commit, the Promise created by the hook was not rejected, leaving the error untreated and
popping until the window's onunhandledrejection event handler.
After this commit, the error appears on the owl errors stack, catchable with the hook onError.
opw-3667395
closesodoo/odoo#148887
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
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>
As a reminder, the readonly expression in grouped kanban can enable or
disable the drag and drop feature. If the view is not reaonly but the
field in the arch on which the view is grouped is readonly, the drag
would be disabled.
Before this commit, there was a regression introduced in commit
ba1a5509fa that made the kanban record not
able to evaluate the readonly expression in the fields.
This commit fixes the issue by making the kanban record evaluate the
provided expression. It does not however correctly evaluate the
expression if it contains another field as the drag and drop feature
can be enabled at a view level, not at a per record level. It would then
resolve to not readonly.
Task id 3611116
closesodoo/odoo#148533
Signed-off-by: Francois Georis (fge) <fge@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>
Before this commit, a Field using the useInputField hook can ignore values
from an onchange in some cases.
Problem:
=======
In order to know if it should apply the value of an onchange on the field's input,
the useInputField hook uses a useEffect which will check if the field is
not dirty (being edited) and if it is not invalid. If it true, it will apply
the value returned by getValue which often corresponds to record.data[fieldName].
By executing getValue, it will therefore start to observe changes in record.data[fieldName]
until the next render. If getValue is not executed then changes applied
by onchange on record.data[fieldName] are ignored because we don't observe record.data[fieldName].
Solution:
=======
Always execute getValue in the useEffect to always observe changes on
record.data[fieldName] and apply them correctly on the input if needed.
(It s a hack but we don't have a better solution for now)
How to reproduce:
================
- Go to a Form view with a field B with onchange and a field A (char field)
- Edit field B (an onchange is in progress)
- Insert a value in the input of field A
- The onchange is resolved with a value for field A
- The value in the input for field A does not change (because the field is in edition)
- Click outside the input for field A (trigger change event)
- Edit field B (an onchange is executed directly)
Before this commit:
The value returned by the second onchange is not visually applied to
field A. The old value is still present in the input.
After this commit:
The value returned by the second onchange is correctly applied to field A.
Its input contains the value of the onchange.
closesodoo/odoo#148711
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently in calendar views in mobile it is possible to create events selecting
the time of the event by dragging. However, in calendar we also have the action
swiper responsible for moving between weeks when swiping close to the borders.
The issue is that when trying to create events by dragging close to the border
will cause the action swiper to trigger a swipe, therefore switching to the
next week. This commit fixes this by adding a swipeInvalid prop to the action
swiper that will be checked during the touch move event handler. If the
swipeInvalid is executed at any move and returns true, the swipe is cancelled.
task-3635841
closesodoo/odoo#148541
X-original-commit: 7772b17f226ddb99060b51d6b337e5f5106b5c25
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Steps to reproduce
==================
- Set the zoom option on an image field (You can do it with studio
starting from 16.3)
- Go to a record and hover over the image
=> Nothing happens
Cause of the issue
==================
The tooltip is only displayed in readonly,
but with https://github.com/odoo/odoo/pull/100570 ,
the readonly mode has been removed.
So it only applies for views with the readonly attribute.
Solution
========
Always display the tooltip
opw-3646005
closesodoo/odoo#148534
X-original-commit: e0f9a7eedfb91ea46969490cf261548835844907
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, the mockServer didn't respect the unity specification
for many2one fields. When you do a mockWebRead and you want to read other fields
than "id" and "display_name" for a many2one field, the mockServeur ignores
this part of the specification.
The goal of this commit is to ensure that the mockWebRead respects
the full specification for many2one fields.
closesodoo/odoo#148483
Signed-off-by: Aaron Bohy (aab) <aab@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 commit, the StaticList and its Records shared the same
reference to the activeFields. When an x2many record was opened in
form view (and that form view wasn't inline), we altered the active
fields to add the information coming from the form, and we loaded
the corresponding data for the record we open. However, by doing
so, we also altered the active fields of all the other records,
for which we didn't load the corresponding data. From that point,
a rendering of those kanban records could lead to a crash, because
we iterate over active fields and make the assumption that there's
an entry for each of them in data, which isn't the case.
For instance, this happened in a dev branch in project, in mobile:
after opening a sub task in form view, if we switched to another
notebook tab and then switched back, there was a crash.
This commit fixes the issue by creating a copy of activeFields for
each Record, s.t. when a record is opened in a dialog, only its
activeFields (and those of the StaticList) are altered.
Note that activeFields of the StaticList must be altered in this
case to ensure that the onchange spec is properly generated, with
the fields of the form view.
closesodoo/odoo#148351
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, the key for the cache of compiled templates
(in the useViewCompiler hook) only relied on the arch, i.e. we had
a cache hit if we had to compile an arch that had already been
compiled before.
However, the Compiler to use might change. When this happens, the
template must be re-compiled, obviously, as the ouput may differ.
For instance, have a kanban arch with a js_class (pointing to a
custom view with a custom compiler), and have that arch used in an
x2many (where js_class is ignored, i.e. where it is rendered with
the basic kanban renderer). This happens in project, with the task
kanban view, which is also used for the child_ids field, in the
task form view.
This could lead to traceback, as the compiled template might refer
to attributes of a the KanbanRecord that only exist on the custom
KanbanRecord, not on the basic one.
Part-of: odoo/odoo#148351
This commit fixes an issue about the last arrow button not taking the
`o_first` class in some cases.
With Odoo 17, we introduced a new behavior for our arrow buttons.
This behavior includes an invisible element placed before and after the
first arrow button on the left and right side.
While this is working fine as long as you don't have any hidden item
insie a dropdown menu, once you trigger a stage that was folded into a
dropdown menu, this invisible element appears on the right side.
Since we use the `o_first` class that sets a `border-radius` on the first
element on the right side, this invisible element was taking that
`o_first` class.
To fix the issue, we search for the first element within the scope that
does not have a `d-none` class, and we then add the class to that specific
element.
task-3628288
closesodoo/odoo#145453
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the StateSelectionField component handles the hotkey registration,
it was necessary to verify that an hotkey can effectively be added, instead
of trying to register to alt+undefined.
This issue happens when having more options in the selection field. Since the
code is written in a way each listed option should have an hotkey associated,
which is not the case, because the list of supported hotkeys has a length of 3.
The command is then added, without an associated hotkey.
A simple test case has been added, using the hotkey to set a state, and asserting
the presence of more than 3 items in the dropdown.
opw-3620129
closesodoo/odoo#148343
X-original-commit: ab572de20367f67aab4092b9e600e5ebd4cce4a6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Since the commit odoo/odoo@0d99f4b9d9, the header buttons with display="always"
can't be invisible. The invisible attribute is ignored for this type of
button in list view and kanban view.
This commit fixes this issue by adding t-if that will evaluate the invisible attribute.
closesodoo/odoo#148092
Signed-off-by: Aaron Bohy (aab) <aab@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>
always_range option on the daterange widget allows to always display this
widget as a range (two inputs separated by an arrow) even if both
start/end date are empty and not required.
task-3628069
Part-of: odoo/odoo#145167
Before this commit, since we are no longer in 2023, the test failed
because there is no longer 2021 in the filters dynamically added in the
dropdown of the date filter. The reason is now we have the current year,
the previous one, and the one before, that is, 2024, 2023, 2022.
This commit adds a patchDate to be sure we will start the test in 2023,
to get the expected filters displayed (2023, 2022, 2021).
closesodoo/odoo#147809
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Several tests are non deterministic because they are using
`assert.verifySteps` at the wrong moment. Helpers such as
`afterNextRender`, `nextTick`, `Deferred` are used but those are
either not reliable or cumbersome to setup.
This PR introduces an asynchronous API on top of
`assert.step`/`assert.verifyStep`. This will wait until steps are
executed or until the timeout is reached.
fixes runbot-52660,54471,52794
closesodoo/odoo#147455
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Before this commit, in a non-editable x2many in list mode, if there
is a field "A" with many2many_tags which is displayed as an x2many
in list mode in the form dialog, it cannot be reordered with handle field.
Problem:
When we extend a record from an x2many to a form dialog, we use the
activeFields defined in the form view and patch them with those in the
list view. Currently, we always use the default order from the list view
even if it doesn't exist. So we always ignore the one defined in the form view.
Solution:
If there is no default order in the list view, we use the one in the form view.
How to reproduce:
- Go to a form view with an x2many field in list mode which contains
an "A" field with the many2many_tags widget.
- Click on a record in the x2many
- A form dialog opens with field "A" in the form of an x2many in list mode,
containing a handle field.
- drag and drop a line to reorder the records
Before this commit:
It is not possible to reorder records
After this commit:
It is possible to reorder records
Task ID: 3641933
closesodoo/odoo#147253
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, `ButtonBox` components were rendered inside
`Dialog` ones.
The approach created issues in the user flow, particularly in cases
involving intermediary records that were not yet saved yet.
task-3619180
closesodoo/odoo#146797
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the helpers for the kanban view are only used
in the kanban tests in web module and those helper functions are not
exported and so it is impossible to use it outside that file.
This commit moves the helper functions for the kanban view in a new file
called "helpers.js" in the same directory containing the tests for the
kanban views and export all the helper functions to be able to use it
anywhere we need to use those helpers in JS tests.
closesodoo/odoo#147279
Related: odoo/enterprise#53040
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
luvi