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>
Steps to reproduce
==================
- Use a laptop with touch or apply the following patch
```diff
diff --git a/addons/web/static/src/core/browser/feature_detection.js b/addons/web/static/src/core/browser/feature_detection.js
index 21c6294b1b0e..64c4bc9b899c 100644
--- a/addons/web/static/src/core/browser/feature_detection.js
+++ b/addons/web/static/src/core/browser/feature_detection.js
@@ -62,6 +62,7 @@ export function isDisplayStandalone() {
}
export function hasTouch() {
+ return true;
return browser.ontouchstart !== undefined || browser.matchMedia("(pointer:coarse)").matches;
}
```
- Enable debug mode
- Go to contacts
- Hover the mouse over a question mark next to a field
=> Nothing happens
Cause of the issue
==================
The function `shouldCleanup` returns true when the device has touch and
the popover has been triggerd with the mouse
opw-3694156
closesodoo/odoo#152629
X-original-commit: 27242a0f1070b6b16c16e479e22dc0ccad0d9659
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, there was a race condition with the statusbar
field, and more specifically with useRecordObserver.
The issue could be reproduced in the form view of project.task. In
an existing task, belonging to a project with some stages, change
the project to another project with its own stages. It might happen
that the displayed stages weren't the ones of the newly set project.
If this didn't happen directly, this happened upon saving (i.e. the
correct stages are displayed just after switching the project, but
as soon as the user saves the record, the former stages are back).
This happens because useRecordObserver used an outdated version
of the props to get the domain (i.e. the props of the component
have been updated, but useRecordObserver still used the old version,
in particular the old props.domain).
This commit fixes the issue by ensuring that we always use the last
version of the props.
opw 3693113
closesodoo/odoo#152433
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
In form views, when the user closes the tab while having unsaved
changes, and if those changes are valid, we want to save them
automatically before leaving.
Before this commit, there could be situations where the changes
weren't actually saved. For instance, if they involved an heavy
payload for the write rpc, or if the network connection was poor,
it might happen that the xhr is killed. Or at least, browsers do
not offer any guarantee to wait for those xhr to reach the server.
Instead of a classical xhr, we thus use navigator.sendBeacon which
ensures that the data will be sent reliably [1]. There's a drawback
though, as its payload is limited. When the payload is too heavy,
sendBeacon simply returns false and does nothing. In this case,
we prevent the page from unloading and display a notification
suggesting the user to manually save his changes before leaving.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
Task 3537838
closesodoo/odoo#151834
X-original-commit: 0b53daa60ee5b370def21c8e0e30a6819597a0e4
Related: odoo/enterprise#55457
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, in the command palette, during a search, it is possible
that the value entered is modified. The problem only occurs if the namespace
has a debounceDelay bigger than 0 and at least one of its command providers is async.
How to reproduce:
=================
- Go to the command palette with the @ namespace.
- Type a few characters
- Re-enter a few characters
If you repeat this operation several times, some characters may disappear.
Why:
====
The value of the input is modified at each "input" event, but the searchValue
in the state is only modified when the debounce trigger "search".
Since the command palette template is contained in a slot, each state
change causes a complete rendering of the command palette. When the search is executed,
the commands are added to the state after each provider has generated them,
so a rendering takes place and it is the value contained in state.searchValue
that is used for the input and not the value contained in it before the rendering.
Solution:
=========
No longer modify state.searchValue during the search, but at each input event.
closesodoo/odoo#151906
X-original-commit: f4e1350e3a03c8a3a2b6bab8f4f74e278b1d2905
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce
============
- On a project, on a task
- create a subtask give it a name and from the list view click on the
"view" button
- you get redirected to form view to create a new task that is not related
to the parent task or the project
Problem
=======
When you click on the "view" button, the task is not saved yet, so the
subtask doesn't exist yet to be viewed in Form view
Solution
========
We prevent the redirection to the form view if the record is not saved yet
same logic as : https://github.com/odoo/odoo/commit/9b136383c2599301413e6770cc0ff204273b589d
opw-3681471
closesodoo/odoo#149753
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a form view in a dialog with an action button (e.g. a stat
button). Click on it. Before this commit, the action was executed
in the background, but the dialog remained open, which could
confuse the user and was definitely weird UX-wise.
With this commit, we automatically close all dialogs when we
execute an action which will update the main action container.
Note that this was working in previous versions thanks to legacy
compatibility code [1], but this code has no impact on the new
(wowl) dialogs, so as of 16.0, it has very limited impact.
Here's a specific scenario to reproduce the issue:
- go to the project task gantt view
- click on a pill
- in the task for view (in dialog), click on the external button of
the project many2one
- in the project form view (in dialog), click on a stat button (e.g.
"At risk")
-> before this commit, the 2 dialogs remained open.
opw 3644904
[1] https://github.com/odoo/odoo/blob/15.0/addons/web/static/src/legacy/action_adapters.js#L42
X-original-commit: 03fa39738c4f81ae30caaaa032c099797ecba9e7
Part-of: odoo/odoo#149543
Co-authored-by: Aaron Bohy (aab) <aab@odoo.com>
Sorting is being computed on each mounted select menu during the useEffect() hook since this commit: 8a44857.
This can lead to long wait times or browser crashes when there are many select menus with many options.
Before this commit, all of the select menu were sorted when the user select a value in one of them.
This is not necessary as the sorting is already handled in beforeOpen.
After this commit, no sorting is being computed in useEffect() anymore to avoid unnecessary computation.
A test has been added to verify the sorting happens when needed.
opw-3616438
closesodoo/odoo#151318
X-original-commit: f58b88383ce6a7439c02dbe761dc9025ddfe3b0a
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Co-authored-by: Luca Vitali (luvi) <luvi@odoo.com>
Recently, a new option 'always_range' has been added to the datetime
field (task 3628069, commit bc98aad). This option forces the display
of the arrow between the two dates from the start. Before that, you
would add a first date, click a button to add a second date and then
only would the arrow appear.
The oversight here is when the field is empty AND readonly. In that
case, you have an visible arrow next to the label but you can't do
anything with the field anyway. So better not to show it.
This commit makes sure to not display the arrow in this case.
task 3690523
closesodoo/odoo#149912
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes the behavior of the SelectMenu component when an option
is being used with an empty string or a null value.
Let's suppose we have the following choices:
{ label: 'Empty', value: '' },
{ label: 'Full', value: 'full' }
Before this fix, when selecting 'Empty', the value would be selected in the
menu, but the toggler would still be empty, as if no value was selected.
Now, any value corresponding to a choice value can be selected.
A test has been added for each value supported (null and empty strings).
Part-of: odoo/odoo#151276
issue:
- calendar mobile view (month) > pressing on a day or timeframe to create a task doesn't work
if the view does not have the "day" calendar scale set up
Fix:
- We are removing the condition preventing the renderer to use the createRecord callback when
the view is Mobile and in monthly scale
So now a record will be directly created when a user clicks on a timeframe in monthly view even
if he's in mobile view
Task-3677216
closesodoo/odoo#150624
X-original-commit: da23aa3d68e0f8b833d085c09bcf81d8aa2a4285
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The decimal property crash when added in a list view, if some records
have False as a value.
Technical
=========
Since fe797a03285ec9c81d29ed631839c91e2b9957a4 , we use the wrong
Formatter in the Float field.
Task-3698415
closesodoo/odoo#150682
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Hubert Van De Walle