Since https://github.com/odoo/odoo/commit/28e6b7eb83e4309c4e70974d947194bdca240865, the boolean toggle widget
trigger a save when the user clicks on it. This is a problem when the
widget is used in a form view opened from a o2m list, because the
record updated is saved immediately, even if the user clicks on the
discard button.
This commit adds a new option to disable the autosave on the boolean
toggle widget. To disable the autosave, add `autosave: false` in the
options on the field definition.
Task-id 3235962
closesodoo/odoo#120000
X-original-commit: b56e58dff3258698dbbf173bc6790a35a47131b0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Suppose a RelationalModel instanciating a record.
On this record, trigger an onchange adding a new line on a one2many field.
=> The values of the Command.create command is not parsed correctly.
Indeed, if your one2many contains a Date field, its value will be a string and
not a Datetime object as expected.
closesodoo/odoo#119928
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds two autoresize hooks for text inputs and textareas to
make it adapt their size (width for text inputs, height for textareas)
depending on their content.
The commit therefore solves the issue of several form view task titles
being restricted to 1 line while it can be annoying if the title is too
long. The autoresizeTextarea feature was moved from TextField to the
autoresizeTextarea hook and the autoresizeInput feature was moved from
the AutoresizeInput mail component to the autoresizeInput hook.
The TextField component has a new option for disabling linebreaks.
task-3138826
closesodoo/odoo#117355
Related: odoo/enterprise#39493
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit:
The AceField component used the ace library to provide the user a code
editing field
After this commit:
The AceField component is now using the CodeEditor component and the usage
of the ace editor lib is now abstracted behind the component.
closesodoo/odoo#117782
Related: odoo/enterprise#39365
Signed-off-by: Géry Debongnie <ged@odoo.com>
We refactor the ModelFieldSelector and ModelFieldSelectorPopover
components.
We also improve a bit ModelFieldSelectorPopover:
- on first page, the button to go back is no longer available
(so that it is now more difficult to produce an invalid path)
- we always start with a page presenting the model where the last
selected field name belongs to
- the keyboard navigation is improved
- click on model field selector opens the popover with the focus in
the search input (if any)
- for relational fields in popover: the user can either click on the
relational field (and select it) or a special button that make him
follow the relation to the field comodel
We also refactor the hook useDynamicPlaceholder to make it use a new
component DynamicPlaceholderPopover that uses ModelFieldSelectorPopover.
Task ID: 3272798
closesodoo/odoo#117951
Related: odoo/enterprise#39673
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
This commit fixes a use case where a user would not be able to access the
property field values of a record because he did not have access to that
record's parent (from the property field definition configuration).
In a concrete example:
- In the Knowledge App
- Marc Demo has access to the "Article B".
- The parent article of "Article B" is "Article A".
- Marc Demo does not have access to "Article A".
- Article B has some property fields values configured.
- If Marc Demo tries to open "Article B" -> crash
This is caused by the framework having to read the property definition from the
parent record, which we don't have access to.
A "sudo" was added to allow that use case (which is supported).
In addition, this commit also adds further checks on the web client side to
gracefully handle a special use case where the end-user could not write on the
parent record because of record rules.
(It only checked *access rules*).
To avoid making an extra RPC every time we load the record (to check if we can
write on the parent), we only make that check when the user tries to modify
(add/edit/remove) a property and show a proper error message.
(This also applies when creating new property field tags).
Task-3062064
closesodoo/odoo#118929
X-original-commit: bc538f6944461a642bac0f757ec96d7f8cc14c9a
Related: odoo/enterprise#39946
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce
==================
- With the Chrome devtools, add a network delay of 1 second
- Go to Purchase
- Create RFQ
- Add vendor
- Add products and navigate by using the 'TAB' key
- Add another product line
- Repeat process quickly
`this.list.editedRecord is null`
Cause of the issue
==================
Order of events:
- First tab pressed
- onchange_1 triggered
- Second tab pressed
- onchange_2 triggered
- onchange_1 resolves
- The editedRecord is switched to readonly
- onchange_2 resolves
- There is no more editedRecord
opw-3115650
closesodoo/odoo#118760
X-original-commit: af5cedf078b439710e8801374ace524de54f3b66
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
**Before this commit**
Since 394f85c954f anytime this hook opens a popover, a traceback occurs.
It is due to the fact this hook passes a callback as a
getter-only property to the usePopover hook options.
The traceback occur because the usePopover
hook has to reassign this option (onClose callback).
**After this commit**
Fixed and tested.
closesodoo/odoo#118580
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Currently, the Many2XAutocomplete component is not reactive: The component
gets the model to load from its props and the component uses a hook to
initialize and open a SelectCreateDialog dialog for that model. The issue
is that the name of the model is copied and set in the setup function of
the Many2XAutocomplete component. When the model changes, the function
opening the SelectCreateDialog dialog is not updated and will hence still
use the name set initially.
Steps to reproduce the issue:
1. Create a new property field of type Many2one or Many2many
2. Choose a model
3. Click on the "Default Value" field
4. Click on the "Search More..." link from the dropdown
5. Choose another model
6. Click on the "Default Value" field
7. Click on the "Search More..." link from the dropdown
=> The modal displays records from the first model picked.
To fix the issue, we will simply put a `t-key` attribute on the component.
The component will then be reloaded whenever the given key changes. The
model loaded by the SelectCreateDialog dialog will then be updated properly
whenever the given model changes.
task-3192917
closesodoo/odoo#118505
X-original-commit: e9fcc1c950129cdb253df3df2ed7197e3de55fd3
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Banken Julien (jbn) <jbn@odoo.com>
The objective of this commit is twofold:
- improve the style of the DomainSelector component, in particular, the
style of the control buttons "Add node", "Add branch", and "Delete node".
- add the possibility to reset the domain when the current domain is not
supported. The debug input is also always visible in that case
if the debug mode is active. It is displayed in readonly iff the
corresponding DomainSelector prop is set to true.
Task ID: 3269923
closesodoo/odoo#118057
Related: odoo/enterprise#39512
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
The old submenu "Add Custom Filter" of the menu "Filters" is now replaced
by a menu item "Advanced Search". Click on that item will open an
"Advanced Search" dialog in which the current search domain is displayed
in a domain selector. It is then possible to easily add/remove/edit some
parts of that domain before make a new search with the edited domain.
Task ID: 3269923
Part-of: odoo/odoo#118057
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
This commit ensures that keys ending with _view_ref are properly
removed from context when using create and edit action
opw-3256019
closesodoo/odoo#117471
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Install appointments
- Log in as Marc Demo
- Go to Calendar/Online appointments
- Click on a record in the availability x2many fields
Current behaviour:
It opens the record in a form modal.
Expected behaviour
It should not open the record since #110838 because the x2manyfield
is in `editable="bottom"`.
closesodoo/odoo#118225
X-original-commit: d4399a87f1ca59389d7e58754b67c3fc816cb25a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when clicking on "Attach files" in discuss
composer, then removing it, it was not possible to upload the same
file again.
This happens because file input of file uploader relies on `change`
from the input. The `input.value` contains the filepath, so if we
upload the exact same file without clearing the value, the value
will be unchanged and it won't trigger uploading as a result.
This commit fixes the issue by clearing the input just after
the file has been uploaded, so that we can upload the same file.
Cannot reproduce bug in QUnit tests because `inputFile` helper
programmatically always trigger "change" on input file.
closesodoo/odoo#117704
Signed-off-by: Luca Vitali <luvi@odoo.com>
We move the function loadFields from the view service to a newly created
field service. That service can also be used to load model fields for a
given path (loadPath), i.e. load all model fields for the models
traversed by the given path.
We use loadPath in useModelField and DomainSelector.
closesodoo/odoo#117882
Related: odoo/enterprise#39418
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This improvement will give a visual indication that the progress
has gone over 100% by changing its color.
As, depending on what it measures, it could be positive or negative,
we add an option to the widget to determine the class (color)
that should be used.
task-2909337
Part-of: odoo/odoo#96104
Steps to reproduce
==================
- Go to the product page
- Open studio
- Click on the picture and set the size to large
- Save and quit studio
- -> The size doesn't change
Port of https://github.com/odoo/odoo/pull/87087
opw-3217741
closesodoo/odoo#117423
X-original-commit: 63a3466c805c09989e5e022519e1ba450ecb1053
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Using the same image on new records does not work without refreshing the
page
Steps to reproduce:
1. Install Sales
2. Go to Sales > Products > Products and create a new product
3. Set a name and an image on the product
4. Create a new product (with the 'New' button in the top right of the
form)
5. Set the image used previously on this product
6. The image does not save
Solution:
Add a `t-key` on the FileUploader in order to recreate a FileUploader
when we open a new form
Problem:
The FileUploader component is not reset when we open a new form (the
files previously uploaded are still present on the FileUploader).
`onFileChange` is thus not called when we use the same image, as the
file hasn't changed.
[This commit] in master fixed the same issue by resetting the
FileUploader after each upload so we can revert it
https://github.com/odoo/odoo/blob/7710c3331ebd22f8396870bd0731f8c1152d9c41/addons/web/static/src/views/fields/file_handler.js#L66
[This commit]:https://github.com/odoo/odoo/commit/18384bb519d95e937ea4cfdd660ac08ba89214c0
opw-3151756
closesodoo/odoo#117252
X-original-commit: 3b04edc80f916b3b02a6abc7e88de32e53593fc2
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The commit change the design of the Many2ManyAvatarFieldPopover the goal
is to remove the m2m dropdown and fill the dropdown content directly
inside the popover.
It also reverses the order of the displayed tags inside the m2m avatar
field in the kanban view and inside the popover.
It removes the possibility to unassign users on mouse hover in kanban
view.
Note:
It's still possible to remove users inside an m2m_avatar_field popover.
Task ID: 3229888
closesodoo/odoo#117194
X-original-commit: f0d71e98743421318a798ef9d4f1e75d11a23334
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Currently, the property fields of type integer and decimal does not
behave like the standard fields. There are the following issues:
1. The property fields of type integer and decimal do not fallback to
the value 0 or 0.0 when the field is emptied.
2. The user can not write the value 0 in the property field of type
integer and decimal. The value gets discarded whenever the user
unfocuses the input field.
This commit will fix those two issues and ensure that the property
fields have the same behavior as the standard fields.
task-3226202
closesodoo/odoo#117253
X-original-commit: 08c317743ba90802f471058a8f12d7211f9eb150
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds a new service "overlay" that will be used as a base
for other service which displays a component on foreground like
"popover" or "dialog". The services "popover", "dialog" and "effect"
already uses this new service to have a common container.
The "overlay" service also fix a stacking context issue that could
happen when a popover opened a dialog and this dialog then opened
another popover thanks to the common container.
task id: 3233266
closesodoo/odoo#115308
Related: odoo/enterprise#38786
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, in the form view dialog of an x2m, resequencing an
x2m will cause a crash.
Why:
The basic_relatonal_model passes the wrong view type to the basic_model
when resequencing. In this case, we want to use the form view.
How to reproduce:
- Going into a form view with an editable x2m
- Open a record of the x2m in a form view dialog with an x2m containing
a handle field
- Change the order of the records using the handle field (resequence)
Before this commit:
A crash is displayed
After this commit:
The records have been resequenced correctly.
closesodoo/odoo#117145
X-original-commit: 003e6f27db767cd80758b868c8afbf73b78f1abe
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when the "Create" button of a m2x is clicked and
an error is returned by the server, a form view dialog is opened to
create the record. We want to know if the error is caused by a missing
required field but not by any other type of error.
So we open the form view dialog only if the error is of type
ValidationError otherwise we display an error dialog.
closesodoo/odoo#116954
X-original-commit: 49bae69c602d1587fe159719667ff8dd0fb23984
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a list view, the style of a decoration on a m2o
widget was ignored. For example, when applying the danger decoration,
we want the m2o field to be in red.
How to reproduce:
Go to a list view with a field having the many2one widget and
a danger-decoration.
Have a line that respects the decoration condition.
Before this commit:
m2o field text uses its base colour (blue)
After this commit:
m2o field text uses the colour red for danger decoration
closes odoo/odoo#116621
Forward-port-of: #115831
X-original-commit: 9e0eac2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the notebook tabs were skipped when navigating with
the keyboard tab or shift+tab keyboard shortcuts. This commit simply
modify the tabindex to 0, so they are not ignored.
Users can now move through the tabs with the tab key, and press enter to
activate a specific tab.
Note that there is not tests because that kind of user interaction cannot
be simulated from the js code
closes odoo/odoo#116874
Task: #2622077
X-original-commit: 1a9a4aef728b406b4c3a1c99cb66e3fc4fd4ff52
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since commit 2ecfed335d, m2x_tags_avatar
are based on dynamic.readonly to know if they are readonly or not. This
is a mistake, the only information that depends on dynamic.readonly is
the presence or absence of the popover.
In this commit, we'll set the initial value to readonly and add the
isEditable props that will tell iif you can delete or add records with
the popover.
closesodoo/odoo#116782
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The web client has a mechanism to invalidate the action and the view
cache: in the basic model (and the relationalmodel), some code is
looking for updates to some specific models (such as ir.actions) and
trigger a `CLEAR-CACHE` event. This event is then listened by the action
and view services to properly clear the caches. This mechanism was also
used to reload the page after editing a company, or reloading the
currencies after editing some currency.
With this commit, we modify the orm service to trigger an event after
each rpc. This event can then be used by the action/view service, and
also by the currency/company services to perform their specific cleanup.
This work is one step in the future refactoring of the relational model.
closesodoo/odoo#115655
Related: odoo/enterprise#38814
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce
==================
- Go to a form view with a binary field, or add one with studio
- Upload a file a.txt to a record
- Upload a file b.txt to another record
- Switch between both records with the pager
- The filename is not updated
opw-3208810
closesodoo/odoo#116323
X-original-commit: 90515916e8adb3edb560d73ec8889ad52319cc1d
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In tests, if we need to interact with dropdowns, we should patch setTimout so that we don't have to wait x ms for the dropdown to open.
closesodoo/odoo#116319
X-original-commit: 008d4faebabbecb88d4ce514650b59cdc21ff85a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the use of multiple <field> with the same name in a
view was not well supported.
Why was this?
Some Field components need to know information related to the <field>
such as context, domain, required and readonly. The solution used before
this commit to access this information is to use the getFieldContext,
getFieldDomain, isReadonly, isRequired functions of the model.
Unfortunately, these only take into account the last occurrence of the
<field> because the model is not aware that the same field is present
several times on the view. The information must therefore not come from
the model. For example, it was not possible to have the same field
twice with 2 different domains. It will use the domain of the last
field for both.
Solution:
We will add the object "dynamicInfo" to the fieldInfo passed to the Fields
extractProps function. This object will contain a getter to get the value
of required, readonly, domain and context for the current <field>.
If a Field needs one of its information, it will just have to get it
from extractProps.
Part of Task: 3179751
closesodoo/odoo#115197
Related: odoo/enterprise#38151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
Allow to use the following domain in views
```
[('properties', '=', [])]
```
To be able to show / hide elements based on the fact that the
properties is empty or not.
Task-3213639
closesodoo/odoo#115990
X-original-commit: 4c41108df23a1bbce8c5f6918ead80568a72d4ce
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Before this commit, when over a man2one avatar, on a task project for
instance, we don't have any information about the user.
Now, a tooltip with the name is shown, note that this was already the
behavior in previous versions.
task-id = 3148168
closesodoo/odoo#115865
X-original-commit: c361cff78ddb2ad6b1f1c1d80c71a3ab154c6789
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**TO REPRODUCE**
- open contacts
- open a contact with a picture (for ex, douglas fletcher)
- change the picture => new picture is displayed
- click on cloud icon to force save => new picture is displayed
- repeat: After repeating, the old picture will be displayed.
**SOLUTION**
Before this change, `getUrl` is bound to the rendering context
instead of the component and it will write to the rendering context.
This is introduced in this commit: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6
The following excerpt from the mentioned commit explains:
"A side-effect of this change is that now the rendering context is no
longer the instance of the component by default, but is always an object
with the component in its prototype chain."
To make sure that `getUrl` is properly bound to the component,
we should call it from the `this` of the rendering context.
closesodoo/odoo#115857
Task-id: 3204546
X-original-commit: 05898cdaaf2dbf628665f3fa4c24769f7c424efe
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit deactivates the daterangepicker from reacting to the
`input` keyup events.
The handler for input keyup must only be the parent because
daterangepicker does not have access to both the start and end date
inputs.
As a consequence of not having access to both inputs, the
daterangepicker always sets the end date to the start date when a date
input is modified.
**Steps to reproduce:**
- Go to the event app and open a record
- Click on an input of the date range picker, and the picker opens
- Move the cursor in the input with the keyboard (right or left arrow)
- The picker loses the range
**Current behavior:**
The picker sets the end date to the start date whenever there is an
onKeyup event on the input.
**Expected behavior:**
The picker should not reset the end date when there is an onKeyup
event on the input.
closesodoo/odoo#115834
Ticket-id: 3198864
X-original-commit: 2a1857db4bee43ff266b4be279791c9b5c957085
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit avoids to update the related daterange field (aka. end date
when changing start date, and vice-versa) when this field is not present
in the DOM (could be 'invisible' field or hidden column in list).
Steps to reproduce:
- Open Field Service
- Switch to list view
- hide the End date column
- select record(s) to enter multi edit mode
- click on the Start date of the selected record to open the date range
picker
- select a new range
- click Apply
==> Error saying that cannot read setStartDate from undefined
task-3200845
closesodoo/odoo#115766
X-original-commit: 9e00bd26ac43bfdaacd74de324ead84e4154a912
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when a record had a very long
display name, the name could be cut in the middle of a
word in the many2one's dropdown.
Now, these names are truncated and have ellipsis to tell
the text continues.
task id: 3234714
closesodoo/odoo#115712
X-original-commit: ed9f9098e3b85c8c739ed7fa5ff6b28bfa2e3584
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Move the kanban gauge field from web_kanban_gauge to web.
Also delete the web_kanban_gauge module and remove all its references.
opw-3231911
closesodoo/odoo#115293
Related: odoo/upgrade#4437
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit [1] recently restricted the context sent to read records
and related records (m2o, x2m) in form views (see commit message
for details). It restricted the context in too many cases though.
For instance, open an existing record (or create a new one) with
an x2many, and add a line in that x2many. If there is an inner
x2many inside, and there're records in that inner x2many by
default, the context sent to read those records does not need to
be restricted, as this is not part of the (initial) read of the
whole form view.
To reproduce the issue, create a new invoice, add a line: the
default tax's name isn't correct ("15% (Sales)" instead of "15%").
[1] fa11f330b8closesodoo/odoo#115552
X-original-commit: 81c619113fed0b70c2bb69e016b18e1f93ce5983
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since c857473 the Kanban arch parser do not take into account the root
node class attribute anymore.
This lead to an issue regarding the x2many fields making use of kanban
views.
This commit brings the following changes:
- the kanban and list arch parsers now share the class attribute in
their arch infos.
- the x2many field adds the className from arch infos to its root node.
closesodoo/odoo#115534
X-original-commit: 980244fa8bf2b720527e457f22c4039c450eed5b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before 16.0 and the "always edit" form views, some fields allowed to
be edited in readonly (e.g. the statusbar in crm lead or project
task). Users could thus change the stage of a record in readonly and
the change was saved directly. If the field was tracked, the change
was even logged in the chatter directly. Since the form view is always
in edition now, we loose that behavior and the user must click on the
save cloud icon to manually save and see the tracking messages. To
mitigate this, those fields that were editable in readonly could save
the record directly when edited, like buttons do.
Changing the values of the following fields should automatically save
the record.
- BooleanToggleField
- PriorityField
- StateSelectionField
- StatusBarField
To accomplish this, we now unconditionally save the record when the above
mentioned fields are changed.
closesodoo/odoo#115500
Task-id: 3175672
X-original-commit: c9b7c43c69eaf87e7900801b926d3868adc36d8c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Purpose:
Allow quick assignation of records in the kanban views (and other places
by extension).
Currently, if you want to work in a board-like env (e.g. tasks in
kanban, crm in pipeline, that kind of thing), having the possibility to
quickly assign/unassign records without having to open them fullscreen
can be really useful => it should be possible to "quick edit" these
fields in kanban views easily, without switching to form views.
If you want to keep the field readonly don't forget to add the readonly
attribute.
Task-id: 3121207
Part-of: odoo/odoo#114400
Purpose:
Allow quick assignation of records in the kanban views (and other places
by extension).
Currently, if you want to work in a board-like env (e.g. tasks in
kanban, crm in pipeline, that kind of thing), having the possibility to
quickly assign/unassign records without having to open them fullscreen
can be really useful => it should be possible to "quick edit" these
fields in kanban views easily, without switching to form views.
If you want to keep the field readonly don't forget to add the readonly
attribute.
Task-id: 3121207
Part-of: odoo/odoo#114400
Before this commit, in x2m fields with a parent record dependent context,
the context used to generate default values for a new record by clicking
on "Save & New" could be wrong. It was not based on the edited values of
the parent record.
How to reproduce:
- Go to a form view with a text field (field_a) and an x2m field with the
context { default_field_b: 'field_a' }.
- Edit the 'field_a'
- Click on "Add a line"
A dialog opens with the edited value of 'field_a' as the value for 'field_b'
- Click on "Save & New"
Before this commit:
A dialog opens with the unedited value of 'field_a' as the value
for 'field_b'
After this commit:
A dialog opens with the edited value of 'field_a' as the value
for 'field_b'
closesodoo/odoo#114460
X-original-commit: b22ef9d2cc4119c8cd6e9c72103279e37f043440
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit 17a24020ac, StateSelectionField
displays its label in all views. This was an error. It should only
display its label in list views.
closesodoo/odoo#114538
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds the possibility to display a properties field in a list
view.
How it works:
When a properties field is present in the arch of a list view, it will
not be displayed directly. It will display its properties as an optional
column. Now, we will find at the end of the dropdown of the optional
columns a section by record parent of the properties field. The proposed
sections will be the properties linked to the parent record of which at
least one record referring to it has been encountered during the
navigation in this list view.
(A parent record is the record storing the properties definition).
Limitation:
Multi-editing is not applicable on properties fields as you cannot edit
one property without modifying all the others.
closesodoo/odoo#112005
Taskid: 3105039
Related: odoo/enterprise#37004
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: mcm-odoo <mcm@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
The aim of this commit is to make more warning and error dialogs behave
like the "oh snap" dialog of form views.
task-id=3126594
closesodoo/odoo#112276
Related: odoo/enterprise#37593
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Pierre Rousseau