*: mail, pos_sale, pos_self_order, website_sale
=== `oi-close` adaptation ===
Prior to this commit, `oi-close` icon was based on the default
sans-serif font. Depending on this, there could be alignment and size
inconsistencies with the Odoo UI icon library.
This commit adapts `oi-close` to use a custom icon from the UI icon
library to make it more robust and maintain consistency with this
library.
=== corner arrow icons adaptation ===
Prior to this commit, directional icons related to the four corners were
misaligned.
This commit adapts these four icons so that they are properly aligned.
task-3618046
closesodoo/odoo#144598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Install planning app.
- Open Planning.
- Click on search bar menu.
Issue:
- The groupBy column width is more than expected.
Cause:
- groupBy and filter menu size changes depending on their
groupBys and filters names so giving bigger name to filters
and groupBy increase their size and there was no max-width
set on then and because of setting name and giving bigger
string on field makes that column unexpectly big.
Fix:
- set max-width on `o_filter_menu` and `o_group_by_menu` to
avoid unexpected bigger size for filter and groupby columns.
task-3607270
closesodoo/odoo#140412
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
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>
Since [1], an error is raised when no app is detected on the clickbot.
The issue with this is that it's possible for a user to no have access
to any app. This occurs when we test single apps (web for instance) with
demo user.
The aim of the error is to detect if we are stuck on a tablet mode page.
Now, we change the test on the ensureHomeMenu function, to don't have
false positives, and detect correctly if we are stuck on a tablet mode
page.
Fixes runbot issue 52675
opw-3649047
[1] : 8f365824c9dddacf1b3a40688a30c8498df3d5d4
closesodoo/odoo#149214
X-original-commit: 10475a96401b02b95e92cc6c9eaa909aeb7de1d1
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The ListRenderer disables the checkbox of all lines corresponding to a
record which cannot be selected. Unfortunately, because
`canSelectRecord` is a getter, it is invoked once per line, and this
getter in turns invokes the `editedRecord` getter which scans all record
to find which record is selected. This operation is O(n²), so it's very
slow when there are a lot of records.
This commit fixes that by computing the value once per render.
Time to render the list view of views (technical > User Interface >
views) with 600 records visible:
- before: ~1800ms
- after: ~250ms
closesodoo/odoo#149051
Signed-off-by: Aaron Bohy (aab) <aab@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>
Since milk redesign the kanbancard lost their outline bottom on focus
state.
Previous fixes where applied to solve this issue in commit[1]
and commit[2]. These fixes were a Catch-22:
fixing a behavior here, creating an issue there (double borders,
issue on drag..) which lead to more custom code.
In this commit, we remove the code added by the previous fixes and apply
a solution used in version 16.0 and prior. Relying on a negative margin
to hide the border of the following `kanban_record` and applying an
outline effect and a greater `z-index` on focus to make it appear on
top of the border. This z-index is set to 2 to compensate the
`z-index-1` on the kanban column when a card is focused and dragged.
[1]: odoo/odoo@d8fcc218bc
[2]: odoo/odoo@2495bfa725
task-3580229
closesodoo/odoo#148869
X-original-commit: ca388322327379e470e76f3a3c6ee2b2271e3895
Signed-off-by: Pierre Paridans (app) <app@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 parser of the library we use to extract strings to be translated
(python-babel) doesn't handle escaped newlines in the same way as the
JavaScript parser. The resulting mismatch makes the content that uses
them untranslatable.
for example:
```js
const hey = _t("slt \
çv ?"
);
```
is exported as "slt \nçv ?", while the content of the variable is
"slt çv?"
This commit removes faulty occurrences from the code base and re-exports
the corresponding POT files.
*: point_of_sale, pos_sale, project, web
closesodoo/odoo#145971
Related: odoo/enterprise#52617
Signed-off-by: Louis Wicket (wil) <wil@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>
The digits option was of type string, but it needs to be an array of two
integers.
We introduce a new digits type to handle that case.
This is used in studio, more info in the enterprise PR.
opw-3614919
closesodoo/odoo#148571
X-original-commit: 6dbf59a9db1a68069df7e922fcab673ce7f7ae5a
Related: odoo/enterprise#53865
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@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>
When a user connects to its database that has been freshly upgraded
to 17.0 database, he gets the following JS crash:
```
TypeError: can't access property "defineLocale", moment is undefined
@http://www.odoo.test/web/webclient/locale/fr_FR:13:10
@http://www.odoo.test/web/webclient/locale/fr_FR:9:4
@http://www.odoo.test/web/webclient/locale/fr_FR:10:2
```
Before 17.0, the `/web/webclient/locale/<string:lang>` route was used
to get the appropriate `momentjs` locale and was cached for a duration
of 1 week.
So when connecting to the upgraded database we will get the cached
file, but as `momentjs` has been removed (see odoo/odoo@4327c062d8)
it will crash.
Now as `luxon` is using browser's `Intl` to get the translations, we
can safely remove the call to that endpoint (it will always return an
empty file anyway)
closesodoo/odoo#145733
Signed-off-by: Samuel Degueldre (sad) <sad@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>
*: analytic, mass_mailing
This commit fixes the supportedOptions object in some fields. Instead of using
a 'supportedTypes' key when descbribing the type of fields that an option must use,
the 'availableTypes' key must be used. This was simply misspelled.
A help has also been added for the fold_field option, following the fix for task-3474817
closesodoo/odoo#143127
Related: odoo/enterprise#51241
Signed-off-by: Lucas Perais (lpe) <lpe@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>
Issue:
======
The auto signature has hidden overflow part in y axis when having long
characters in bottom like (y, j, g)
Steps to reproduce the issue:
=============================
- Use any sign template that have at least one name_and_signature sign
item.
- Enter a name that have at least one of the characters (y,j,g)
- Click on auto
- The signature doesn't show fully
Solution:
=========
Update the hardcoded values for the y-axis for the name and the line of
signature and the font size to make sure it fits perfectly inside the
canvas.
opw-3639171
closesodoo/odoo#148299
X-original-commit: c9653d5649a35640cc461c9baa0b73e8c6c1cace
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the pager hook use useChildSubEnv to patch the
config with the pagerProps. We used useChlidSubEnv because this
information only targets one of its children (the ControlPanel),
not the components using the hook themselves (e.g. the controllers).
However, this has an infortunate side-effect. If a component using
the pager hook also wants to patch the env (e.g. with useSubEnv),
and does it after calling usePager, it will erase the sub env
created by the pager hook for the children by its own.
This happens with the TimesheetTimerListView:
```js
setup() {
super.setup(); // super will call usePager
useSubEnv({
config: {
// this config doesn't contain the pagerProps
// generated by usePager, as it's the config of
// the component itself
...this.env.config,
disableSearchBarAutofocus: true,
},
});
}
```
Since using useChildSubEnv in this case isn't necessary, we simply
replace it by useSubEnv.
Note that we don't add a framework test for this issue, as it
would be totally artificial. Instead, the enterprise PR adds a
test for the TimesheetTimerListView.
opw 3636182
closesodoo/odoo#147393
X-original-commit: 8dbf8021842b94b9b067e2582f3aa92d31ef62e5
Related: odoo/enterprise#53342
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@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>
Steps:
- Open Field Service
- Create a new task
- At first, the product stat button shows the price as 0.00
- Add task name and customer
- Save the task.
- Check product stat button
Issue:
- Now, after saving the task, the product stat button will not have the price
shown as it was displayed before.
Cause:
- The class o_field_empty is applied which has the property of display: none
and hence the price field is not displayed.
Fix:
- The o_field_empty class is applied at the wrong place, we need to apply the
o_field_empty only when o_stat_text is applied.
closesodoo/odoo#147926
Task: 3394985
X-original-commit: 9ea49b1e0be064ef4dd7dafe05aff4bd742ac135
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Open Field Service
- Switch to the calendar view
- Click on any task
- Notice the space in the row of the worksheet template
Issue:
- There is a weird space between the title Worksheet Template and the template
name
Cause:
- Due to the long name of Worksheet Template, it moves to the next line but
occupies a certain amount of space around it
Fix:
- By giving flex-wrap, the content is displayed properly
Task: 3394985
Explanation:
When the label 'Worksheet Template' is long and moves to the next line without
flex-wrap, it may cause unwanted spacing issues. By using `flex-wrap: wrap`,
you essentially enable the content to flow onto a new line if it exceeds the
available width, ensuring a more visually appealing and properly aligned
display without unnecessary space around the label. It allows for a more
flexible layout, accommodating varying content lengths without compromising
the overall presentation.
closesodoo/odoo#147925
X-original-commit: 9be92729eaa4bc3b3cfe9778cb2b1fcc47a8cc59
Signed-off-by: Pierre Paridans (app) <app@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
This commit adds the possibility for the `.o_horizontal` class to wrap,
which is especially interesting in mobile.
When using a `radio` widget, you can choose to use two options :
- `horizontal` which will add a `.o_horizontal` class to the radios
and allow them to display with a `flex-row`
- `vertical` which will add a `.o_vertical` class to the radios
and allow them to display with a `flex-column`
Prior to this commit, the `.o_horizontal` class was not allowing elements
to wrap, which would cause overflow issues on small devices.
To fix this issue, we add a `flex-wrap` property to the class, to ensure
that if the buttons are larger than the breakpoint, they will wrap
and stay inside the container.
task-3580082
closesodoo/odoo#140651
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The Settings page lacks a default search context key, because it lacks
the `<search>` arch.
We add a context key to make actions target some settings.
closesodoo/odoo#147149
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
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>
In list views with search panel, in case there are no records found,
the nocontenthelp is being cut off,
because the o_list_renderer doesn't take the full height.
This commit sets the height on the div, so there is no cut off happening.
Part of: task-3619987
closesodoo/odoo#147268
X-original-commit: 52c916089547c96c2d16c0c6134b40270b72b72d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Before this commit:
Filter items in the sidebar/panel are sorted DESC. Items without value
are put at the end of the sorted list (eg : Open Shifts)
After this commit:
Filter items are sorted ASC. Label that begins with numeric are also
sorted correctly. Items without value are stull put at the end of the
sorted list.
task~3524031
closesodoo/odoo#146127
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Description:
===========
Before this commit, when a line in edit mode in a list view is the last
tabable element in a dialog, pressing "tab" does not cause a switch to
the next line in edit mode. It is therefore not possible to navigate
in this dialog using "tab".
Problem:
=======
Currently, the ListRenderer listens to keydown events using few t-on-keydown.synthetic
in order to know whether to switch the next line to edition.
For information, the effect of a synthetic is to create a single listener
on "document" instead of creating a listener for each element. There is
a conflict with the ui service which listens to all the "tab" keydowns
in order to check whether or not we are on the last tabable element of
the current activeElement. If we are, we stop the event and focus on the
first tabable element. This feature avoids the need to navigate outside
dialogs by pressing tab.
In our situation, this has the effect of stopping the keydown event
before the synthetic can receive it, as the service ui listener is placed
on the dialog and the synthetic listener on the document.
Solution:
========
Remove the use of synthetic in the ListRenderer.
No significant loss of performance was observed.
closesodoo/odoo#147027
X-original-commit: 48e154e
Related: odoo/enterprise#53150
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Prior to this change, anything passed in the context of a m2m
avatar field would not be taken into account because the context
was not passed properly in the many2many_tags_avatar_field template.
This commit fixes that and also adds a test for future testing.
task-3599601
closesodoo/odoo#146562
X-original-commit: 03202b7c790be266674e12b96a0b99f44ac773ed
Signed-off-by: Francois Georis (fge) <fge@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>
This commit fixes a crash that would happen on file upload in the project
sharing portal chatter. This crash was caused by the file size check in
the uploadFiles method of the FileInput component due to the fact that
the PortalFileInput calls this method once per file instead of once for
all files. The fix therefore ensures that the file size check will be
correctly applied in the case of a single file parameter instead of a
files array.
Steps to reproduce:
- Access the portal (with the /my route)
- Go to Projects
- Open the AGR - S00064 - Sales Order project
- Open any task in the kanban view
- Send an attachment in the chatter
- Before the fix, a traceback occurs on file upload
Crash introduced by https://github.com/odoo/odoo/pull/138203/commits/82b4395b2f12e1c86d2bd5c4acd47c321be071d8
opw-3628996
closesodoo/odoo#146214
X-original-commit: 8e2aef9ab607b06eb4667859204cfd7186b3f060
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, columns in list views could be manually resized
only if there were records in the table. For the ungrouped case it
makes sense, as the table is empty anyway. However, for the grouped
case (either with empty groups, or with all groups being folded),
the list contains no records, but resizing could make sense as
there could be aggregate values displayed on group headers.
Technically speaking, there's no reason to restrict the resize
feature if the table is empty. Functionally wise, a user could get
confused if the feature is sometimes available, and sometimes not.
For that reason, this commit simply removes the isEmpty condition,
meaning that resizing columns is now always available, even if the
table is empty.
Task 3621490
closesodoo/odoo#146622
X-original-commit: 8fbdbb59eb3f37fad1fb75f4ff363f7fa17e6d27
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On device which are primarily recognized as "touch", when using a
mouse-like pointer, the tooltip can't be opened both on "touch" and on
"hover" (withe the mouse).
This commit fixes it by removing the escaping that prevented the mouse
events' listeners from being registered on touch-enabled devices.
Steps to reproduce:
1. Using Chrome, open the developer tools and click on "Toggle device
toolbar"
2. Install Contacts
3. Go to Contacts and open the form view of any contact
4. Now click again on "Toggle device toolbar" to disable it but do not
reload the page: touch device capabilities will be loaded but you
will be able to use a mouse
5. Click on the question mark next to "Tax ID", nothing happens
opw-3493571
closesodoo/odoo#146621
X-original-commit: 5cbfa9751d6186ac6515a4341676706a807642ec
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit fixes 3 issues with the domain in field tooltips, in
debug mode.
1) it only displayed the domain defined on the field in the model,
not the domain set in attrs in the view, if any.
2) when the domain was the empty array, `domain: ` was displayed.
3) unset values should not appear in the tooltip (invisible,
column_invisible, required, readonly).
opw 3455119
closesodoo/odoo#146563
X-original-commit: 8c4ff1fac9eb003c23770bf74f9d7ffe062f6ce7
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since PR odoo/odoo/pull/124068, the browser history back no longer works
correctly when navigating from the home menu to applications. It requires
two history backs instead of one.
Why:
Two pushStates are performed on the router, the first to add the menu_id
and the second to apply the action associated with the menu.
These two pushStates are not in the same setTimeout, which causes two
changes to the url. So two entries in the browser history .
Solution:
We perform the two pushStates in the same setTimeout. This causes
only one url modification and therefore one entry in the browser history.
How to reproduce:
- Go to the home menu
- Click on the app A
- Return to the home menu using the toggle menu
- Click on the app B
- Perform a history back
- The home menu is displayed
- Perform a history back
Before this commit:
The home menu is still displayed
After this commit:
The app A is displayed.
closesodoo/odoo#146143
Enterprise: odoo/enterprise/52683
X-original-commit: 8e3152fbfbb4a836ab9663d009fbcacbe3554ae8
Related: odoo/enterprise#52697
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Brieuc-brd