In the legacy implementation of FieldMany2ManyTags, we instantiated
a FieldMany2One with the attrs of the many2many field node. As a
consequence, the FieldMany2ManyTags honnored its own options and
all options supported by the FieldMany2One.
In the new implementation, before this commit, we lost the support
of the Many2ManyField's specific options, in particular "no_create"
and "no_create_edit". This commit fixes that issue.
With this commit, the FieldMany2ManyTags also takes into account
the "can_create" attribute that is automatically set to "0" by the
framework if the user hasn't the required access rights.
Note: Many2OneField options is a mess, it would be nice to
refactor and simplify them in the future.
closesodoo/odoo#99283
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the list view crashed when it was grouped if
there was a button column in between two "aggregatable" fields
columns. The reason is that "formatAggragatableValue" makes sense
only on field columns, and it crashes when called on a column of
another type. It was for instance the case in the Stock > Locations
list view.
closesodoo/odoo#99289
Signed-off-by: Georis François (fge) <fge@odoo.com>
Edit a domain in the debug text area of a domain field in debug mode
was possible but the value displayed in the text area was reset to the
value displayed in the part above. For instance, starting with a domain
field value like "[('id', '=', 1)]" then editing it in the text area to
be "[('id', '=', 3)]", the value for the domain field would be correctly
updated but the value displayed in the domain field would be the initial
value "[('id', '=', 1)]". We fix that by making the DomainSelector
component accept an extra prop "debugValue" to be displayed in the debug
area instead of the prop "value" if it is defined.
closesodoo/odoo#99207
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Setting [(1, "=", 1)] as domain in the debug text area would make crash
the DomainSelector component because the sub component ModelFieldSelector
would not accept 1 as a fieldName prop due to its props validation. We
fix that by converting 1 to a string.
Part-of: odoo/odoo#99207
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Before this commit, the required attribute has no effect on the x2many
fields. It will always be valid unless one of its records is invalid.
Problem:
In some cases, we would like to be able to make some x2many fields
required. For example, many2many_tags should be invalid if it contains
no records.
In legacy, if a field is required, then it has the responsibility to
evaluate if its value is valid. To do this, each field contained the
isSet function which returns true if the value is set.
In our new architecture, it is the model that evaluates if the value of
a field is valid based on the field type. It is therefore no longer
possible to customise the evaluation of the validity of a field based
on the FieldComponent.
Solution:
This commit will reintroduce the possibility to customize the evaluation
of the validity of a field based on the FieldComponent.
To do this, we add the possibility to define a static isSet function
on the FieldComponent. If this function is present, it will be used
to evaluate if the field value is set or not.
closesodoo/odoo#98873
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a grouped kanban which display a priority field widget.
Quick create a record.
Click on any priority widget to change the priority.
Before this commit, the model was still considered in edition, preventing any change
in other record. Hence, the priorities did not change (at least, there was no write operation)
when clicked on.
After this commit, this flow works as expected.
closesodoo/odoo#99199
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit standardizes the API of orm service functions by adding
a "kwargs" parameter, s.t. one can always use those functions even
if the target model overrides the corresponding method to add the
support of a given kwargs. Furthermore, to simplify those function
API, and to close the gap between the js and python APIs, we moved
the "context" argument inside the kwargs.
closesodoo/odoo#99018
Related: odoo/enterprise#30830
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit changes the API of the "create" function of the orm
service to better reflect the API of the corresponding method in
models.py, which takes a list of record values in argument.
Before this commit, a call to "create" only allowed to create a
single record.
Part-of: odoo/odoo#99018
Before this commit, the "read" function of the ORM service didn't
allow to pass any kwargs. As a consequence, it wasn't possible to
call the "read" method of a model with "load" kwargs specified.
This commit fixes the issue, and adapts existing calls accordingly.
Part-of: odoo/odoo#99018
Before this commit, when dropping a record on a folded column in a
kanban view, the column would not load its records and display a "load
more" button instead.
Now, dropping a record on a folded column loads it entirely before
unfolding it, displaying its records normally (including the newly
dropped one).
closesodoo/odoo#98922
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When a field in readonly view can be modified, it should write to the
backend immediately. (No changes are stored to be comited later)
For some reason, a bit of code was preventing this if the field was
required and had a falsy value. Furthermore, the code seemed incorrect
or at least misplaced. Removing these lines didn't affect the test.
The fix simply remove this extra check.
There was a condition in the update code for required field in readonly
views that prevented the correct flow to be executed. Since no test are
broken removing this check but it fixes the problem, it is removed.
closesodoo/odoo#98978
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Adds two new props in `form_controller` in order to call a function from
the parent `Component` just after the form view is saved/discarded.
closesodoo/odoo#97314
Related: odoo/enterprise#30045
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if a touchstart event is performed on a row in an
x2many, then a crash is displayed.
We also use this commit to rename the hasSelector props to allowSelector.
allowSelector is true if checkboxes can be present.
How to reproduce:
- go to a form view in mobile mode with an x2many field
- touch a row in the x2many (trigger an event touchstart)
Before this commit:
An error is displayed
After this commit:
Nothing happens.
closesodoo/odoo#98893
Related: odoo/enterprise#30773
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, it was impossible to empty a many2one in a list view.
How to reproduce:
- go into a list view with a many2one
- empty a many2one containing a value
- click outside the line
Before this commit:
The record goes into readonly mode and its many2one returns to
its original value.
After this commit:
The record is saved and its many2one is empty.
closesodoo/odoo#99140
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes the style of the field, which was
pretty broken since the Owl conversion.
It also bring back the tooltip (as in legacy) when
the button is clicked.
The button now only shows the tooltip if the text
has been copied successfully to the clipboard, and
not appear when it is not allowed or not available
in the browser.
Tests have been added to assert those behaviors.
Enterprise PR to adapt a selector in tests:
https://github.com/odoo/enterprise/pull/30832closesodoo/odoo#98340
Related: odoo/enterprise#30832
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds a generic `action="action_some_method"` attribute to
the list view to allow for a custom action when clicking on a (record)
row. This feature mirrors the existing Kanban "action" attribute.
Note that in cases where the action method does not return a valid
action then the default action `act_window_close` will be called
instead (same behavior as the kanban view and buttons in general).
Supports "magic link" part of Task: 2882539
Part-of: odoo/odoo#97109
Purpose
=======
Allow non administrators to use relational properties.
Standard internal users can not read ir.model. Because of that we
created a component that simulate the behavior of a many2one, but
that call custom public method that check which model the user can
access.
Task-2852259
Part-of: odoo/odoo#95184
Purpose
=======
For security reason access on ir.model is not granted to internal suers. Due
to this constraint a component exists in spreadsheet to be able to select
the models for which we have a read access on the records of this model.
This is required for the properties fields feature, hence moving its code
to web.
Some renaming is performed to make it generic. This generates some changes
in other addons, notably some class renaming.el.
Task-2852259
Part-of: odoo/odoo#95184
Purpose
=======
Create a component for the new Properties field. This component instantiates
the right sub-component based on the property type (e.g. a DatePicker for a
DateTime, a Many2XAutocomplete for relational properties, etc).
This component also allow changing the properties definition (default
value, model, property type, etc).
Note that currently it is limited to children properties, assuming definition
is done from children to containers.
Add unit tests to ensure that behavior of the properties component is correct.
Task-2852259
Part-of: odoo/odoo#95184
Before this revision,
it wasn't possible, in the form header,
to organize buttons in nodes.
If you attempted to do so, the buttons were not appearing.
e.g. for the below form
```xml
<form>
<header>
<button name="0"/>
<button name="1"/>
<div id="special_buttons">
<button name="2"/>
<button name="3"/>
</div>
</header>
</form>
```
Before this revision, the buttons 2 and 3 were not appearing.
Adding this possibility can allow simpler inheritage,
for instance by organizing buttons in sections and then
the inherited view can add buttons directly within the right section,
using a selector targetting the section.
It also allows to restrict a button to users having 2 groups.
e.g.
```xml
<button name="action_draft" position="after">
<div groups="sale.group_auto_done_setting">
<button name="action_done" type="object" string="Lock"
states="sale"
help="If the sale is locked, you can not modify it anymore. However, you will still be able to invoice or deliver." groups="sales_team.group_sale_manager"/>
<button name="action_unlock" type="object" string="Unlock"
states="done"
groups="sales_team.group_sale_manager"/>
</div>
</button>
```
If you want to restrict the button `action_done` to users
having both `sale.group_auto_done_setting` and `sales_team.group_sale_manager`,
you cannot put both groups on the same node,
because otherwise it's an OR connection, not an AND.
`groups="sale.group_auto_done_setting,sales_team.group_sale_manager"`
means
"users has `sale.group_auto_done_setting` or `sales_team.group_sale_manager`",
not AND.
So, the only possibility to restrict a button to two groups with an AND
connection is to restrict the button to a group and nest the button
inside a block restricted to the second group.
The above example is an actual example/need from the existing code.
But, as this possibility wasn't there before this revision,
they achieved the goal by using the `groups_id` feature:
```xml
<record id="view_sales_order_auto_done_setting" model="ir.ui.view">
<field name="name">sale.order.form</field>
<field name="model">sale.order</field>
<field name="inherit_id" ref="sale.view_order_form"/>
<field name="groups_id" eval="[(4, ref('sale.group_auto_done_setting'))]"/>
<field name="arch" type="xml">
<button name="action_draft" position="after">
<button name="action_done" type="object" string="Lock"
states="sale"
help="If the sale is locked, you can not modify it anymore. However, you will still be able to invoice or deliver." groups="sales_team.group_sale_manager"/>
<button name="action_unlock" type="object" string="Unlock"
states="done"
groups="sales_team.group_sale_manager"/>
</button>
</field>
</record>
```
So they had to use an inerited view for that purpose only to restrict
the button to two groups. It's a work-around.
It is much simpler to allow to have nested buttons in the header of the
form.
closesodoo/odoo#98551
Related: odoo/enterprise#30643
Related: odoo/upgrade#3812
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The newly converted form view displays the translation alert above the
form renderer, but we want the translation alert to be present below the
status bar when there is one.
This commit fixes that by moving the display from the form controller to
the form renderer.
closesodoo/odoo#98434
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Achraf Ben Azzouz <abz@odoo.com>
Introduce a new Dynamic Placeholder Generator
in mass mailing and SMS creation.
Using a specific character (#) in subject or via the PowerBox in body
we open a field selector popup, which can be use to select
the wanted field and enter a default value. on validation, the dynamic
placeholder will be inserted in the corresponding input/editable.
task-2154624
closesodoo/odoo#71878
Related: odoo/enterprise#30333
Related: odoo/upgrade#3766
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Previous behavior
================
When `editable=bottom`, when we hit tab until the end of the line, the
user starts to create a new record.
But when `editable=top`, when hitting tab multiple until the end of the
line, the user starts to edit the first line that was existing before
instead of creating a new one.
New behavior
============
The behavior is consistent between both cases: the user can always
continue to edit lines one after the other.
The behavior for `editable=bottom` is not changed, but `editable=top`
continues to add lines on top one of each other.
linked to task-2879904
closesodoo/odoo#98603
Signed-off-by: Georis François (fge) <fge@odoo.com>
- Before this commit
Validating an invalid kanban record on quick creation
would leave the quick creation mode.
- After this commit
Validating an invalid kanban record on quick creation
will stay in quick creation mode, indicating which fields are invalid.
closesodoo/odoo#98874
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, clicking on any part of a kanban record would
initiate a drag & drop sequence, this included its dropdown. This caused
2 issues:
- You could start to drag & drop records by dragging their still opened
dropdowns ;
- Said dropdowns would remain open when dragging their parent record.
This commit fixes both of these issues by hiding dropdowns during drag
sequences and preventing drag when clicking inside the dropdowns.
closesodoo/odoo#98791
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
This commit adds a new parameter to the 'useSortable' hook that allows
HTML elements to prevent a drag sequence. This 'ignore' param can be a
string or a function returning a string, that will be a selector
targetting the elements that need to prevent drag & drop sequences.
Part-of: odoo/odoo#98791
This commit fixes behavior issues in the progress bar field:
- the progressbar would not write on a field if it was declared as
'readonly' on the server (it sounds counter-intuitive but this widget
was supposed to write on records unless given the 'readonly' flag in the
field options);
- the "isEditable" prop was incorrectly computed, resulting in the field
not being editable in kanban views when it should be;
- when editing a value in the field, the focus should be automatically
given to the first input.
These issues have been fixed in this commit.
closesodoo/odoo#97411
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit introduces an object parameter to the "useAutofocus" hook,
that has 2 new optional keys:
- "refName": to override the ref "autofocus" (effectively allows to run
the hook multiple times)
- "selectAll": selects the whole value of the input/textarea (instead of
putting the cursor at the end).
Part-of: odoo/odoo#97411
Before this commit, when a many2one's input shows the choice
"No records", the dropdown does not close.
Cause:
When blurring, the many2one will select its first item. In our case,
"No records" is not selectable and it will not close the dropdown.
How to reproduce:
- go to a form view with a many2one field
- insert a non-existent value in the many2one ("No records" is displayed)
- leave the many2one input ("blur" event)
Result before:
The dropdown containing "No records" is still open.
Result after:
The dropdown containing "No records" is closed.
closesodoo/odoo#98799
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
This commit adds the possibility of having a placeholder in a
required SelectionField.
Solution:
We always add a false option with the placeholder but it is "display:none"
if the field is required.
How to reproduce:
- create a new record in a form view with a required selection field
Result before:
The first option of the selection field will be selected
Result after:
The placeholder of the selection field will be selected
When editing the selection field, the selection field does not propose
the placeholder.
closesodoo/odoo#98823
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With the current implementation of the kanban dropdowns, clicking on a
element doesn't drop the dropdown.
Often it's not a problem as the clicked element initiates a new action.
However, on some occasions (like with a color picker), we want it to
close.
Waiting for a kanban card refactoring, we need to find a bit of a hack:
we wrap the content comming from the arch inside a small component that
only listen for clicks and close the parent dropdown.
closesodoo/odoo#98773
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Previously, the colspan of empty lines in list view did not account for
the fact that the column with the delete action is not always present,
resulting in incorrect colspan on empty lines when it is not.
This commit fixes that by accounting for it, and also fixes the size of
the header of that column, which is supposed to be fixed at 32px but
wasn't in some circumstances.
closesodoo/odoo#98711
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, when a label in a form arch had an empty string attribute,
we would not render it at all as it seemed useless. In practice, some
existing form arch rely on empty labels being rendered for layout
reasons, and the corresponding views are now broken.
This commit fixes that by instead rendering an empty label, just as
legacy views used to.
Part-of: odoo/odoo#98711
# Before this commit
When searching more in an autocomplete component,
the input value is emptied before opening the Search More dialog.
# After this commit
The input value keeps its content when the Search More dialog opens.
closesodoo/odoo#98639
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
This commit is to remove the "Create" button in a grouped kanban view
with create="0".
Problem:
In a kanban view with create="0", the "Create" button should never be
displayed.
How to reproduce :
- go to a kanban view with create="0"
- group the view
Result before:
The "Create" button is displayed
Result after:
The "Create" button is not displayed
closesodoo/odoo#98691
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, if we have a reference field with a "model_field" in
X2many in list mode and we modify this record, then the value of the
reference field is set to false.
Cause of the problem:
The reference field assumes that the preloadedData are always available.
How to reproduce :
- Go to an x2many in list mode containing a reference field with a
"model_field" already containing a value
- edit another field than the reference
- click outside the record
Result before :
The record switches to readonly mode and its reference field contains
the value false
Result after:
The record switches to readonly mode and its reference field has not
changed value.
closesodoo/odoo#98630
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose:
Improve performance/reduce server load for the status bar widget when
the underlying field is a m2o.
Before this commit:
The status bar widget does two calls:
- a search_read request to retrieve ids and folds
- a name_get to retrieve names
With this commit:
The name_get can be avoided to save a call by fetching display_name in
the search_read.
This commit removes the name_get call to retrieve the name directly
from search_read.
task-2919535
closesodoo/odoo#98164
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a formView, if you modify an input and use
the keynav (alt+n or alt+p) to change the record, then the modification
is not saved.
How to reproduce?
- go to a form view with a pager containing more than one record
- edit an input
- press alt+n to move to the next record
- press alt+p to go back to the previous record
Result before:
The record has not changed
Result after:
The record has saved the change.
closesodoo/odoo#98602
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- First issue
The format passed to the daterangepicker locale options could have been
wrong as the daterangepicker lib uses moment and we would pass to it
the date(time) format expressed with luxon's format tokens.
Furthermore, there was no need to pass the format to the daterangepicker
library as the DateRangeField component already handles this.
- Second issue
There was also another issue with the DateRangeField component:
When applying the daterangepicker values, the conversion between a
moment object to a luxon DateTime object was wrong because of the format
used to convert the moment object to a string.
- Explanation
The format tokens are different between luxon and moment.
- After this commit
An helper function has been introduced in order to transform a luxon format into a moment format.
The DateRangeField component now properly converts a moment object to
a luxon's DateTime object when applying the daterangepicker selection.
- Additional note
Also, the DatePicker component was locally converting the luxon's
datetime format and thus has been adapted to use the new helper.
closesodoo/odoo#98578
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Before this commit
Using a daterange field with an empty start/end date(time) will result in an unusable field.
The datepickers shown are set with invalid moment.js objects.
- Explanation
A formatted empty value yields an empty string.
Calling `moment("")` results in an invalid moment objet.
- After this commit
When the formatted empty value yields to a falsy value (i.e. an empty string), we call the global moment function without arguments.
Calling `moment()` results in a valid moment object representing the current date and time.
This is what we are looking for, and thus our issue is resolved.
Part-of: odoo/odoo#98578
The purpose of this commit is to enable the "group by" functionality of
many2many in graph views.
Some other views also implement it (e.g. Gannt odoo/enterprise#20192,
List and Kanban odoo/odoo#74985), it is therefore a logical step to also support group
by many2many in graph views.
Previous behavior:
It is possible to select a many2many in the group by but it has no effect in the graph.
Expected behavior with this commit:
It is possible to select a many2many in the group by and it has an impact in the graph.
task-2721035
closesodoo/odoo#98009
Related: odoo/enterprise#30272
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, pick did not work on non-enumerable properties.
For example, getters in a class are non-enumerable properties. It was not
possible to pick the value of a getter in a Class with the pick function.
closesodoo/odoo#97558
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when you want to modify or add a record in a
non-editable x2many, the call to get_views to receive the arch for the
FormViewDialog did not contain a context.
Problem:
The arch of the form view that is received for adding or editing a
record in a non-editable x2many is not evaluated correctly.
Cause:
An empty context is passed to the "get_views" to receive the arch
for the FormViewDialog.
Solution:
We use the context of the StaticList that represents the x2many for
the "get_views".
Part-of: odoo/odoo#97558
This commit adds the possibility to define control action buttons in the
arch of a list view for a x2many. These buttons are action buttons that
will be placed in the same place as the control create ("Add a line").
The goal of this new feature is to offer the possibility to define
buttons that execute actions linked to an x2many.
Here is an example where we define a control create and a control action
button:
<tree>
<control>
<create string="Create" context="{}" />
<button string="Action Button" name="do_something"
class="btn-link" type="object" context="{'parent_id': parent.id}"/>
</control>
<field name="display_name"/>
</tree>
Part-of: odoo/odoo#97558
Before this commit, when a ListViewHeaderButton was clicked, the view
context wasn't sent to the server.
As ListViewHeaderButton shows, the onClickViewButton API is not correct.
It expects a record in params but this is not correct in the case of
ListViewHeaderButton. So we decided not to pass a record but a getParams
callback that allows us to calculate the params when we need them.
Part-of: odoo/odoo#97558
Prior to this commit, `default_period` attribute is taking a single value.
This commit adds the support for comma separated values.
task-2941625
Part-of: odoo/odoo#97321
Aaron Bohy