Before, in the list view, the user could not select a record range easily. He had to
check/uncheck manually each checkbox in the range.
Now, the user can select a range of records in list view by hitting its first record
and and its last record while holding SHIFT for the second.
It's also possible to do it with the keyboard:
- pressing <SPACE> to select a record and <SHIFT+SPACE> to select a range of records.
- pressing <SHIFT+ARROW> to extend to current checkbox
task-2039894
Part-of: odoo/odoo#99050
Pressing `<space>` in browsers results in a ` ` event key.
We don't want this event key as ` ` is not recognized and not
whitelisted in the hotkey service.
Instead we want to use `space` because it is more readable in the
codebase.
Part-of: odoo/odoo#99050
Previously, when calling error handlers, we would give them a new error
created by the error service, as well as an `originalError` which is the
error that was caught by the error service. In some cases, this error is
part of an error chain, eg: errors that happen in the owl lifecycle are
wrapped in an `OwlError`, so that when an error occurs in a callback
passed to a lifecycle hook, the position where the hook was called to
register the offending callback is part of the stack trace.
In practice, most error handlers only care about the error that caused
the entire error chain (the root) when deciding whether they should
handle the error or not, eg: an RPCError should be handled by the rpc
error handler, regardless of whether it occured in an event handler or
in a component's willStart. It already reads the traceback to display on
the UncaughtError provided by the error service as this traceback
contains the entire error chain stack information and is annotated with
source maps by the error service.
This commit makes it so that the `originalError` passed to handlers is
now the root of the error chain, it also sets the `cause` of the
UncaughtError which is passed to handlers as the error that was caught
by the error service, so that if a handler needs to inspect the error
chain to know whether it can handle the error or not, it can still do
that.
related to OPW-3069633
closesodoo/odoo#106720
X-original-commit: dd6f103b1635868e03a7aa40eb7186861d22d377
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
There was a typo in the color_field xml not allowing to disable the
pop-up in case of readonly. A test validates the feature is active.
The color_field now displays the transparent symbol (instead of black
color) in case the color is undefined.
The product configurator also displays the transparent symbol for
undefined non-custom colors.
task-3013110
closesodoo/odoo#106669
X-original-commit: c67c32c2dbe10b4885ec1177852839b3d18ecf05
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
**Before this commit**
When a popover is shown and then repositioned to a different placement
(i.e. due to window scrolling or resize), its arrow is misplaced.
This is due to the fact that classnames added in order to correctly place
its arrow are just added to the previous ones instead of replacing all
the needed classnames.
**After this commit**
The classnames are now properly replaced instead of just being appended.
closesodoo/odoo#106495
X-original-commit: c54cc2f87930147b5addb6f447574c677ef3504d
Signed-off-by: Luca Vitali <luvi@odoo.com>
When a one2many is used as a search default, its label has to be fetch
via a name_get in order to get a correct display of the facet
corresponding to that field in the search bar. It turns out that the
search model did not wait properly the return of the name_gets before to
start to compute the facets.
closesodoo/odoo#106624
X-original-commit: 50f58212410b321c1c4ad3d42a91cd1d23567308
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
Prevents auto save of not dirty forms with
text fields on page reload and tab/browser closing.
Specifications
==============
The text field default value is making Odoo consider
the form as dirty even when it's not which triggers
auto saving for not dirty forms.
Change the text field widget setDirty condition to
prevent considering empty textarea string dirty.
Typically, if the previous value was false, false and
empty string should be considered as the same value.
Task-3031570
closesodoo/odoo#106619
X-original-commit: 787ef58dd3f91f829509f738ee40c8764c403757
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Use case:
in the reconciliation widget, we need to know when the pager
is updated before the next render because we need to select the
appropriate id to use.
cf the following PR: https://github.com/odoo/enterprise/pull/33631
opw-3031131
closesodoo/odoo#106581
X-original-commit: 19523b511d54278613a3d3e7389a51665dcc3fc1
Related: odoo/enterprise#34408
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
The fix in #106174 was not good.
The translation dialog cannot update not translated terms
the initial term value may be empty "" when the source and the translation are
the same at first. So, the source to for update_field_translations should be
const source = term.value ? term.value : term.source;
closesodoo/odoo#106528
X-original-commit: 1ed5ce6f16d32efc0c5ec4cead67b2d8a57f6c41
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Scrolling inside a grouped kanban with a lot of cards on a column
makes the text header appear over the kanban card due to the missing
background.
Steps to reproduce :
- Open Helpdesk on small screen like a mobile
- Open VIP Support
- Made a Group by "Create date => day" (there should be enough cards on
a column to scroll)
- Scrolling the column => bug, the text header appears over the kanban
card
closesodoo/odoo#106368
X-original-commit: 041fddf0c884ae9a6e2b040decfb1f31e9d25a29
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
**Issue:**
When at the first page of the list, and the user deleted all/or some
of the records, the next page is not automatically displayed.
**Solution:**
This is because the first page (offset=0) is exempted from offset
adjustment (_adjustOffset) which is responsible in reloading the
records in the list.
In this commit, we propose to reload the list if the call to
`_adjustOffset` didn't call `load` and there are actually deleted
records.
closesodoo/odoo#106317
X-original-commit: 2863978041d2856644da938ced9eedc640b8f198
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Issue:**
- Open a list view and group the records. Notice the count per group.
- BUG: When deleting a record under a group, the count in the group
is not updated.
**Solution:**
When calling `deleteRecords` in the `DynamicGroupList`, we call
`deleteRecords` on each group's `list`. This "list" can be
`DynamicGroupList` or `DynamicRecordsList`. Regardless which instance
calls the `deleteRecords` method, we should take the number of the
deleted records and subtract it from the group's current count.
If it turned out that the calling object is a `DynamicGroupList`,
we should make sure that it returns the ids of the deleted records
so that the parent group can update its count as well, that's why
we are collecting the deleted record ids.
It's not so easy to follow but we can roughly imagine the structure
this way:
DynamicGroupList
-> DynamicGroupList[]
-> DynamicRecordsList[]
Deleting items from the inner dynamic records list should result to
update of the parent group list, and eventually, to the update of the
root group list.
X-original-commit: 865c1b37f7986f00b85c9e8135e46cc4b2ac70da
Part-of: odoo/odoo#106317
Some missing aria attributes from 14.0 are reintroduced.
They are required for screen reader users to be able to know if menus
are opened and if menuitems are checked (e.g. if a filter is applied).
closesodoo/odoo#106277
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Luis González <lgonzalez@vauxoo.com>
Dropdown menus/items were refactored and moved to OWL when migrating to
15.0. Now, the focus is always on the dropdown button, which captures
and handles all keyboard events, to be able to move over the menus.
Currently-selected item is highlighted by toggling classes.
However, since the focus is always on the dropdown button, screen
reader users are no longer able to know what menu item is being
selected, as it's only a visual change (in previous versions, the focus
actually moved to the selected element).
The above is fixed by making the activeElement follow the visual change.
Part-of: odoo/odoo#106277
Co-authored-by: Luis González <lgonzalez@vauxoo.com>
**Before this commit**
Various issues are present in the calendar filter autocomplete:
- typing a character in the input would close the autocomplete dropdown
- search for a term yielding to no results would not display the
"No records" entry
- click on the "Search more..." entry yields to a validation error
message: "a mandatory field is not set". [1]
**After this commit**
The FilterAutoComplete component has been removed as it was useless.
It was a kind of higher order component trying to manage the
AutoComplete component's input state, leading to unwanted complexity.
We decided to remove this component despite being in a stable branch
for the following reasons:
- it was not exported and only used by the CalendarFilterPanel
- it brought unnecessary complexity
- it was not working properly
- the branch is still a bit young
- the diff in the CalendarFilterPanel template is minimal
Now that the CalendarFilterPanel directly make use of the
AutoComplete component, the first listed issue has been solved.
The two other issues were simple fixes addressed in the mean time.
[1] this issue comes from opw-3031045, more infos below:
Steps to reproduce:
- Go to calendar basic view
- Click on "+ Add attendees" and then on "Search more ..."
Current behavior:
Validation error on partner_id in calendar_filter create
Expected behavior:
You can look for a partner with advanced research options
Explanation:
The code treated the "Search more ..." option like a partner
option instead off calling the onSearchMore method that creates
the advanced research dialogue.
opw-3031045
closesodoo/odoo#106292
X-original-commit: 73af1d04d9d49eace16e3f88c32ce5d457b44b83
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Martin Fockedey <mafo@odoo.com>
Co-authored-by: Hubert Van de Walle <huvw@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Since the conversion in OWL of the `many2one_barcode` widget, on Mobile
when we open the search more a filter value is added automatically in
the filter and so when we want to change the value we need an additional
step to remove the filter to see all records.
This commit, use a 'custom event' to open the barcode search and restore
the normal behaviour on the `click` event.
Steps to reproduce:
* Go to Timesheet
* Add a new line
* Select a project
* Try to change the project => BUG show only the selected project
closesodoo/odoo#106267
X-original-commit: 6d7f5a0abd79f6185831a2b9617b031d13da89be
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Co-authored-by: Romain Estievenart <res@odoo.com>
Before this commit, new model term translations cannot be saved if it has been
translated before.
The reason is while translating fr_FR
the backend needs the mapping {old_term_fr: new_term_fr} to update old_value_fr
However the UI sent {old_term_en: new_term_fr} which was wrong
This commit fixes the bug by changing the key of the mapping from the
old_term_en to the old_term_fr
opw-3074712
closesodoo/odoo#106257
X-original-commit: f28c11917e093d0d3f5d18f0b377cfb24a7dbd92
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
**Issue:**
- Open a list view with `expand="1"` and `limit=<arbitrary small number, say 5>`.
- BUG: The pager shows that it's displaying the limited records, but in reality,
it's displaying all records under each group.
**Solution:**
This is because we are *not* limiting the number of records being fetch in the first
read_group rpc. We are now specifying the expand_limit in this commit.
closesodoo/odoo#106238
X-original-commit: e5bba9f5eb63ee95924c892801fe18feaef6d1fc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Steps to reproduce:**
- go to a product page
- replace image (=> image is shown)
- click on "Save manually" (the cloud upload icon)
- BUG: previous image is displayed.
But it was saved: if you move to another record and return then it
shows the correct one.
**Solution:**
Basically, in an image_field: If its props.value is a "binary size",
then the image source is a url pointing to a server endpoint and
this url is based on the rawCacheKey, otherwise, we use the "base64"
of the uploaded image.
The proposed solution for the said issue is to invalidate the
rawCacheKey during upload. Then, during the calculation of image url
(at `getUrl`), we reassign the rawCacheKey with the newest
"__last_update" value of the record when needed (if the props.value
is a "binary size").
closesodoo/odoo#106236
X-original-commit: 93911daab238e96c8aa9b0a951b9a268d83a9847
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since odoo/odoo#99660
the `depends` field attribute is no longer passed
from the server to the web client.
Because of this, the "Set Defaults" feature
of the debug menu is completely unusable,
as the list of fields on which to set a default is empty because of it.
The use of this `depends` field attribute has been introduced in
revision odoo/odoo@ce9bbf6c10
In the commit description, we can read that setting a default
on computed fields having depends has been disabled
because the defaults set were being overwritten by the call to onchange.
Note that only the fact the field has depends is required,
the actual list of field names is not used, just the fact the list is
not empty.
However, since revision
odoo/odoo@488e334fc8,
available since Odoo 14.0,
this is no longer the case, the defaults are no longer being overwritten
by the call to `onchange`, since the `default_get` has been integrated
into the `onchange`.
A video attached to the pull request of this revision
shows the behavior difference.
Hence, setting a default on a computed fields having depends
(with an inverse method, hence not readonly)
can be allowed again in this "Set defaults" debug feature,
therefore avoiding to have to send back the `depends` field attributes
to the web client.
opw-3031290
opw-3038711
opw-3055292
X-original-commit: 48ac799288e76a0256b9ce0712a70ed5abc0f62e
Part-of: odoo/odoo#105251
Steps to reproduce:
- go to Contacts app;
- add a reporting view (Graph, Pivot or Dashboard) (with studio for example)
- tape any character in the search bar;
- on "search related company for" field either use the arrow keys to go down to this and then click the right arrow key or click on the triangle to the left of this field.
Issue:
An error occurs.
Cause:
There is a mismatch between the parameters that are sent by the rpc call and those processed by the logic part.
Specifically, the domain must be part of the kwargs and not the args of the params key in the rpc call.
The problem occurs with a filter that looks like: `<field name="parent_id" domain="[('is_company', '=', True)]" operator="child_of"/>`
Solution:
Move domain in kwargs under key named args in the params of the rpc call.
opw-3031096
closesodoo/odoo#106074
X-original-commit: 8a9b418b27dcc9b904413f14cd0443f9a5b10d17
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Current behaviour:
When rendering a calendar view with "Year" option,
the weekday headers may be incorrect in some cases
when the timezone is set to a negative timezone GMT.
For ex. it renders "S S M T W T F" instead of "S M T W T F S",
if the first day of the week is Sunday.
Expected behaviour:
Formatting should be consistent with the first day of the week,
and be indepedent of the timezone.
Steps to reproduce:
- Change your system timezone to somewhere in Alaska
- Install TimeOff
- Open TimeOff and switch to the yearly view.
- Observe that the weekdays headers are incorrect.
Reason for the problem:
The custom calendar header formatter was trying to generate
the end result directly based on the date marker, which is
incorrectly set in that context. This patch doesn't fix the root
cause of why the `info.date.marker` starts at an incorrect date.
Fix:
A formatter shouldn't read state. Since we are using the luxon plugin,
we use the `"EEEEE"` format, which is equivalent to the `"narrow"` options
from JS's `Intl.DateTimeFormat()` available in all browsers.
Affected versions:
- 16.0
- master
opw-3033464
closesodoo/odoo#106041
X-original-commit: e212f8752047222d1d81e1e9589934e70ecacf2a
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
*: im_livechat, website_livechat, website_slides
In c989ff3, the odoo module system has been changed so that it now
errors out when modules are defined but have missing dependencies and
cannot run. Unfortunately, tours are defined in a single bundle,
`assets_tests`, and this bundle is used everywhere tours need to run,
but some of these tours depend on modules that only exist in the backend
and others on modules that only exist in the frontend. We don't want to
break up the `assets_tests` bundle as this creates a poor developer
experience, and so the solution that was chosen at the time is that when
the `assets_tests` bundle is defined, we ignore all module dependency
errors.
This causes a problem however, which is that if a module dependency is
missing in production code, the page will be broken by the module error
(which is expected) but if the `assets_tests` are present, which is the
case when running tours and tests, then it won't, meaning the tours will
happily pass despite the application being broken, which is
unacceptable.
This commit fixes this issue by replacing the assets_test bundle by a
new bundle (`__assets_tests_call__`) within which all module dependency
errors are ignored, which lets dependency errors that are hapenning in
other bundles (ie in production code) happen even during the tests.
Because of this, this commit also fixes the dependency errors that
already existed but were previously silent:
- for im_livechat and website_livechat, the code was refactored to use
the standard mechanism that we use elsewhere to add data directly in the
page: we store the data in __session_info__, and the module that exposes
that data is always present, instead of having a module that's defined
conditionally, which causes issues when non-conditional modules depend
on it.
- in web, the `report_assets_common` bundle was used alongside
`assets_common` but without `assets_frontend` or `assets_backend`.
Reports do not need any js and it appears that it already had what it
needed as far as css is concerned except for one fontawesome override.
Code was changed so that the js from the bundle is not included and it
reports no longer use `assets_common`, the js part of the bundle is no
longer used.
- in website_slides, the `slide_embed_assets` bundle is used alongside
`assets_common` without using `assets_frontend` or `assets_backend`
which is required for `assets_common` to function, the approach here was
to simply take the files from `assets_common` and remove the files that
were causing issues. This bundle should be trimmed at some point, as it
contains way too many things that it does not need.
The file colors.js was also moved to core, as it isn't graph specific
and was causing dependency issues with a field that was importing it.
Fields shouldn't depend on files in specific views' directory.
closesodoo/odoo#104794
Related: odoo/enterprise#33909
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a many2one field with a domain set in the field definition in
python. Use this field in an editable list view, with a domain set
on the field node. For instance, go to Sales > Sales Team and see
Team Leader field.
Before this commit, we combined the field domain with the domain
set in the view, which isn't the spec. The spec is to use the
domain set in the view if there is one, and if there is not, use
the field domain (see _getDomain in basic_model.js).
In the scenario described above, it produced a crash because the
field domain couldn't be evaluated with the fields defined in the
view.
This commit restores the previous behavior.
closesodoo/odoo#105774
X-original-commit: 32654fd17ab366d20fff8b3fc8134ee209569f1d
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
QWeb views allowed to render QWeb templates rendered by the server in
a view.
Today, QWeb views are only used in website to see the hierarchy of
their views. The use case of website has now more sense in a client
action rather than an extension of a QWeb view.
This commit removes this view because it is not used anymore and will
probably not find any useful use case in the future.
closesodoo/odoo#103477
Related: odoo/upgrade#4016
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of this commit is to add extension points that allow code
to be executed before and after the save of a record.
CallBack:
onWillSaveRecord is a callBack that will be executed before the
record save if the record is valid if the record is valid.
If it returns false, it will prevent the save.
onRecordSaved is a callBack that will be executed after the save
if it was done. It will therefore not be executed if the record
is invalid or if a server error is thrown.
This commit will replace all the save overrides by the onWillSaveRecord
and onRecordSaved callBack.
Observed problem:
We could notice that each of the overrides of save in order to execute
for example a doAction after this one did not take into account the fact
that the save did not succeed.
For example, a required field is invalid and we try to save, then the
doAction will be executed without the "write" of the save.
The callBack onRecordSaved will prevent this common error.
closesodoo/odoo#105180
Related: odoo/enterprise#33710
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The code does not actually depend on mail features and it is intended to be used
in the base form view of user.
closesodoo/odoo#105415
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
\- Add 'Move to next stage'
Generic, we think it is a useful tool to have anywhere.
\- Change the 'Set priority...' command
to 'Set priority as Low/High' :
Only 1 command will be available with the 'not current' priority.
Specific, because it is used on selection fields,
which means there could be more than 2 options.
\- Transform the 'Set kanban state...' command into three commands
Generic. 2 commands will be available.
One for each 'not current' kanban state.
task-2857447
closesodoo/odoo#91821
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit adds the isAvailable option to the command. If you set this
option, then it determines if the command should be displayed or not
in the command palette.
Why add this option?
We want to allow a component to define a command that will be displayed
according to the internal state of the component
Part-of: odoo/odoo#91821
The goal of this commit is to fix indeterministic crashes
in Many2ManyTagsField test suite.
We could see that the wrong helper was used in some tests. We used
selectDropdownItem after an editInput on this same field.
Cause of the error:
editInput => event input debounce which causes the autocomplete to open.
selectDropdownItem => event click which causes the autocomplete to open.
After this event, a second click takes place to
select the dropdown item (call to clickOpenedDropdownItem).
The setTimeout is not patched, it is possible that the input event takes
place after the click which does not cause any crash. But if the click
event happens after the input then the autocomplete is closed before
the dropdown item is selected.
To solve this, we will patch the setTimeout and we will use only
clickOpenedDropdownItem to select the dropdownItem.
We also patched the setTimout in all tests to avoid indeterminate
behavior related to the debounce in the autocomplete input.
closesodoo/odoo#105693
X-original-commit: 36f6e6801166865e0c8047c1c2be43ef8826581f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the modified test sometimes failed on runbot.
We need to wait for an extra tick, because the dialog might be
rendered in another animation frame that the crashing client
action.
X-original-commit: fb73b9f08fbb315544b3a4fce727a4bf2fbaa1bc
Part-of: odoo/odoo#105693
Before this commit, performing a search in a m2o can block your ui
despite the result already being displayed.
Why?
When you perform your search in a m2o, a set of RPC queries are made
with the different search values (name_search). If the last search value
(the one that will be used by the m2o in its autocomplete) has already
been resolved, but one of the other RPCs has still not been resolved,
then the screen will remain blocked until all the rpc's have been resolved.
Solution:
Since we are only interested in the last rpc, we will cancel all the
others. So with each new rpc, we will cancel the previous one.
How to reproduce:
- Go to a form view with a m2o field
- Edit this field +- slowly (several rpc will be done with different values)
- Receive the result of the search. (The autocomplete is displayed with
the right values)
Before this commit:
If one of the other rpc's is not yet resolved, the ui will block
until all rpc's are resolved.
After this commit:
The ui will not block.
closesodoo/odoo#105286
X-original-commit: 1700416551725a70eca5597b6e106b43282c00d2
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, performing a search in a m2o can block your ui
despite the result already being displayed.
Why?
When you perform your search in a m2o, a set of RPC queries are made
with the different search values (name_search). If the last search value
(the one that will be used by the m2o in its autocomplete) has already
been resolved, but one of the other RPCs has still not been resolved,
then the screen will remain blocked until all the rpc's have been resolved.
Solution:
Since we are only interested in the last rpc, we will cancel all the
others. So with each new rpc, we will cancel the previous one.
How to reproduce:
- Go to a form view with a m2o field
- Edit this field +- slowly (several rpc will be done with different values)
- Receive the result of the search. (The autocomplete is displayed with
the right values)
Before this commit:
If one of the other rpc's is not yet resolved, the ui will block
until all rpc's are resolved.
After this commit:
The ui will not block.
closesodoo/odoo#105269
X-original-commit: 9917d841fa38ccc1e6d67875a665494dc22ef92f
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before, the `Layout` component was not friendly enough for
client action. There was no default component for `ControlPanel`
and `SearchPanel` in `Layout`, resulting in the fact that it had to be
defined manually in the client action environment:
```js
useSubEnv({
config: {
...getDefaultConfig(),
...this.env.config,
},
});
}
```
Now, the `Layout` component defines default component for `ControlPanel`
and `SearchPanel`. Making it easier to use for generic usage.
closesodoo/odoo#105413
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
... when re-opening the dropdown.
Before this commit, in an autocomplete component with an async
source, when:
- clicking on the input to open the dropdown,
- then typing something to filter the results
- then selecting one of them (which closes the dropdown)
- and finally re-opening the dropdown:
the previously displayed (and filtered) results were briefly
displayed, while the source was being fetched again. It thus
produced a weird and annoying flickering.
This commit fixes the issue by reseting the source before fetching
it.
closesodoo/odoo#105539
X-original-commit: 83769b00837f4eea29586f53709d65d3078ddce3
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the drag & drop feature for the Project "Tasks"
kanban view did not work if the drag sequence was initiated from the
title of the card.
This was due to the "o_kanban_record_headings" class having the CSS rule
`overflow: hidden`, because of a well known 6 year-long-and-counting
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1352061
Namely: mouse enter|leave events won't fire on anything underneath
elements having `overflow: hidden`.
This commit solves this issue by introducing a dedicated class name
'o_dragged' to all elements dragged using the `draggable_hook_builder`,
and defining on it the CSS attributes that were assigned in JS before,
as well as `pointer-events: none` on itself and all its children to
avoid the issue mentioned above.
Also in this commit: fixed a syntax error in a CSS rule in project's
"task_name_with_subtask_count_char_field" widget.
closesodoo/odoo#105353
Related: odoo/enterprise#33774
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a grouped list view, it was possible to have
empty groups when changing pages.
Why:
Before this commit, if a grouped list performs a load, then it is
checked if its previousParams are equal to the current one. If so, we
keep all the old groups empty. This requirement is related to the kanban
view, so we will move it to the kanban model.
The kanban view needs it when we archive data but don't want to delete
groups (colomns). So we perform a load but we don't want to delete the
empty columns.
How to reproduce:
- Go to a grouped list view
- Click on a record
- Return to the list view using the breadcrumb
- Go to the next page
Before this commit:
The groups on the first page are always present with those on the second
page. The groups on the first page are empty.
After this commit:
We only have the groups on the first page.
closesodoo/odoo#105488
X-original-commit: 04467197b9ec0851e3f9f7a74d1b97c5e27420bc
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, we had an issue with the width calculated
for data cell (see. sizeOfDataCell).
In some case, the width was 50% instead of taking 100% of the
available space.
This was because some elements of the inner groups that should not
have been visible were computed as if they were, taking an effective
slot in an innergroup's row.
E.g. with two labels:
Before:
"invisible label" and "label" on the same line with `style="width: infinite"`
"data field" on a second line with `style="width: 50%"`
After this commit:
"label" and "data field" on the same line with `style="width: 100%"`
Note that as `infinite` is not a valid value, this wasn't interpreted and
style attribute was empty.
Thanks to grid for still aligning elements even if they are technically
in different rows. It's why we only saw this issue because of the
width of the data cell.
Steps to reproduce:
- Go to Accounting
- Customer -> Invoice
- Create a new invoice
-> See Customer field
Thx to @kebeclibre
closesodoo/odoo#105489
X-original-commit: e177c63e3618e4b9e492a27d1301c098a0066cb6
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
When editing a m2m avatar field in the list view, keyboard navigation,
e.g. pressing arrow-left when the focus is on the right-most item,
results to a crash. Also, the "delete" button when in edit mode
is not there anymore so the user is unable to remove items.
This is because we are not building the proper list of tags. More
specifically, we fail to provide `onKeydown` and `onDelete` handler
to the tags, thus, it crashes and no delete button. This proposed
change fixes both issues.
closesodoo/odoo#105467
X-original-commit: 02a046708a96567a41b5f9aec0f71cefc92ab981
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
Before in a legacy client action, using a link to change view and
going back to the client action with breadcrumb does not restore the
scroll position.
Now with this commit, the scroll position is restored when going back to``
the client action.
Steps to reproduce:
- Install Accounting
- Go to `Accounting -> Reporting -> Balance Sheet`
- Unfold the tree to make the window scrollable
- Click on a link at the bottom of the window
- Go back to Balance Sheet
closesodoo/odoo#105443
X-original-commit: 225e809aa3ce1c506be69287e8084adf877547d7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Issue:** When creating a custom filter for a selection field,
the selected value is not properly displayed. Note however that
applying the filter still works. The problem is only in the displayed
value.
This is caused by setting the "value" attribute of the selection
element which is always an empty string (because formatField doesn't
properly work for selection field). However, the empty string is not
the issue because it doesn't matter what "formatted value" is returned,
it is not needed. The selection field's value is based on the value
of the selected option.
**Solution:** To properly show the display text of the selection item,
we need to make sure that value of the selection field is not overridden
during its onChange event. As a result, the selected option will become
the value of the selection field, displaying the proper text.
Therefore, in the onValueChange event handler, if the field type is
selection, we don't reset the value of the the selection element.
closesodoo/odoo#105420
X-original-commit: afadac5e21e6af2111ef42852243e78bb085d7c3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, when compiling a form group, the scope class is
added to the elements of the outer group. It was added on the element
class attribute. The issue is that FormLabel don't have a class
attribute but a className attribute. So the class wasn't shown on the
DOM.
Now, the class is added on the FormLabel className attribute and shown
in the DOM.
closesodoo/odoo#105315
X-original-commit: 214beb39d7c1a315255f0a5a842e60f73e7900cc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the labels tags that were after the fields losses
their attributes (i.e. classes) after the compilation of the form view
arch.
Now, the attributes are correctly copied after the compilation.
similar to : 873790f802
X-original-commit: 395bdf8880c5929652838a93351596b045708905
Part-of: odoo/odoo#105315
Co-authored-by: Patrick Hoste <pko@odoo.com>
Steps to reproduce:
- select a language where thousands separator is not (e.g. portugese)
- try editing any number input field
Bug:
error when parsing the new value when thousands separator is not defined
Fix:
fixed default value (only fallback to commas if it's not the decimal
Point separator)
opw-3041135
closesodoo/odoo#105312
X-original-commit: 71712acdf259aca7745a8a0b41a022d3abdcb047
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit [1] broke some confirm dialogs because the confirm and cancel
callbacks are not called with the same `this` anymore. Note that [1] was
actually not forward-ported here in 16.0 but now is via this fix.
E.g.:
- Install website
- Go to the page manager (/website/pages)
- Clone a page (choose a name and confirm)
=> Crash (this.$ does not exist).
Note that this flow was quickly fixed with [2] by changing the local
code instead of fixing the root cause (this commit here actually
technically reverts that change so it keeps working). This flow was
also not broken in 16.0 as the code was rewritten differently.
The work done at [1] actually needed some more rework than that to
handle two other potential usecases:
- If the confirm dialog handlers' promises are rejected, the dialog is
not closed (rightfully, like for example allowing to fill an empty
required input)... but [1] prevented to click on the button again
forever. With the same example as above, it can be reproduced: if the
RPC to clone the page fails, I cannot retry.
- If not both confirm_callback and cancel_callback were given, [1] only
prevented to multi-click on the related button (e.g. if you click on
"Ok", a RPC which takes 10 seconds is made, you click on cancel
immediately afterwards -> the dialog is closed while it should be
prevented (and would be if cancel_callback was given, following [1])).
That may not be entirely stable to make this change though but it
seems to make sense and be better (just keeping what [1] wanted here).
Note: this adds some more tests to check all of this + some more things
that were found during development. For example: [1] relied on the fact
that callbacks returned a Promise or nothing... while developers
actually were returning random things (for no reason as no way to get
the result anyway). Adding a test for this prevents to break that in
stable (the first iteration here crashed in such cases).
[1]: https://github.com/odoo/odoo/commit/4b8b079a7d9991a8dc481fe71a45185d672135c9
[2]: https://github.com/odoo/odoo/commit/8216341f5ad8d82ad0bcb0d1f01d874477d2de7b
Closes https://github.com/odoo/odoo/pull/103712
opw-3033878
opw-3043224
opw-3046485
opw-3042542
closesodoo/odoo#105081
X-original-commit: 90b280c221f3c0819cb0b291e102f161fc47507a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
**Issue:**
When a copy clipboard field is empty, there is no way to edit it
because the Field component is not shown.
This issue can be reproduced using any type of copy clipboard field:
- CopyClipboardChar
- CopyClipboardText
- CopyClipboardURL
Check the following video for illustration:
https://youtu.be/CTzqJRtwqv0
**Solution:**
This PR proposes a fix of *always* showing the copy clipboard field
(together with the copy button) even if the content is empty.
For illustration, check: https://youtu.be/jMM7zn_mFCU
**Notable changes:**
- The modified tests were using a wrong class name. But since they were
asserting the "non-existence" of the copy button, they were working.
- We are casting null text field to empty string (just like char field)
so that we avoid crash (in dev mode) when passing a "boolean" as 'content'
props to the 'CopyButton' component. This is asserted in the augmented
test case where we also try to render an empty text field.
closesodoo/odoo#104248
Task-id: 2861388
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Even if a many2many field is forcely set to be sortable, it should
not be included in the list of custom groupby options if it's
an un-stored field.
closesodoo/odoo#104978
X-original-commit: 9ba52387481bb0720c5d4f5d8a86c3ad6e801137
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Dardenne Florent (dafl)