This commit adds two props for the `ConfirmationDialog`:
`cancelLabel` and `confirmLabel`.
Both are `String` and optional and the buttons will remain named "Ok"
and "Cancel" by default.
Part-of: odoo/odoo#97314
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>
Several modules need to display records data in a list table in a way
suitable to possibly different record types. Here we refactor the list
renderer to allows to specify columns (and their colspans) record by
record.
Part-of: odoo/odoo#97984
Several modules need to modify some parts of the templates used by the
list renderer. Those being called recursively (and with parameters
sometimes), it is quite lengthy to do. Now the call to templates are done
dynamically so that it is easier to extend the templates by specifying
some static keys of the ListRenderer.
Part-of: odoo/odoo#97984
The aim of this commit is to provide better API points to be able
to extend the behavior of the X2ManyField in conjunction with the
ListRenderer. More precisely, we make possible to specify record by
record if it should be edited/created inline or in a dialog.
Part-of: odoo/odoo#97984
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, X2Many renderers were not easily accessible from the outside,
making it difficult to override them in some extension.
After this commit, the renderers are accessible in the object `components` on the constructor.
Part-of: odoo/odoo#97984
XXL Form View doesn't apply the right max-width (1320px instead of
1140px).
This is due to the precedence of the selector for `.o_xxl_form_view`
since https://github.com/odoo/odoo/pull/96627. Also this code block
applies to both legacy an new FormView instead of only the new one.
This commit fixes it by properly targetting the `.o_form_view` with the
`.o_xxl_form_view` and restores the previous behavior.
closesodoo/odoo#98686
Signed-off-by: Adrien Dieudonné (adr) <adr@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>
This commit moves the form variables from primary_variables.scss to
the FormView folder.
Part of the overall v16 SCSS optimization/restyle, task-2704984
task-2918464
Part-of: odoo/odoo#98101
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>
If datetimepickers were used too soon after page loading, they would use
the wrong format and UI options as the code in charge of initializing
those options was not fully lazy loaded yet.
With this patch, we prevent the tempusdominus lib to consider pickers
that are in a body that is marked by the lazyloader during the lazy
loading of JS files. We could potentially not add the lib attribute
(data-toggle="datetimepicker") on those elements and let the business
code initializing the pickers add it but that would not have been a
stable fix and it may be better this way as this works generically.
opw-2944720
closesodoo/odoo#98917
X-original-commit: 7e012340d3adcd64e829a5dca34173da24d649bc
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
A modal using the 'ADD' and 'SAVE' buttons will have the same keyboard
shortcut for both of these buttons
Steps to reproduce:
1. Install Inventory
2. Go to Inventory > Operations > Transfers and open a transfer with a
contact and in status 'Ready'
3. Click on 'EDIT' and open the contact in the Delivery Address with the
quick edit button
4. Push on 'Alt' key: the 'ADD' and 'SAVE' buttons use the same shortcut
Solution:
Modify the current hotkey used for button 'SAVE'
opw-2954146
closesodoo/odoo#98884
X-original-commit: 0f8d28269f4900e70d7fefbb359580390656cdf7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@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, in a legacy view, clicking on debug menu
"View Metadata" causes a crash.
closesodoo/odoo#98866
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Before this commit
On an empty m2m_tags(_avatar)_field, triggering a keydown event yields to a traceback due to an owl issue.
This will be fixed in owl later.
- After this commit
The 't-on-keydown' attribute on TagsList component has been moved into the tags themselves.
closesodoo/odoo#98840
Signed-off-by: Samuel Degueldre <sad@odoo.com>
- Before this commit
The browser autocompletion feature may conflict with
the AutoComplete component. First, the browser could
display its own autocompletion dropdown over our component's.
Secondly, selecting an item in the browser's autocompletion
dropdown simulates a keydown event with an undefined 'key' property,
leading to display traceback when the AutoComplete component
uses the keydown event (i.e. in getActiveHotkey).
- After this commit
The <input/> of our AutoComplete component now has the following attr
`autocomplete="off"`. This disables the browser's autocompletion feature
for this <input/>.
Part-of: odoo/odoo#98840
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>
Previously, if you updated a legacy field widget in a new view twice in
quick succession, it may be that the first update recrates the widget,
but the second update doesn't wait for that widget to be created by the
previous update, even though the second update may rely on the widget's
$el to be defined, which can result in a crash.
This commit fixes that by making sure the widget has finished starting
before attempting to recreate it with the new params.
closesodoo/odoo#98822
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
With the conversion of the views to owl, we added an extra div around
fields that represents the whole field, and wraps potentially multiple
elements that may be rendered by a field widget. This changes the DOM
structure, and to allow concrete fields to control everything about the
way they are displayed, we decided to use the css rule "display:
contents" for that div. As it turns out, while this does give more
control to the field widget, it breaks a lot of existing css rules, and
also prevents classes that are applied on that div from the arch from
affecting any css property related to layout (such as margin, position
or padding).
Because of that, we decided to revert this change, and set this div's
display property to inline-block (the same as legacy field widgets) and
adapt the few fields where this does not work out of the box, which
fixes many issues.
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>
This commit fixes a visual issue with the input element of field widgets
in editable lists: the inputs were too narrow and offset to the left.
These inputs should now take the whole width of their containing cells.
> Example view: CRM / Configuration / Tags
closesodoo/odoo#98288
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
To compute the correct size of the text field, the vertical
borders are removed and reset after the computation.
The second part was not done correctly and so the
textarea didn't have any border.
closesodoo/odoo#98284
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
This commit removes vertical padding of the dropdown
toggler used in the StateSelection field widget converted
to Owl recently. In a list, it was causing an unexpected
higher row.
closesodoo/odoo#98718
Signed-off-by: Aaron Bohy (aab) <aab@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>
*: bus, calendar, hr_attendance, iap_mail, im_livechat, project, snailmail,
snailmail_account, survey, web, web_editor, website_livechat.
This commit is part of the websocket integration in Odoo.
This bus service now communicates with a shared worker in order to provide
a single websocket connection for multiple tabs. It is designed to
be used as a websocket except that events are slightly different,
re-connection is handled automatically. If the browser does not support shared
worker (Safari), the service fallback on a simple web worker.
Available events are:
- connect : fired upon a successful connection.
- disconnect : fired upon reception of the websocket close event.
The close code and reason are given to the listeners callback.
- reconnect : fired upon a successful re-connection.
- reconnecting : triggered when the worker starts to try reconnecting.
- notification : fired upon the reception of notifications.
Since multiple tabs are now handled by a worker, the cross_tab bus is no longer
required and has been removed.
Part-of: odoo/odoo#75510
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>
svs-odoo