After this commit, `colorField` is used instead of `cardColorField` to
handle color change from the dropdown of cards in the kanban view.
The value of `colorField` is observed in order to adapt the HTML classes
of `oe_kanban_card` (first `DIV` of `o_kanban_record`) by
adding/removing `oe_kanban_color_X` (where X is an index representing a color).
opw-3823860
closesodoo/odoo#161645
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
This commit fixes a bug where the value of an autocomplete with autoselect
could go into an undefined state where the model value doesn't match the
input value but no change is detected. This would happen on escape press,
scroll and more recently due to https://github.com/odoo/odoo/pull/159333
on click out. To fix this issue, the commit introduces some change in the
autocomplete behavior so that it will no longer select the active option
on click out (blur) when autoselect is active and instead it will revert
the input value to the one stored into the model. Also applies this
behavior on escape key press and scroll for the before mentioned reasons.
Steps to reproduce:
- Go to CRM form view
- Edit the salesperson name to some non existant one and click out (or
scroll or press escape)
Before the fix, the name was stuck to the invalid one but no change was
detected so we couldnt save it. Before https://github.com/odoo/odoo/pull/159333,
click out would select the active option of the dropdown instead (and
launch a dialog for quick create). This is removed because the behavior
is neither intuitive nor practical. After the fix, the name is reset to its
previous valid value instead. This applies to all autocomplete components
with autoselect prop set to true.
closesodoo/odoo#162040
X-original-commit: 9d9026ed0c7bb0af6cf910cc206cf8b55d1b7a36
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
This is a followup on [1].
In Chrome the event's currentTarget is cleared after events such as
"scroll" are handled. For asynchronously called methods to be able to
access it, the current value of currentTarget needs to be kept.
To help developers that might stumble on this issue when using
`throttleForAnimation`, this commit emphasizes the fact that usage of
that function is not limited to event handlers, and it adds a test case
that illustrates a solution for tracking the lost scroll event target.
No scenario was identified in 15.0, but this could be used as an
alternative solution for [1].
[1]: https://github.com/odoo/odoo/commit/0ba601d2ef5c4e2f846818e78dcd23966d6f563d
task-3449843
X-original-commit: 6cc4cbf2b91d624368c489460a90795921985f6b
Part-of: odoo/odoo#161850
Since [1] positioning of popovers targeting an element contained in an
iframe is permitted.
This commit will ensure the popper's element positioning is correct in
the following case: have a popper
- outside an iframe
- targeting an element that is inside it
- and no container element has been given (default is used)
**Before this commit**
The default container that is used is the target's owner document
element, a.k.a. the iframe's html element.
**After this commit**
The default container that is used is now the popper's owner document.
** Side notes **
This bug has been found when working for the following taskid-3603843
It is required for this task and will get fw-ported through the master
branch.
[1]: d6afa9f325closesodoo/odoo#161568
X-original-commit: e664b2367f482aa6edc492db16ec92ffff1ac0a1
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Have a form view that has twice the same x2many field, excpet the first one is invisible=1.
The second occurence has a context with the form_view_ref key.
The x2many should have at least one record.
```xml
<form>
<field name="x2m" invisible="1" />
<field name="x2m" context="{'form_view_ref': 'some_ref'}">
<tree>
<field name="display_name" />
</tree>
</field>
</form>
```
When opening a record, the context was not taken into account, yielding the wrong form view to open that record.
After this commit, the form_view_ref context key is taken into account, and the right form view opens.
opw-3845448
closesodoo/odoo#161253
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Install sales app.
- Go to settings of sales.
- See header field there is no download button.
Issue:
- Binary field should have download button and
user should be able to download file with out
issue.
Cause:
- Since Settings is abstact model so it does not
contains id field in it and download button visibility
depends on id field.
Fix:
- Extend binary field for setting view to get proper
file from related field where actual file is stored.
task-3620555
closesodoo/odoo#160070
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, we didn't correctly detect when to prefix the
value of an url field for the href of its link.
closesodoo/odoo#160916
X-original-commit: 27458e3bdb545f550e60f1bd39addf188151c38b
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, methods on python objects such as sets and strings were
implemented as functions returning a function returning the result.
While curried functions can be a great tool, they're also confusing at
first glance and in this particular case they can be easily replaced by
a simple function and the usage of Function.prototype.bind to bind it to
the correct argument. We also add a simple whitelist for pyjs functions
as a sanity check as it makes no sense to call JS functions from python
code.
With this change, we can also treat functions and methods from any
object more uniformly instead of having many return points that are
treated like special cases.
task-3762958
Part-of: odoo/odoo#139451
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes an issue regarding unwanted interaction between the
regular autocomplete option click selection and the onChange handler
from the input field hook used in the PartnerAutoCompleteCharField
component. This became an issue starting from https://github.com/odoo/odoo/pull/154203
because of the disappearance of the t-on-mousedown.prevent handler
placed on the autocomplete options list which would prevent the onChange
event from being triggered when clicking on an option. The issue would
be that the onChange handler from the input field hook would take
precedence over the option click handler of the autocomplete which would
most of the time be ignored afterwards. The solution found for This
problem is to prevent the immediate propagation of the change event
in the autocomplete handler when an option has been clicked on so that
it will never be propagated to the input field hook handler in this case.
Steps to reproduce:
- Go to contacts and open a company contact
- Type in the name field a few characters (at least 3)
- Click on any autocomplete option
Most of the time, the option will not be applied and the name won't change
closesodoo/odoo#160561
X-original-commit: aa1e5eabb67800fbf4155c9cae12b90d97bb75db
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
this commit fixes an issue introduced by https://github.com/odoo/odoo/pull/154203
which could keep the autocomplete options list opened even after a click
away when the user would "drag and drop" an option out of the list instead
of simply clicking on it. This is caused by the fact that the onInputBlur
code is directly terminated in this case (because of ignoreBlur) while
it is the only way for the autocomplete list to be closed in this case.
The solution is therefore to add an external listener on pointer down
which will always close the autocomplete list when clicking away from it.
Steps to reproduce:
- go to any autocomplete (crm salesperson for example)
- click on the input
- drag and drop a result outside of the list
- try to close the autocomplete list by clicking away
Before the fix, the autocomplete list would only close by scrolling
or clicking on the input once again.
X-original-commit: 57801ab7292e3d369615740a5f67aac9a4b9a521
Part-of: odoo/odoo#160561
Steps to reproduce
==================
- Go to Field Service
- Group by "start date: week"
- Archive every record in a column until there is only one left
- Go back to the kanban view
- Click on the single record from the column
- Archive it
- Using the breadcrumbs, go back to the kanban view
=> The group order is not preserverd and the empty one is the last one
Cause of the issue
==================
Before archiving the record, we have the following data:
`{group1: [1], group2: [2, 3]}`
After archiving the record, we have `{group2: [2, 3], group1: []}`
A new group is recreated from the old one, but it is always added at the
end.
Solution
========
We can insert the old group at his previous index.
The same solution was used in previous versions
opw-3816409
closesodoo/odoo#160121
X-original-commit: 0d44e931c40fbca005b8d1864cf2d07485ed84f8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when the clickbot detected an error dialog, it
stopped the test and throw an error saying that an error dialog was
detected. This information is not enough to check why, and how, the
error dialog was produced.
Now, we also log the content of the error dialog as well as all the
information of the last rpc that was in error.
closesodoo/odoo#160103closesodoo/odoo#160272
X-original-commit: 4f26b324a30c5120ea60b6b42fef6cd6000d2859
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Have an x2many with several pages containing a field with a
readonly modifier (in the view, not in the field definition), e.g.
`readonly="1"` in the arch. Have an onchange that returns an
UPDATE command for a record that isn't in page 1 (so a record we
haven't read), with a value for that readonly field. Before this
commit, the value was sent in the UPDATE command, even though
readonly fields shouldn't be sent.
The difficulty here is that we can't always evaluate those readonly
expressions, as they can depend on other fields, which we didn't
read if the record is in a page we didn't browse to yet. However,
"static" expression like `"1"`, or `"context.get('something')"`
can totally be evaluated, and they should. This is what this commit
does.
Steps to reproduce the issue:
- Install mrp
- Go to Manufacturing > Products > Bill of Materials
- New:
- Product: quick create "B1"
- Components: two lines: quick create "C1" and "C2"
- Save
- Manufacturing > Operations > Manufacturing Orders
- New [in that form view, set the limit of the x2many to 1]:
- Product: "B1"
- Save
- Change quantity to 2
- Save
=> Invalid Operation
opw 3819253
closesodoo/odoo#160129
Signed-off-by: Géry Debongnie <ged@odoo.com>
In some cases, sorting a sub-view list and then deleting one of its rows can cause a traceback.
This commit corrects this situation.
Here's a way to reproduce the error:
- Install `sale_management`
- Open a quotation
- Put enough elements to have two pages
- Modify the view via debug mode and change the list view limit from "200" to "2".
- Add 4 elements
- Sort with `product_uom_qty` field
- Attempt to delete the second element (i.e. the last element on the first page)
When deleting this line, a traceback is raised
Let's say we have 4 records with the following data
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
| 2 | Lamp | 1 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 4 | Board | 3 |
In this case we have two cached elements: the two elements visible on
the first page.
In the cache we have two complete records, by complete we mean a record
containing all the fields, for example:
```js
{
"1": {
id: "datapoint_4",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": {
id: "datapoint_11",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
}
}
```
After sorting by quantity, we end up with
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 4 | Board | 3 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 1 | Table | 6 |
It also changes at cache level, since we sorted via the `product_uom_qty`
field, we had to go and read the records on the next page (despite the
fact that they weren't displayed).
But as we only need the quantity information, we only fetch this field
from the records on the following pages.
In terms of cache, we have something like this
```js
{
"1": {
id: "datapoint_45",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
},
"3": {
id: "datapoint_16",
...
data: {
sequence: 10,
name: "Board",
product_uom_qty: 3,
display_type: false
...
}
},
"4": {
id: "datapoint_32",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": { //Chair
id: "datapoint_1",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
}
}
```
We therefore have one new incomplete record in the cache
The problem will occur when we try to delete a record from the first page,
if we delete `Board`, to have this
Page 1 (`1 - 2 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 3 | Chair | 4 |
Page 2 (`3 - 3 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
So we'll have to move the table that was on page 2 to page 1 (in our
case `Table`), except that when we render the list we'll have to compute
the required/readonly/invisible elements, and if we have a field that
has a readonly with the condition `not display_type` in our view, this
will cause a traceback because in the cache we only have this
```js
"4": { //Chair
id: "datapoint_32",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
},
```
`display_type` is definitely not in the data because we considered this
cached record to be complete.
This commit modifies the `StaticList._applyCommands` function to create
datapoints for all records that are not **entirely** loaded via `StaticList._getResIdsToLoad`.
https://github.com/odoo/odoo/blob/00898aef4dbeb469e0cec7eaea387de2755c6426/addons/web/static/src/model/relational_model/static_list.js#L898-L912
opw-3771077
closesodoo/odoo#159264
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before that commit, the search defaults would not be filtered when the
WithSearch is started with a search model state or updated by its parent.
closesodoo/odoo#159406
X-original-commit: dac527b7baa699cef0828a9d87a4c814ff3f7f05
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Before this commit, if a button had the attribute special="close" on the
footer of an x2many dialog, the dialog was not closed.
This occurs because the view button hook searches the dialog close
functions put in the environment by the dialog component, and in this
case is another component that initialize the hook, and the function is
not found.
Now, the view button hook will use the dialog close function put in the
environment by the dialog service.
closesodoo/odoo#159121
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- BooleanFavouriteField wasn't translated as the component was using
an untranslated variable instead of relying on the translation of
the template.
Some other translation fixing:
- ID Azienda is very generic, the correct name is Numero REA:
See: https://www.registroimprese.it/codice-fiscale-p.iva-rea
- No one calls a mobile phone "Dispositivo mobile", we already
translate it as the more common "Cellulare" even in the same file
task-3263708
closesodoo/odoo#157949
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Steps to reproduce
==================
In 17:
- Install hr_holidays,project
- Switch the language to dutch
- Go to project > three dots > Projectupdates
We can see `x/y Genomen`, it should be `x/y Taken`
Cause of the issue
==================
The original term is Tasks.
When loading the views, python translates them and changes Tasks to Taken.
Owl then translates the template and transforms Taken to Genomen.
Solution
========
Since the views are already translated, we don't need to translate them with owl.
We can simply set the attribute t-translation to off on the view root node.
opw-3787336
closesodoo/odoo#158627
X-original-commit: 454760e12145f8987e443d7776a614a5eb441feb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Open the code editor (wrapper around aceEditor) with an initial value -- in Odoo, that is any instance of the code editor.
Press Ctrl+Z.
Before this commit, the value disappears -- is undone -- even though no real change happened.
This was because we used editor.setValue, instead of editor.session.setValue. The latter resetting the undo history.
This behavior is "documented" [here: Common Operations](https://ace.c9.io/#nav=howto) with:
```js
//Set and get content:
editor.setValue("the new text here");
editor.setValue("text2", -1); // set value and move cursor to the start of the text
editor.session.setValue("the new text here"); // set value and reset undo history
editor.getValue(); // or session.getValue
```
After this commit, the initial value is not undoable.
opw-3793546
closesodoo/odoo#158548
X-original-commit: b33086599383a4c0ab43126598a63e8721f682fc
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a list view with multiple groupbys and a lot of records to
have pagers displayed. Open a group (first level). The pager of the
group uses the number of records instead of number of (inner)
groups as total.
This commit fixes the issue. The pager now correctly allows to
navigate through inner groups.
closesodoo/odoo#157995
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Steps to reproduce:
- Install planning app.
- Go to planning app, and convert the view to List.
- Group by Resource -for example-.
- Notice how the allocated time values are mis-aligned with the header label.
Investigation:
- in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8
- In the `getGroupNameCellColSpan` method:
- the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1`
- as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value)
- but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column.
The proposed fix:
- As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method.
- In our case:
- the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1`
- as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1`
- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct.
- But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes!
- the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0`
- as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2`
- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct.
- One last case, what if we have no aggregates
- both firstAggregateIndex` = `lastAggregateIndex` = -1
- we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1
- if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`.
opw-3764616
closesodoo/odoo#156647
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, it could happen that the More dropdown was
displayed, but it only contained a single stat button. This isn't
what we want, as that single button could simply be displayed
instead of the More dropdown toggler.
Task 3778382
closesodoo/odoo#156241
Related: odoo/enterprise#58565
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the changed test sometimes failed because we
expected the image to be set, but it wasn't (yet). This commit
increases the delay.
Runbot error 56099
closesodoo/odoo#157347
X-original-commit: 289e2b20673ba44fb8ce7afe19bae3bfa94e5f8c
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The way we cache the image is not right when that image is not on the
current record. For instance displaying a partner/user image. The unique
key used is not related to that record.
Introduced by https://github.com/odoo/odoo/pull/97544closesodoo/odoo#157199
X-original-commit: d127ec26d8e8d42c0e25668797cbd0f37203dc52
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: fja-odoo <fja@odoo.com>
Steps to reproduce
==================
In 16.4:
- Go to Accounting > Reconcile 8 items
- Click on the first line on the right
- Edit the label and then press Enter
- Switch to another line
=> Odoo Server Error
Cause of the issue
==================
When pressing Enter, two events are triggered: keydown and change.
In the useInputField hook, there is a listener for both of those events,
and they both end up calling `record.update` with the current value from
the input.
In the relational model, the update is locked inside a mutex.
So the first update (triggered by the keydown) does an onchange.
This onchange deletes the current records (Command.CLEAR) and returns
new records.
Once this is done, the mutex is released. The second update (triggered
by the change event) then tries the same update. Since the value was
obtained when queuing for the mutex, it uses the old (now deleted)
record.
Solution
========
This adds a test for https://github.com/odoo/odoo/pull/154991
as part of the fix got lost in a conflict resolution for previous versions.
opw-3726818
closesodoo/odoo#157155
X-original-commit: fbebffe446de9dd80db2dbe5ca7bd2746dc2a54f
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In some conditions, a x2many field can be considered
as modified by the webclient when in fact there is
no change in 'meaningful' stored fields.
In this case, on save, an empty list of magic commands
will be sent to the server, potentially triggering
unexpected recomputations.
Steps to reproduce:
* install sale_stock & sale_management
* create a new storable product
* create a new SO
* create a new line with this product
* Confirm the SO
* Set or Update the SO delivery date (Other info tab)
* Save
-> In the chatter, you will notice an useless tracking
value being printed for the SO Total, with identical values
before and after update.
Cause
Since the server received an empty list of commands for
the `order_line` field, this triggered a recomputation
of the total amounts of the SO, even though there were no
effective changes in the lines.
Solution
Do not send empty command lists for x2m fields.
This will avoid unexpected recomputation and also improve
performance since the fields were recomputed for 'nothing'
closesodoo/odoo#155549
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Bug
===
Since c5b87e130b , the Date / Datetime
are not formatted the way they suppose to be. So the value is not
correct (it contains the timezone, etc).
Because of that, the string "Invalid Date" is stored in database
instead of "YYY-mm-dd" when we change the default value in the
definition.
Task-3774178
closesodoo/odoo#155749
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The commit 7452f855f05251a5458ddb4d654b03be1b179d40 was fixing the
problem in a simple way. It however wasn't good enough of a fix as we
discovered we were triggering too many onChange after the forward port.
So we revert commit 7452f855, and backport 5ffc604 from 17.1. It adds
a method on the model to reset the validity of a field.
It was not what felt the best, but as it is working and we just want to
fix the problem in stable, we go for it.
opw 3680495
closesodoo/odoo#156139
X-original-commit: 2fa3fd751a968a15a76d322c53241022b4b18ef3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
User settings is used to store user's preferences, in web we use it
to store the home menus apps order and in mail for various settings like
push to talk key, discuss sidebar preferences, etc.
Before this commit, the `setUserSettings` method from the user service
overrided all the previous key that has not been changed because it
kept only the changed keys returned by the backend.
Leading to preferences being lost during the session when reordering the
home menu apps.
With this commit, we keep the previous keys that have not been changed.
Steps to reproduce:
- Go to the home menu
- In the Owl devtool check the settings object from the user service:
```JavaScript
{
"id": 1,
"user_id": {
"id": 2
},
"is_discuss_sidebar_category_channel_open": true,
"is_discuss_sidebar_category_chat_open": true,
"push_to_talk_key": false,
"use_push_to_talk": false,
"voice_active_duration": 0,
"volume_settings_ids": [
[
"ADD",
[]
]
],
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"project_todo.menu_todo_todos\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]",
"voip_username": false,
"voip_secret": false,
"should_call_from_another_device": false,
"external_device_number": false,
"should_auto_reject_incoming_calls": false,
"how_to_call_on_mobile": "ask",
"is_discuss_sidebar_category_whatsapp_open": true,
"onsip_auth_username": false,
"livechat_username": false,
"livechat_lang_ids": [],
"is_discuss_sidebar_category_livechat_open": true
}
```
- Reorder an app in the home menu and check again the settings object:
```JavaScript
{
"id": 1,
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"project_todo.menu_todo_todos\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]"
}
```
closesodoo/odoo#155902
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, if a SelectionField was used in a kanban view
alongside the HandleField (enabling re-sequencing, i.e. drag&drop),
the "select" element couldn't be edited. This is because the d&d
feature calls preventDefault on almost all "pointerdown" events
occuring in the card, and the "pointerdown" event is the one that
opens the select.
There's no usecase in 17.0, but there's one in master, in the
product document kanban view.
We fix this in 17.0 which is the version that introduced the kanban
version of the SelectionField.
closesodoo/odoo#155827
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Current behaviour
- when we access the daterange picker it was observed that the apply button
appeared flatter and was not vertically centered.
Expected behaviour
- add h-100 on buttons container to ensure they are vertically centered and no
longer appear flatter
- add close button in which action is similar to pressing ESC or clicking
outside the popover
Task-3624556
closesodoo/odoo#148812
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce:
============
- on Planning create new shift
- select a template
- change the end date
-> the end date is reset to the template value
Problem:
========
- `end_datetime` and `start_datetime` have the same compute method
- `template_id` depends on `start_datetime` and `end_datetime`
- so changing `end_datetime` triggers the compute method of `template_id`
that will read `start_datetime`
- reading `start_datetime` triggers the compute method of `end_datetime`,
that will check if `template_id` is set and if so, will take its values
-------
why the compute method of `end_datetime` is triggered ? :
-------
- `start_datetime` is not protected from recomputing, at this
line : https://github.com/odoo/odoo/blob/saas-16.3/odoo/models.py#L6746
we only protect the fields sent by frontend (only `end_datetime`)
- frontend doesn't send `start_datetime` as it was not changed
Solution
========
as ORM fix can't be made in stable, we send `start_datetime` in the `onchange`
query even if it's unchanged to make sure both fields are protected
opw-3693206
closesodoo/odoo#155705
X-original-commit: 7081372e721387da983621b3dd2986ae0872e4c8
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Before this commit, in a grouped kanban view with progressbars
and an aggregate field, after clicking on a bar to filter
records, the aggregate value was always 0 (at least when grouped
by a many2one or date(time) field).
This was due to a mismatch when trying to find the value of the
aggregate in the web_read_group result, as when grouped by a date
or datetime field, the key is `fieldname:granularity`, and we were
looking for the fieldname only. And for the many2one case, we were
comparing a pair [id, display_name] with an id.
This commit fixes the issue. It also fixes the mocked version of
read_progress_bar in the MockServer, s.t. we can correctly
reproduce the scenario in tests, as in the previous version, keys
in the returned object weren't computed the same way as in the real
read_progress_bar (e.g., "14,Mitchel", instead of "Mitchel"). A
similar fix has been done in [1]. This allows us to introduce a
test when grouped by many2one, which doesn't work as of 17.0.
[1] fd759f18d056844c486a68d0c394df5a03e789f0
closesodoo/odoo#155701
X-original-commit: 69b1809ed763d03560983bb0e4c996946dd694c5
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since Odoo v16, we also use grid in the form layout (inner group).
In a group we use the CSS `grid-template-columns` with the value of:
* `fit-content(150px)`: for the first column (TLDR: col max 150px)
* `1fr`: for the second column (TLDR: take the "remaining" max space)
```css
.o_form_view .o_inner_group {
grid-template-columns: fit-content(150px) 1fr;
}
```
These rules at the first glance seem correct.
But due to "big word"/language, some unbreakable text is overflowing,
to avoid this, we have added the `text-break` BS class.
So now all text can be "squash"/wrap if there is no space available.
The problem is when we have a text be too long and unbreakable in the
second column, the label (first column) is squashed to see only one or
two characters.
In our case, the bug happens when we upload a file with a big filename
to an "Attachement" (`many2many_binary`) field.
On the `many2many_binary` field there is a custom CSS rules:
```css
.o_attachment .caption {
white-space: nowrap;
}
```
that force the text to not wrap on the next line, and so the grid takes
the width of the file name as its min value for the width of the
second column, and "squash"/wrap the first column.
This commit fixes the issue by allowing the second column to be smaller
than the `max-content` width using the css `minmax(0, 1fr)`.
Steps to reproduce:
* Open "Marketing automation" app
* Create a New campaign ("New" button)
* Click on "ADD NEW ACTIVITY"
* Select the "Mail Template" field
* Create and edit a "Mail Template"
* Click on the "Options" tab
* Upload an attachment with a long name
=> BUG, all labels (first column) are "squashed"
Note:
* the `text-break` class is equivalent to:
```css
.text-break {
word-wrap: break-word !important;
word-break: break-word !important;
}
```
* when we use `Xfr` (X a positive numeric value `1fr` in our case)
outside a `minmax()` notation, the GRID specs[1] specifies that it
should be converted to `minmax(auto, Xfr)`.
* also the `auto`[2] in the case of `minmax(auto, Xfr)`the value
represents the largest minimum size (in our case, the file name).
[1]: https://www.w3.org/TR/css-grid-2/#valdef-grid-template-columns-flex
[2]: https://www.w3.org/TR/css-grid-2/#valdef-grid-template-columns-auto
task-3644267
closesodoo/odoo#155650
X-original-commit: dbf1794799f2be54e0a0da7719cde3e5069fcdd9
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
This commit backports the test introduced in odoo/odoo#155154, as
it is relevant to have it in every versions to ensure that dropdown
menu (i.e. submenus) are correctly tested.
closesodoo/odoo#155218
X-original-commit: 8915c8db63d2ebc697bbfc073e3504589a26b4b8
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Go to Documents activity view.
- Click on Schedule activity.
- Perform multiple clicks on any record.
Issue:
The 'Schedule Activity' wizard opened as many times as the record was clicked.
As a result, even after successfully scheduling an activity on that record,
the user still faced multiple open wizards remaining and had to manually close
each one of them.
Fix:
This commit introduces a method `executeOnceAndClose` which makes use of a
flag 'busy' to ensure that the `onSelected` function is called only once and
hence exactly one `Schedule Activity` wizard is opened, despite clicking a record
more than once.
closesodoo/odoo#154442
Task: 3721404
X-original-commit: 19cc5ea3cf2c8fcf742ba5ab9b4b82305d81d555
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes a pretty specific issue within autocomplete behavior
where the change event after clearing the value is prevented.
Steps to reproduce:
- go to an empty autocomplete and click on it
- start typing a search with results
- click on the first result
- without focusing out, clear the input and finally click out
No change event is triggered on click out in this case so the cleared
value is not updated in the end and saving the record will keep the
non cleared value.
The t-on-mousedown.prevent in the dropdown was mainly used to keep the
focus on the input after selecting a value for the autocomplete. This
introduces a side effect: when one starts typing on the initially empty
autocomplete, the browser keeps the initial value of the input in memory
until it is focused out (and therefore blurred). When the input is
focused out, it will compare the current value of the input with the
stored initial value and decide to trigger a change event based on the
comparison between the two values: if these are different, the change
will trigger. In our case, since the mousedown event on a search result
is prevented, no focus out will happen and therefore the browser will
still wait for the next focus out to trigger the eventual change event.
But since we clear the input before focusing out, the two values are
empty and no change event is triggered which introduces the issue.
To fix it, we remove the t-on-mousedown.prevent of the template and
manually avoid triggering the onInputBlur method with a flag to keep
the previous behavior and we finally focus on the input programatically
after selecting a value.
task-3734818
closesodoo/odoo#154448
X-original-commit: 9d3d5d937e37ab6ef0c393e11cfb449f2897f6c1
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Steps to reproduce:
1- Install Sales module
2- Activate developer mode
3- Navigate to any storable product
4- Click on 'Replenish'
5- Click on 'developer bug' and Choose 'Set Defaults'
6- Choose 'Scheduled Date' from the 'Default' dropdown menu and Save
Current behavior before PR:
When trying to set a default value for scheduled date in 'Replenish' for a product it will display an error for 'Invalid type' this is happening because when converting the string value to a datetime value it does not handle iso format date and this is the format that gets passed from the UI.
Desired behavior after PR is merged:
It is handled now from the UI side that the format that is been sent is the server valid format of datetime.
opw-3692472
closesodoo/odoo#154209
X-original-commit: 6dc46639935fdc175b2d094b58ef4e66c68466b0
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps to reproduce
==================
- Install account_accountant
- Go to settings
- Enable Budget Management
- Go to Accounting > Reporting > Management > Budgets Analysis
- Switch to the graph view
- Change the measure to "Planned amount" and then back to
"Practical amount"
=> The practical_amount measure is undefined,
The theoritical_amount measure is missing.
Cause of the issue
==================
The view is defined as follows:
```xml
<graph string="Budget Lines" sample="1">
<field name="crossovered_budget_id" type="row"/>
<field name="planned_amount" type="measure" string="Planned amount"/>
<field name="theoritical_amount" type="measure" string="Theoretical amount"/>
<field name="practical_amount" type="measure" string="Practical amount"/>
</graph>
```
The theoritical_amount and practical_amount are non stored fields and
thus are skipped inside `computeReportMeasures` unless they are passed
in `activeMeasures | additionalMeasures`. [0]
When parsing the graph view, the last field of type measure is
passed to the graph model and is the one that will be used initially. [1]
This is why the practical_amount is initially defined.
Solution
========
We simply need to keep track of fields of type measure.
This was the case in 14.0 but got lost in the conversion.
---
[0]: https://github.com/odoo/odoo/blob/e7a9ebec3176c37485643fcda2381e489a1df86f/addons/web/static/src/views/helpers/utils.js#L49-L60
[1]: https://github.com/odoo/odoo/blob/0fb64bef16914937cf4a1d1618fb58ade6d16f14/addons/web/static/src/views/graph/graph_arch_parser.js#L63
opw-3713613
closesodoo/odoo#153967
X-original-commit: 76178cd61ba10ff29b24183edb550c54b319a230
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
The string value of an empty array is `""` which is falsy. Prior to this commit,
if all optional columns headers were disabled in a list view, it would result in
a reset of those when the view is mounted the next time, instead of keeping them
disabled like in prior versions.
task-3692178
closesodoo/odoo#153831
X-original-commit: e600ed2fa2f2e612dfca20872356ae926dde0a54
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
Versions
--------
- 17.0
- 17.1
- master
Steps
-----
1. Go to Settings / Manage Languages;
2. select your current language;
3. set First Day of Week to something other than Sunday;
4. go to Time Off app.
Issue
-----
Weeks in year overview still start on a Sunday.
Cause
-----
Commit 52dae7a2f0 hardcoded `firstDay` to
Sunday for the `hr_holidays` module. This was a workaround to some
issues with `fullcalendar`'s week number calculations.
Solution
--------
Remove the hardcoded `firstDay`, and add a custom week numbering
function to be used on week, month, and year calendar views for
consistent numbering that allows for different first days of the week.
The function returns the ISO week number of the Monday nearest to the
configured first day of the week, i.e. the following Monday when first
day is set to Friday, Saturday or Sunday, the previous Monday if first
day is set to Tuesday, Wednesday or Thursday.
There were 3 main considerations for deciding a week numbering method:
1. no exisiting setting for users to decide on a method;
2. the ability to pick a first day of the week independent of locale;
3. the version of `luxon` used being unable to factor in locale.
Addendum
--------
This commit doesn't fix the issue with group-by week numbering in list
view. These stem from `babel`'s inconsistent locale defaults and
inability to take user-configured first day of the week into account.
opw-3668175
closesodoo/odoo#148623
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit's purpose is to fix the re apparition of personnal stage on
the todo app when personnal stages are deleted one after the other.
Step to reproduce:
-login as Marc demo
-open todo
-delete any personnal stage without any todo in it
-delete any personnal stage with at least one todo in it
The personnal stage deleted first is now present again in the kanban
view. Note that it is only a frontend bug. The record has been correctly
removed from the db, and any action with it will trigger a cache miss
exception and reloading the view completly will removed those ghost
stages definitly.
Source of the problem:
The problem is that the deletion is only reloading the view completly
when a record with child data is removed. More precisly, the
_deleteGroup function of the dynamic list triggers an rpc call to update
the config of the component only when a record with child data is
deleted, and that data need to be switched to another record, while when
it is an empty record, the record is simply removed from the group
field of the list. The issue is that there is thus a mismatch between
the group in the list.config.groups and the list.group. And when the
config is updated, only the list.config.groups is used to update the
config, meaning it potentially still contains element that were already
deleted.
Solution:
Doing a check up on the list.group to ensure that any deleted element is
also removed from the config when an update is triggered.
Note: I dont why Mitchel admin did not trigger the bug. Code wise, it
should happends no matter the access right of the connectedd user.
Version affected:
17.0+
task - 3553101
https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=formclosesodoo/odoo#142536
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
When the user creates new stages or groups in Kanban view and adds new tasks
with particular states and then if the user clicks on any colour in the
progressbar then the filter gets applied on all the groups or stages.
Observerd Behaviour:
The filter is applied on all the groups or stages.So, if we click on a colour
in the progressbar suppose colour Green to filter out Approved task(s) of a
particular stage then in that stage or group only the Approved task(s) would be
visible. Also the filter would get applied on all other stages or groups created
at that time. In those stages all the task with that state would be visible and
rest of them would get blurred.
Steps to produce:
- Install `Project` and add a new project in it.
- In the newly created project add some new stages or groups, each consisting
some new tasks.
- Give some states to those tasks through project state selector
(for eg: Approved, Changes Requested).
- Click on any particular colour in the `Progressbar` of any particular group or
stage.
Expected Behaviour:
When the user clicks on any colour in the progressbar then it should filter out
only those tasks which are associated with that color/state and only in that
particular group or stage.
Reason:
https://github.com/odoo/odoo/blob/579ee6d9792050955fa80346fd57ad294efcdd62/addons/web/static/src/views/kanban/progress_bar_hook.js#L114
group.serverValue results as Undefined. Because when the data is being prepared
here:
https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/dynamic_group_list.js#L222-L231C11
there is no serverValue provided. So, whenever a group is getting created
here serverValue `Undefined` as value.
https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/group.js#L25
Note:
- There was a need to change the function name from
`getServerValueFromGroupData` to getGroupServerValue as now now this function
calculates serverValue while the data is being created and not when the data is
already created.
- The function is exported into another file as this function defines the basis
to calculate serverValue and there is a necessity to calculate serverValue while
data is being created.
Task-3620697
closesodoo/odoo#149694
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When reading values in reactive objects, Owl's reactivity system will
return reactive versions of the sub-objects to allow tracking reads in
depth, so that changes to values in deep object hierarchies can still
cause components to render themselves if needed.
Luxon objects are immutable. Since they cannot change and values inside
them cannot change either, tracking reads within luxon objects is pure
overhead.
This commit makes luxon objects non reactifiable by setting the
Symbol.toStringTag property on the luxon classes, which is what Owl uses
internally to determine if objects can be made reactive. It will also
cause some of these objects to serialize to more specific strings
instead of just [object Object], eg [object LuxonZone].
closesodoo/odoo#153540
X-original-commit: ac58cb22cd8b275f89bf387a6cea8144ce26ee65
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Have a grouped list view s.t. there's a group with enough records
to have a pager in the group. Go to the second page of that group.
Then, apply a filter such that there's only a single page remaining
in the group. Before this commit, no record was displayed, because
the previous offset wasn't reset to 0 it should have been. With
this commit, the offset is recursively reset, so we correctly
display the records of the first page after a reload.
closesodoo/odoo#153494
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this PR, the `test_complete_chatbot_flow_ui` would sometimes fail
when checking if the user can add a reaction to a message.
There are two issues:
- This step uses the `contains` helper and specify the live chat `ShadowRoot`
as the target. However, the `contains` helper uses a mutation observer
that observes the light DOM thus, changes in the shadow root are not
correctly observed.
- The target passed to the `contains` helper is the `ChatWindow` DOM
element but this element can be unmounted in-between.
This PR fixes this issue.
fixes runbot-56670
closesodoo/odoo#153382
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit fixes an issue caused by the way we use onInput props in Knowledge to
fetch articles depending the current search value. Since we start from an empty
string in the input again, it make no sense to display the choices previously
fetched with a search value no longer displayed in the UI. The only way to display
the correct items is to update the input value, then put an empty search to fetch
accordingly.
This is clearly an issue, when the onInput props is used to fetch the content of
the SelectMenu, depending of the search value. The UI obviously display an empty
search, and filter accordingly, but without fetching the items corresponding to
the empty search value.
A test was added as well to assert SelectMenu can be used for this purpose without
forgetting to call onInput again when clearing the search value in beforeOpen.
closesodoo/odoo#153072
X-original-commit: ca417f171b1bd2dd567beed7bc0e1fcaba6c8a4c
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
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>
Achraf (abz)