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>
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>
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>
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>
Fix the rounding of the percentpie field value as it was sometimes
displaying a very long number due to python rounding precision.
The value is now displayed rounded to 2 decimals without trailing zeros.
Task-3648755
closesodoo/odoo#149226
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Open the Project module.
- Open any project.
- Add a subtask.
- Without manually saving the subtask beforehand, click on 'View'.
Form view of sub-task opens that doesn't have any of the fields it should
inherit from its parent task.
- Go back to the parent task using the breadcrumbs.
- Click on 'View' again. Now, the sub-task has all of its fields set as it should.
Issue:
- After clicking on 'View', the form view of the sub-task opens, but it doesn't
have any of the fields it should inherit from its parent task.
Cause:
- On clicking 'View', the switchToForm action is called, and this action
doesn't save records before switching to the form view. Also, it should load
that record into the Parent task after saving. In other modules, when clicking
on 'View', the openRecord action is called, which is also not saving data.
Fix:
- Records should be saved when the action is called on clicking 'View'.
For the project module, when the action is called, after saving the record,
it should also load records in the parent task.
task-3631285
closesodoo/odoo#147665
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce
==================
1. Install event
2. Go to Events
3. Configuration > Event Templates
4. Click on any event
5. Click on Communication
6. Add a line, change type to SMS
7. Type anything in Template
8. Click on Create "..."
9. The operation cannot be completed
Cause of the issue
==================
For many2one and many2many editable fields, the server sets the
can_create and can_write attributes on the field nodes. [1][2]
In some cases [3], those attributes are missing even though the fields
are actually editable. They are also absent for reference fields.
The `canQuickCreate` props was set to the following value:
`canCreate && !noQuickCreate`. When canCreate was absent, this was
evaluated to undefined, thus ignoring the noQuickCreate option.
Solution
========
When the permission attributes are missing, we have to assume that the
user has the appropriate permissions.
We also have to cast the extracted props to booleans as if you have an
props with a value of undefined, it will fall back to the default value.
In the test `no_quick_create option on a many2one when can_create is absent`,
we set the field as readonly and then cancel the readonly on the view.
This reproduces one of the bug of [3] which causes the permission
attributes to be missing.
-----
[1]: https://github.com/odoo/odoo/blob/fa6da3d63a3a4cce4e8ca788a49772925d318764/odoo/addons/base/models/ir_ui_view.py#L1296-L1297
[2]: https://github.com/odoo/odoo/blob/fa6da3d63a3a4cce4e8ca788a49772925d318764/odoo/addons/base/models/ir_ui_view.py#L1080-L1086
[3]: https://github.com/odoo/odoo/pull/138032
opw-3609799
closesodoo/odoo#148163
X-original-commit: efcb2a820bb57f1fae809725e799b3145fbbe599
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Before this commit, a Field using the useInputField hook can ignore values
from an onchange in some cases.
Problem:
=======
In order to know if it should apply the value of an onchange on the field's input,
the useInputField hook uses a useEffect which will check if the field is
not dirty (being edited) and if it is not invalid. If it true, it will apply
the value returned by getValue which often corresponds to record.data[fieldName].
By executing getValue, it will therefore start to observe changes in record.data[fieldName]
until the next render. If getValue is not executed then changes applied
by onchange on record.data[fieldName] are ignored because we don't observe record.data[fieldName].
Solution:
=======
Always execute getValue in the useEffect to always observe changes on
record.data[fieldName] and apply them correctly on the input if needed.
(It s a hack but we don't have a better solution for now)
How to reproduce:
================
- Go to a Form view with a field B with onchange and a field A (char field)
- Edit field B (an onchange is in progress)
- Insert a value in the input of field A
- The onchange is resolved with a value for field A
- The value in the input for field A does not change (because the field is in edition)
- Click outside the input for field A (trigger change event)
- Edit field B (an onchange is executed directly)
Before this commit:
The value returned by the second onchange is not visually applied to
field A. The old value is still present in the input.
After this commit:
The value returned by the second onchange is correctly applied to field A.
Its input contains the value of the onchange.
closesodoo/odoo#148711
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce
==================
- Set the zoom option on an image field (You can do it with studio
starting from 16.3)
- Go to a record and hover over the image
=> Nothing happens
Cause of the issue
==================
The tooltip is only displayed in readonly,
but with https://github.com/odoo/odoo/pull/100570 ,
the readonly mode has been removed.
So it only applies for views with the readonly attribute.
Solution
========
Always display the tooltip
opw-3646005
closesodoo/odoo#148534
X-original-commit: e0f9a7eedfb91ea46969490cf261548835844907
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, the StaticList and its Records shared the same
reference to the activeFields. When an x2many record was opened in
form view (and that form view wasn't inline), we altered the active
fields to add the information coming from the form, and we loaded
the corresponding data for the record we open. However, by doing
so, we also altered the active fields of all the other records,
for which we didn't load the corresponding data. From that point,
a rendering of those kanban records could lead to a crash, because
we iterate over active fields and make the assumption that there's
an entry for each of them in data, which isn't the case.
For instance, this happened in a dev branch in project, in mobile:
after opening a sub task in form view, if we switched to another
notebook tab and then switched back, there was a crash.
This commit fixes the issue by creating a copy of activeFields for
each Record, s.t. when a record is opened in a dialog, only its
activeFields (and those of the StaticList) are altered.
Note that activeFields of the StaticList must be altered in this
case to ensure that the onchange spec is properly generated, with
the fields of the form view.
closesodoo/odoo#148351
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
This commit fixes an issue about the last arrow button not taking the
`o_first` class in some cases.
With Odoo 17, we introduced a new behavior for our arrow buttons.
This behavior includes an invisible element placed before and after the
first arrow button on the left and right side.
While this is working fine as long as you don't have any hidden item
insie a dropdown menu, once you trigger a stage that was folded into a
dropdown menu, this invisible element appears on the right side.
Since we use the `o_first` class that sets a `border-radius` on the first
element on the right side, this invisible element was taking that
`o_first` class.
To fix the issue, we search for the first element within the scope that
does not have a `d-none` class, and we then add the class to that specific
element.
task-3628288
closesodoo/odoo#145453
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the StateSelectionField component handles the hotkey registration,
it was necessary to verify that an hotkey can effectively be added, instead
of trying to register to alt+undefined.
This issue happens when having more options in the selection field. Since the
code is written in a way each listed option should have an hotkey associated,
which is not the case, because the list of supported hotkeys has a length of 3.
The command is then added, without an associated hotkey.
A simple test case has been added, using the hotkey to set a state, and asserting
the presence of more than 3 items in the dropdown.
opw-3620129
closesodoo/odoo#148343
X-original-commit: ab572de20367f67aab4092b9e600e5ebd4cce4a6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
always_range option on the daterange widget allows to always display this
widget as a range (two inputs separated by an arrow) even if both
start/end date are empty and not required.
task-3628069
Part-of: odoo/odoo#145167
Before this commit, in a non-editable x2many in list mode, if there
is a field "A" with many2many_tags which is displayed as an x2many
in list mode in the form dialog, it cannot be reordered with handle field.
Problem:
When we extend a record from an x2many to a form dialog, we use the
activeFields defined in the form view and patch them with those in the
list view. Currently, we always use the default order from the list view
even if it doesn't exist. So we always ignore the one defined in the form view.
Solution:
If there is no default order in the list view, we use the one in the form view.
How to reproduce:
- Go to a form view with an x2many field in list mode which contains
an "A" field with the many2many_tags widget.
- Click on a record in the x2many
- A form dialog opens with field "A" in the form of an x2many in list mode,
containing a handle field.
- drag and drop a line to reorder the records
Before this commit:
It is not possible to reorder records
After this commit:
It is possible to reorder records
Task ID: 3641933
closesodoo/odoo#147253
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this change, anything passed in the context of a m2m
avatar field would not be taken into account because the context
was not passed properly in the many2many_tags_avatar_field template.
This commit fixes that and also adds a test for future testing.
task-3599601
closesodoo/odoo#146562
X-original-commit: 03202b7c790be266674e12b96a0b99f44ac773ed
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit:
The readonly readonly modifier of the statusbar field was not taken into
account when the "clickable" option was set.
After this commit:
Even if the "clickable" option is set to true, if a readonly modifier is
set, it will prevent (or not) changing the stage of a status bar.
closesodoo/odoo#145766
Opw: 3222998
X-original-commit: 9e1d01bc44e5e90ed2b809cfadbd05a5793b3c07
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Before this commit, during an onchange, when we received an update command
for an x2many referring to an unknown record on the front end (does not
have a Datapoint Record) during the save, we sent all the contents of
these commands without removing the readonly fields.
In this commit, we're going to filter all the readonly fields according
to the backend (fields). We're not taking modifiers into account because
the command refers to an unknown record, so we don't have the data to
evaluate modifiers correctly.
How to reproduce:
- Go to a form view with an x2many field
- Edit a field that causes an onchange
- The onchange command returns an "update" command for an x2many record
which is not on the actual page (unknown record) with a value which is readonly
according to the backend
- Click on the Save button
Before this commit:
The "update" command doesn't contain the readonly field
After this commit:
The "update" command contains the readonly field
Task ID: 3607260
closesodoo/odoo#145556
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If someone wants to show the label of the state_selection field then
it can be shown
like-
<field name="xxx" widget="state_selection" options="{'hide_label': False}"/>
task-3475416
closesodoo/odoo#136901
Related: odoo/enterprise#48060
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
When the width of the column is too small to fit the date, the date was
cut by the following column instead of having its content
truncated. This could be seen on the "Creation date" in the list view of
Sales Quotations.
task-3463329
part of task-3326263
closesodoo/odoo#144039
X-original-commit: b9675c38b49d99e00e401dbdb90445354aab43c3
Related: odoo/enterprise#51684
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Previously, the datetime field read the value for readonly directly in
the attrs when extracting its props when available. This resulted in 2
separate bugs:
- in debug mode, props validation of the datetime picker would fail, as
it expects to receive a boolean for the `range` prop. This was caused
by the fact that required was the raw attribute (a string) instead of
the boolean and ended up being propagated to the `range` prop
- outside of debug mode, the value for required did not cause a crash
but any value for required that was not empty would be interpreted as
truthy, causing the field to always be display itself as though it is
required. In non-range mode, this is invisible, but in range mode, it
would always show the second datetime input and the arrow between the
beginning and end date, even with required being 0/False, or a python
expression that may evaluate to false
This commit fixes that by instead reading the value for required from
the dynamic infos provided to `extractProps`, which will always be a
boolean and contain the value of the evaluated expression when
appropriate.
closesodoo/odoo#143509
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes an issue where if one sets no_create_edit and
no_quick_create to true on a m2o while no_create is unset, no dropdown
is shown to tell the user that no record was found. Since the quick create
and create and edit options are disabled by default when create is false,
we no longer need it in the condition and can only rely on quick create
and create and edit.
task-3599696
closesodoo/odoo#143202
X-original-commit: 9da78c1b2bdd85f06e8682b99c8c481e91546ec7
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
When we save a many2one in a dialog opened by the external button, we
trigger a "read" of the "display_name" to update it if the changes made
in the dialog have had an impact on it.
Before this commit, the context used for this "read" was completely wrong,
it was an unevaluated string. This commit will therefore allow you to use
the evaluated context.
closesodoo/odoo#142862
X-original-commit: 7e9c8d41f5d035a00117198539ddebdbd8b4aa7c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, if the value of an image/sign field is modified by an
onchange and the record is saved manually, the old image is displayed.
Why:
ImageField's rawCacheKey, which is used to know if the image has been updated,
is not updated. So we will reuse the old image.
Solution:
rawCacheKey becomes a getter that always returns the current value of __last_updated.
How to reproduce:
- Go to a form view with a char field and an image field
- Edit the char field
- An onchange is performed and modifies the value of the image field
- The new image is displayed
- Click on the save button
Before this commit:
The old image is displayed
After this commit:
The new image is displayed
closesodoo/odoo#142471
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, if we have x2many fields which contain a virtual
record with the many2many_tags widget, a server error will occur during
a search because the "name_search" will be performed with a domain containing
a virtualId.
This commit will therefore filter the virtualId when generating the domain
used by the "name_search".
closesodoo/odoo#141269
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a form view with an x2many in non-editable list mode,
creating a record by clicking on "Save&New" allows it to be edited inline
despite the list view not being editable. The purpose of this commit is
to prevent this from happening.
How to reproduce:
- Go to a form view with an x2many field in non-editable list mode
- Add a record
- Edit the new record
- Click on Save&New
- Edit the new record
Before this commit:
The new record is in edition in the list view
After this commit
The new record is not in edition in the list view
Part-of: odoo/odoo#141269
Before this commit, in an editable list view (or in x2many), you need
to click twice on a boolean field to change its value. The first to set
the record to edit and the second to toggle the value.
The purpose of this commit is to simplify this flow by only requiring one click.
How to reproduce:
- Go to a form view with an x2many in editable list mode that contains a boolean field.
- Click on the boolean field of the first record
Before this commit:
The record goes to edition and the value of the field has not changed.
After this commit;
The record goes to edition and the value of the field has changed.
closesodoo/odoo#141153
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In many situations, when you click on a button, you want to disable all
the other buttons while it is running.
Currently, in each of these situations, we duplicate the same code that
disabled all the buttons and enabled them afterwards. Unfortunately, in
many cases, if the code executed crashes, the buttons are not enabled.
In this commit, we're going to create a helper so that we have a single
version of the code that correctly handles crashes. This helper will
disabled all the buttons, then execute the click code and enabled all the
buttons afterwards. If the code crashes, it will also enbaled them.
The problem has been reported for the Settings Form view:
When you edit this view and click save, if an error occurs in the save,
all the buttons remain disabled.
closesodoo/odoo#140938
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a many2many_tags field with onchange and on a slow network, quickly
add or remove tags several times. Each call to update sends a command 6
(SET) based on the current state of the record (typically here,
the very initial state). For example, if there're 2 tags [1, 2] in the
relation and I add 3, a command 6 with ids [1, 2, 3] is sent. If I
quickly add 4 before the onchange returns, another command 6 with ids
[1, 2, 4] is sent. At the end, 3 would not have been added to the
relation.
With this commit, we don't use the command "set" anymore. Instead, we
use a combinaison of commands "link" and "unlink" to add and remove
records from the relation. This way, we don't need to know the current
state of the record, and we can be sure that the final state of the
relation is the one we expect.
Task-id 3522153
closesodoo/odoo#140644
Related: odoo/enterprise#49995
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes an issue with the domain field where a traceback would
be launched when an invalid domain is received. It also changes how
invalid domains are displayed in foldable domain fields so that only the
content of the domain selector component is displayed in this case.
closesodoo/odoo#140719
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit changes the behavior of the domain field such that it
performs a quick validation of the domain after it has been edited in
the debug input. This solves an issue where the isValid state was not
properly updated after debug input edition.
Part-of: odoo/odoo#140719
Purpose:
-------
The "StockMoveX2ManyField" custom field has given rise to a new need,
that of being able to edit a record in an x2many directly or from a dialog.
This is the first use case to require the ability to do both at the same time.
This particular use case highlighted a bug preventing a change from being saved.
How to reproduce:
- Go to a form view with an x2m using a custom widget
- Open an x2m record in dialog mode
- Close the dialog
- No changes have been made to the record, so the save button is not displayed
- Edit a field in the same record
Before this commit:
The save button is not visible
After this commit:
The save button is visible.
closesodoo/odoo#140298
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Purpose:
--------
Before this commit, if you edit a char field with an onchange in
an x2many, the FormStatusIndicator buttons will flicker.
How to reproduce:
-----------------
- Go to a form view with an x2many field in list mode
- Type a char in the char field of a record
- The FormStatusIndicator buttons are visible
- Click outside the char field
- An onchange is triggered
Before this commit:
The FormStatusIndicator buttons will disappear until the onchange returns.
After this commit:
The FormStatusIndicator buttons remain visible.
closesodoo/odoo#140179
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
This commit removes the requirement that the records count should be
set before the edit domain button is shown for domains which must be
edited in a dialog. This could be annoying in cases the records count
loads slowly.
task-3561782
closesodoo/odoo#139969
X-original-commit: f2ba825eac5e4bda3d1b1d3676a1b737701c0fb8
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
When ReferenceField uses an M2O field. The model is not updated along
with the props when the model field is updated.
Because of this, the onWillUpdateProps hook will keep trying to update
its value. This results in an infinite render loop.
task-3248500
closesodoo/odoo#139954
X-original-commit: f8f6aaa5e32967d6c7cd888fbe574acdc6f79dc6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Currently, users who want to change the visibility of product's
documents need to open their form view and edit it.
The selection widget now allows users to quickly edit the way a document
is displayed to their customers from the product's documents kanban view.
Part-of: odoo/odoo#137975
This commit is part of a serie of commits which aims at simplifying and
reorganizing js files in the web addon
closesodoo/odoo#139156
Task-id: 3508223
Related: odoo/enterprise#49212
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose:
--------
The "KanbanPropertiesField" has been renamed to "CardPropertiesField".
For consistency, the key "view_in_kanban" of the properties definition
is renamed to "view_in_cards"
Task-3458627
Part-of: odoo/odoo#132578
Purpose:
--------
This commit rewords the "KanbanPropertiesField" to "CardPropertiesField"
and add it as widget to use for properties fields in calendar views.
The rationale is that the "Show in cards" option of properties should
allow to enable the visibility of properties in kanban cards and in
calendar popovers (as it is currently the case in knowledge).
Task-3458627
Part-of: odoo/odoo#132578
Since https://github.com/odoo/odoo/pull/137098, we add a fallback for
false display_name in the form view, but we didn't add it for the list
view which doesn't instantiate the Many2one component. It uses
`formatMany2one` instead. Fix it to be consistent with the Many2one
closesodoo/odoo#139215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Before this commit, if you click twice on a record in x2many, two dialogs
are opened containing the same record.
Solution:
=========
Prevent a record from being opened as long as a record in this x2many
is already open.
How to reproduce:
=================
Go to a form view with an x2many
Click on the first record in the x2many
Click a second time on the record of the x2many (before the dialog is opened)
Before this commit:
-------------------
Two dialogs are opened with the selected record
After this commit:
------------------
Only one dialog is opened with the selected record
closesodoo/odoo#138984
X-original-commit: 31a9b13
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Steps to reproduce
==================
- Install purchase_product_matrix,web_studio
- Go to purchase
- Click on a record
- Open studio
- Click on the "Products" tab > Edit List view
- Edit the product field
- Widget: Many2one
- Disable creation: enabled
- Close studio
- Create a new record
- Add a new line
- Type some random text in the product field
-> The option create is available
Cause of the issue
==================
When the can_create attribute is not passed, the `canCreate` ends up
undefined. This means the default value of true is used and the
`no_create` option is ignored.
The can_create attribute should actually be passed and there is a bug in
python in the `_editable_tag_field` function, but it is not something we
can change in stable due to the fact it it requires an explicit change
in some views to pass the validation and thus, this requires an addon
upgrade (`-u ...`).
See https://github.com/odoo/odoo/pull/138032
opw-3432903
closesodoo/odoo#139068
X-original-commit: 4b6756e1775488e230bc25767adf5744f0ea9149
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, adding more records to a many2many field than the
limit of the pager did not update the pager. This commit fixes this
issue by updating the limit of the pager.
closesodoo/odoo#138883
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the status bar field could be displayed in 2 ways:
- in small screens: as a dropdown
- in larger screens: as an inline list of buttons
This commit centralizes both of these approaches into a dynamic display
that fits the available space:
- the current stage is always displayed;
- previous stages are displayed behind or contained in a dropdown if not
enough space;
- next stages are displayed behind or contained in a dropdown if not
enough space.
Task 3336856
closesodoo/odoo#124267
Related: odoo/enterprise#48706
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
We improve various aspects of the domain selector:
- We make the domain selector be able to display all domains accepted by the class Domain (domain.js)
- We improve the edition/selection of values, e.g. for the operators in/not in
- We improve/simplify the style/dom
Task IDs: 3507123, 3508940
closesodoo/odoo#128680
Related: odoo/enterprise#48324
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mathieu Notté <mano@odoo.com>
We move the filterable widget from loyalty to web to make it more widely
accessible to other applications. It will soon be used in the new activities
plan feature.
Following the move of the filterable selection widget to the web module, we do
some light cleanup.
Task-3390865
Part-of: odoo/odoo#137969
The goal of this commit is to cause a recalculation of specialData when
this depends on a record value.
Currently, specialData are only calculated during onWillStart and
onWillUpdateProps. But the specialData of certain fields do not depend
only on the props, they can also depend on the values present in the record.
We therefore want to recalculate them when the value of the record changes.
How to reproduce:
- Go to a form view with a field "x" and
a field with specialData dependent on field "x".
- Edit the field "x"
Before this commit:
The specialData have not changed
After this commit:
The specialData have been recalculated.
closesodoo/odoo#138372
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of this commit is to resolve two issues relating to the properties field:
Issue 1:
========
In a list view, when you edit a property and then select another field
in the same record, the edition disappears.
How to resolve:
--------------
Do not delete the changes linked to the property in record.update.
How to reproduce:
----------------
- Go to a list view with a properties field containing a property char
- Insert a value in the char property
- Click on another field in the same record
Before this commit:
The inserted value disappears
After this commit:
The inserted value is still present
Issue 2:
========
The fields/activeFields only take into account properties received
during the initial web_read and not those added by an update or an onChange.
How to resolve:
--------------
Generate property fields and activeFields during parseServerValue
(web_read and onChange) and during an update.
How to reproduce:
----------------
- Go to a form view with a properties field
- Editing a field with an onChange
- The onChange returns a new property for the properties field
Before this commit:
A crash is displayed
After this commit:
The new property is displayed correctly
closesodoo/odoo#137989
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds the recently removed add condition button to the folded
domain field so the user can unfold the domain and add a new rule in one
click.
Task-3525269
closesodoo/odoo#137663
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Purpose:
--------
When the property field is added into a form view, the "add a property"
button is shown by default.
However, most of the time the users won't add properties when opening a
form view, making this button take up space for nothing.
To alleviate this issue, commit [1] added an option that allows to hide
this button, and added actions to allow adding properties from the cog
menu instead.
Now that properties are being added into several views, one would like
this "add properties" button to be hidden by default, and show an entry
in the cogmenu allowing add properties by default, without needing to
create an action for every view using a property field.
Therefore, a new static action "Add Properties" has been added in the form
controller that is available if a properties field has been encountered
during the parsing of the form view's arch.
The "hideAddButton" has been changed into "showAddButton" and now allows
to show the "Add a Property" by default.
Task-3458627
[1]: https://github.com/odoo/odoo/commit/1f80810e39f811122a65e11cd8cac99aa39a7960
Part-of: odoo/odoo#137589
Abdelouahab (abla)