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
Previously, when evaluating a button's context from its attributes, we
would evaluate it with the record's data as context, this resulted in
x2many fields being evaluated as a datapoint (in particular, as a
StaticList). When we then went to call doAction with that context, the
action service tries to serialize that context with JSON.stringify,
which crashes as the StaticList contains circular references. This is a
mistake, as contexts and domain that are to be evaluated from a
string/attribute should be evaluated using the record's evalContext, not
its data. This commit fixes that.
closesodoo/odoo#98469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With the conversion of the kanban view, it was no longer possible to
validate the quick-creation of a column using enter while within the
quick-create input, this is because the hotkey service ignores hotkeys
being pressed while within an editable element by default except for the
escape key.
This commit fixes that by configuring the enter hotkey that
is registered to bypass the editable protection, and also restricts this
hotkey to only be active while focused inside the input.
closesodoo/odoo#98535
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Previously, when registering a hotkey without an area then a hotkey with
area, there would be a crash, as that latest hotkey is the candidate
winner, and we then check that there is no other matching hotkey with an
area that's more specific. In doing this, we assume all other candidates
have an area and call it as a function, but since some hotkey
registrations don't have one, we get a crash.
This commit fixes that by filtering the candidates to only those which
have an area before trying to narrow down to the most specific one.
Part-of: odoo/odoo#98535
Before this commit, when creating a record containing an invisible
x2many, the fields related to this x2many were not asked during the
creation onchange.
Problem:
Some required values were missing when igniting a new record.
Cause:
The arch related to an invisible x2many was ignored.
closesodoo/odoo#98086
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
# Issue
A Dropdown is not closed when a child ViewButton is clicked.
# Solution
Make the ViewButton close the Dropdown.
# Note
Usually, a dropdown is closed by a DropdownItem component.
This is not the case here, because the clicks on view buttons are stopped
(see the view button template). Letting them bubble would close their
eventual parent dropdown, but it brings other issues (e.g. for a view button
in a list renderer's group row, or view buttons that could get interpreted
as action links under some conditions <a type="action" .../>).
Instead of looking in the env to close the parent dropdown if any,
an alternative solution would be to extend the ViewButton component,
wrap it in a DropdownItem component, and reroute its `onClick` handler
to the DropdownItem's `onSelected` prop.
But this requires some preparation at the form compiler level
(when compiling the status bar buttons), which we thought was overengineering
at the time of writing.
closesodoo/odoo#98399
Signed-off-by: Samuel Degueldre <sad@odoo.com>
*: hr_org_chart,l10n_gcc_invoice_stock_account,mail,point_of_sale,
purchase,website,website_sale,website_sale_autocomplete,
website_slides_survey
Some commit have added old Bootstrap 4 classes after the merge of
Bootstrap 5.
Note that it's not possible anymore as the merge bot is now able to
detect it.
closesodoo/odoo#98349
Related: odoo/enterprise#30551
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
In legacy, when you have a label with a string attribute that is empty,
that label is rendered as empty. In the new form view, when the string
attribute was empty we would fall back to the default label for that
field, which is incorrect.
This commit fixes that by not rendering labels that have an empty string
at all.
closesodoo/odoo#98237
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, the state selection field was positioned
on the left of the sheet, just above the title. Now, it is
positioned on the right of sheet.
This commit also fixes the text displayed by this field by
using the value of the fields (normal;blocked;done)_legend.
Finally, this commit removes the last uses of the deprecated
field `kanban_state_selection`.
closesodoo/odoo#97765
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit completes the style of the tags of m2m_tags field.
Tags did not have correct colors and had border.
The commit also fixes the m2m_tags_avatar field for the same reason
as well as a traceback when clicking on the remove tag button.
closesodoo/odoo#96654
Related: odoo/enterprise#30012
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
# Before this commit
Serializing a date would apply the TZ offset of
the luxon's DateTime object in which it is contained.
This sometimes led to output the wrong date.
# After this commit
Serializing a date contained in a luxon's DateTime object
will not apply any TZ offset and will output a serialized version as-is.
# Note
If you still want to apply the TZ offset, you should do it manually:
const toSerialize = date.setZone("utc");
const value = serializeDateTime(toSerialize);
closesodoo/odoo#98194
Related: odoo/enterprise#30469
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
There were 2 problems before this commit:
1. When switching view and coming back from the breadcrumbs: the
previous view props (such as the pager props) were lost;
2. When paging to the next record, switching view and coming back from
the breadcrumb, the view was reverted to the first selected record,
effectively ignoring the paging step.
This commit fixes both of these issues by keeping the controller's
props during a "restore" action, and by also updating the current
controller's props when using the pager.
closesodoo/odoo#97395
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit fixes the style of the field broken
since the introduction of the "display: contents"
rule in css.
closesodoo/odoo#97906
Related: odoo/enterprise#30073
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Steps:
- Go to Employees/Reporting/skills
The first group has a Level Progress of `0.84444` which is not a valid
percentage, it should be `84.44%`
This fix calls the correct format function to display correctly the
aggregate values depending on their widget or type instead of just
displaying the raw aggregate value.
(https://pad.odoo.com/p/wowl_views:
[GMF] Employee : Skills report, group sum should be % https://tinyurl.com/262ec37z)
closesodoo/odoo#98207
Signed-off-by: FrancoisGe <fge@odoo.com>
Inside a res.config.settings form view have a label with a string on it placed
before the field it is linked to.
i.e.:
```
<label for="myField" string="myString" />
<field name="myField" />
````
Before this commit, the string was not taken into account to build the HTML label.
After this commit, it is.
closesodoo/odoo#98109
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit fixes the recently converted color_picker field
widget. It is now always opened in a list as in legacy,
no longer togglable and many style issues have been fixed.
In form views, we still toggle the opened state because
always edit is coming and it would bloat the UI to
keep it always open.
Tests has been added/modified to assert those desired
behaviors.
closesodoo/odoo#97872
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Have a domain declared somewhere in the XML as:
`("&", ("field", "=", "value"), ("field2", "=", "value2"))`
Before this commit, that expression made the Domain algorithm crash, because tuples
were not allowed.
After this commit, only tuples containing at least one other tuple and some optional strings are accepted.
closesodoo/odoo#97850
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
*: mail, web.
The pyEnv used during tests is based on the mock server to provide
server like api. This issue is that when creating multiple environments
during tests, a new mock server is created each time. This is not realistic
since in a real world scenario, multiple tabs would share a single server.
In order to make pyEnv work with multiple tabs tests (e.g. multiple env tests),
let's create a single mock server shared between js environment during a test.
task-2053917
Part-of: odoo/odoo#97975
Pass the options: `{'create': False}` to the a many2many_tags field in some arch
Before this commit, there was a crash because the API of the field's props did not
account for that use case.
After this commit, it does.
closesodoo/odoo#98050
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, in a form view in edition, if you clicked a toggle
boolean in an X2many, the view was saved. A toggle boolean should not do
a save if the main view is in edit mode.
The solution is to save the record only if the view's root datapoint
is in edition.
How to reproduce:
- Go to a form view in edit mode with an X2many that contains a toggle
boolean field.
- Click on the toggle boolean in the x2many
Result before:
The view is saved.
Result after:
The view is not saved and is still in edit mode.
closesodoo/odoo#97673
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Denis Ledoux