closes odoo/odoo#99143

X-original-commit: c13b66da
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Before this commit, folding chat window in public livechat
was not working.

This is because the title of chat window was 0px of height,
so it was impossible to click on it.

This commit fixes the issue by letting title take as much vertical
area as it is available in the header, so that the header
except buttons is clickable to fold the chat window.

Task-2964331

closes odoo/odoo#99024

Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

closes odoo/odoo#99021

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Migrate lunch to Owl.

task-2916338

Part-of: odoo/odoo#99021

Steps to reproduce:
- Create a sale order with a product that's invoiced on delivered
  quantities.
- Set delivered quantity (partial delivery) and create an invoice based
  on the delivered quantity. Set the  "Invoice Date" to sometime in the
  past.
- Go to the settings and set  "Invoicing Switch Threshold" to any date
  in the future (so that the invoice you created has a date BEFORE the
  new threshold)
- The invoice will get the label "invoicing app legacy".
- Go back to the sales order and change the delivered quantity.
You should see that the invoiced quantity is automatically set to 0.
A similar behavior can be observed with purchase orders.

Why this is happening:
When a new “Invoicing Switch Threshold”  is set, all posted invoices
before the threshold are marked as `canceled`. In v15, changing the
delivered quantities  triggers the invoiced quantities to be
recalculated as well. However, computing invoiced quantities doesn't
take into account  invoices that are marked as `canceled`. This mean
that the newly computed invoiced quantities won't include invoices
posted before threshold.

opw-2896797

closes odoo/odoo#98909

X-original-commit: cc979734bd7ef3f2a94b411cb7b4f3e782b7ddab
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@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.

closes odoo/odoo#98893

Related: odoo/enterprise#30773
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

This commit adds a new option for picture zoom on product pages.
The designer may now select a attachment viewer like carousel upon
clicking on images in the view.
The hover zoom has also been fixed as it was broken due to the bootstrap
5 changes.
The designer may choose between zoom on hover, on click, both or no
zoom.

TaskId-2922062

closes odoo/odoo#98305

Related: odoo/upgrade#3785
Signed-off-by: William Braeckman (wbr) <wbr@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.

closes odoo/odoo#99140

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

*: website_livechat

This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.

Task-2965839

closes odoo/odoo#99137

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

By observing the slowest queries in our servers, we find some indexes
to add (and verify the pertinence of each) :
- Add a index on `sale_id` of `stock_picking` because, it has a one2many inverse highly used.
- Add a index on `product_id` of `purchase_order_line` because, it has a one2many inverse in purchase_stock and there are some search with it (in `_compute_purchased_product_qty`).
- Add a index on `product_id` of `sale_order_line` to improve the `sale.report` view and it is also called by `_compute_sales_count`.
- Add a index `btree_not_null` on `created_purchase_line_id` of `stock.move` because its one2many inverse `move_dest_ids` is highly used.
- `key` on `ir_ui_view`: Backport of https://github.com/odoo/odoo/pull/97478



closes odoo/odoo#99130

X-original-commit: da55c8d88b846d9d1841712b6bd96799e2768a5b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>

Steps to reproduce:

  - Install `website_event` module
  - Go to Events and edit `Design Fair Los Angeles` event
  - Edit the title and make it very long then save
  - Go to the Website then click on Events in the menu
  - Click on Customize and disable `Layout - Columns` to have
    a list view.

Issue:

  The cover is hidden on edited event.

Cause:

  It's a know issue:
  https://stackoverflow.com/questions/36247140/why-dont-flex-items-shrink-past-content-size



Solution:

  Set min-width: 0 to the div arround the title if screen size bigger
  then `sm`.

opw-2882533

closes odoo/odoo#99078

X-original-commit: f9068079
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

Before this commit, when saving a page website would fail (for a
validation error, for example), the "Save" and "Discard" buttons of the
SnippetsMenu were not re-enabled, and the edition was lost.

This was visible following this flow:
- Go on a job form view,
- Duplicate it,
- Go to its website page,
- Edit the title to remove "(copy)",
- Click on save,
=> There is a validation error (there cannot be two jobs with the same
title), the page was not saved and the user cannot access the
"Save" and "Discard" buttons to continue the edition anymore.

To fix that, the "after" callback of the SnippetsMenu _buttonClicked
method (which will re-enable the buttons) is added after or as the
onFailure callback of the "request_save" event.

Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b



task-2687506

closes odoo/odoo#98352

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

[1] added a way to detect a replayed action, and returns early the
effect that parses the action's params to ignore them.

This implementation is an error, as the return value of the effect was
not consistent: for a replayed action, it was not returning the cleanup
function that resets the pageDocument, websiteRootInstance and
currentwebsiteId.

This was leading to such behaviour, with enterprise modules:
- Go to the website,
- Click on the top left 'home' button,
- Click on the top left arrow to replay the action,
- Click on the top left 'home' button again,
=> The website systray is still there.

To fix that, the cleanup function is moved to an onWillUnmount hook.

Also, blocking the iframe until its first load event is called in an
onMounted hook, as it is the same as using a useEffect hook with no
dependency and no cleanup function, but it is clearer.

[1]: https://github.com/odoo/odoo/commit/83501e38a338cabd5a064dd0db9f70df08a3aadc

Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b

task-2687506

Part-of: odoo/odoo#98352

It was decided with [1] to keep the text selection, if there was one,
when changing a snippet's option.
It was not working for the layout_column option:
- Drop a text snippet,
- Click on the first paragraph (the text is selected),
- Change the number of columns,
=> The text selection is lost.

To add some columns on snippets like the s_text_block which has no rows
and columns, the layout_column option will first wrap its content into a
set of row and column, which will remove the selection.
To fix that, the selection is restored after wrapping the snippet's
content.

The same thing is done when removing all columns from a snippet (and
unwrapping its content).

Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b

[1]: https://github.com/odoo/odoo/commit/e8112e2865ca449c4df9cd6147e9e24c4c6dcd41

task-2687506

Part-of: odoo/odoo#98352

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/30832



closes odoo/odoo#98340

Related: odoo/enterprise#30832
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

This commit converts the purchase dashboard to owl component
and removes its legacy code.

closes odoo/odoo#97590

Taskid: 2920812
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

The move line form view is too technical for the average user so instead we
can to auto-magically open the reference document instead (picking or MO
only for now).

We do the same with stock valuation layers as well, but this feature
will not be available until its custom JS is converted to OWL

"product moves" part of b2b task: 2882539

closes odoo/odoo#97109

Related: odoo/enterprise#29974
Related: odoo/upgrade#3819
Signed-off-by: Arnold Moyaux (arm) <arm@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

Adds a new reporting view for [storable] product.product to allow for
easier analysis by product (rather than by quant which is location
specific).

This includes:
- adding 3 new fields for products:
  - avg_cost = total svl value / total qty
  - total_value = avg_cost / on hand
  - company_currency_id = self.env.company.currency_id (i.e. the
    currently selected company) for which currency symbol to display in
    the view
  - IMPORTANT NOTE:
    - these variables (and some of the existing ones) do NOT support
      multi-company aggregations due these values being used to calcuate
      future svls which should be company specific. Larger refactoring
      would be needed to ensure correct calc in both cases. Larger issue
      occurs in stock.report which uses these variables in combination
      with variables that do take into account multi-company records.
- A customized `SearchPanel` so that a warehouse context can be applied
  to the view, rather than a filter. (viewable only when more than 1
  warehouse)

"stock report" part of b2b task: 2882539

Part-of: odoo/odoo#97109

Minor UX updates in purchase and stock:

Reworded (in stock):
- Default name location "Partner Locations" => "Partners"
- Default result for "Apply All" wizard "Inventory Adjustment" =>
  "Quantity Updated"
- Individual "Apply" move reference/name updated for individual quants
  (i.e. "Quantity Updated / Confirmed") so that the scheduled date is
  no longer included

Removed (from purchase):
- Duplicated menuitems, i.e.  "Purchase > Reporting > Purchase" showed
  the same thing as Enterprise menuitem and both were being displayed in
  Enterprise version. Also updated the no records found help message
  since old message appeared to be slightly out of date.

ENT PR: odoo/enterprise#29974
"other" part of b2b task: 2882539

Part-of: odoo/odoo#97109

Minor UX updates to forecast report:

- add missing space (between # and unit + before |) also removed
  superfluous uoms (only need it at the end now that an equation is
  displayed)
- move On Hand Value to under product link (+ variants if they exist)
  and make it a link to the valuation report of the product(s) in
  question
- add link from Quantity on Hand to the locations (i.e. inventory/quants)
  report for the relevant product(s). Note that product template was
  added to Search in order to support default searching due to
  forecasting report structure
- redo the top right forecast values to be On Hand + Incoming - Outgoing
  = Forecasted so we provide more explicit and transparent values.
  Additionally, these values are made to not display decimal digits if
  all of those digits are 0.  Note that forecasted values in table are
  untouched (i.e. Forecasted Inventory = Forecasted is unchanged and
  Forecasted with Pending still shows in table)

Also did some t-esc => t-out replacement and other small cleanup since
templates were already being edited.

"forecasted report" part of b2b task: 2882539

Part-of: odoo/odoo#97109

Note this is specific to the view shown when clicking on
"Reporting > Valuation", but this uses the same 'stock.quantity.history'
wizard and related custom js as "Configuration > Locations > Current Stock"

Minor UX updates to valuation report:
- don't default groupby product
- add filters incoming and outgoing (same logic as stock.move filters)
- replace "Inventory at Date" with "Valuation at Date" where appropriate
  (but leave location current stock view untouched)
- create separate view for the valuation report so remaining qty/value
  are displayed, but all other svl viewing actions (including the
  "Valuation at Date") will remain showing the original qty/value to
  support deeper analysis
- don't sum unit_cost when groupby is applied in list view since the
  value won't make sense
- add "reference" to svl which is = to stock.move.reference

"valuation" part of b2b task: 2882539

Part-of: odoo/odoo#97109

The purpose is to easily identify useful layers needed in an audit.
This way we could create a filter and only see layers that still have
quantity to deliver

Supports task: 2882539

Part-of: odoo/odoo#97109

Note this includes the view shown when clicking on:
- "History" button in inventory adjustments
- "Product Moves" button in scrap/product forms
- "Reporting" > "Moves History"
At time of this commit being written. Other move line views not changed
since they are specific to inputting data rather than readonly data.

Minor UX updates to stock move lines report:
- rename "Units of Measure" column to "Unit"
- add color to quantity field (green = incoming qty into stock, red =
  outgoing, black = all others [i.e. internal transfers/external
  locations only, etc]
- search filter order updated + src/dest location filters replaced with
  generic filter that checks if either meets condition
- add src/dest package to list view
- add status, lot, and from/to dest to kanban view and replace picking
  with reference so inventory adjustments are visible as well
- order by date desc so most recent ones are first
- always display location src/dest to help understanding of moves

Specific to "History" button in Inventory Adjustments / Reporting >
Locations (i.e. inventory report), moved product_id from domain to
default_search for more user analysis flexibility/ease.

"product moves" part of b2b task: 2882539

Part-of: odoo/odoo#97109

Minor UX updates to stock moves report:

- don't default groupby source location
- order list by date
- rename "Units of Measure" column to "Unit"
- add color to quantity field (green = incoming qty into stock, red =
  outgoing, black = all others [i.e. internal transfers/external
  locations only, etc]
- search filter order updated
- make to location_{dest_}id text-muted when not a physical location
  (i.e. internal/transit)
- display "Quantity" instead of "Demand" for product_uom_qty and show
  sum at bottom of list

"stock moves" part of b2b task: 2882539

Part-of: odoo/odoo#97109

Inventory report has been updated to have:
- better applicability: report renamed to "Locations" and is only
  visible w/Locations, Consignment, or debug mode active
- improved UX: list view rearranged, buttons added, grouping removed,
  sums added to bottom of list
- improved quant "Value": instead of the accounting value, this is now
  the average unit cost (i.e. sum(valuation layer values)/sum(valuation
  layer quantities) per product x on hand qty (of quant).
- single click load for products
- search based on Warehouse option (including storing
  location.warehouse_id to avoid overly complex search function)
- always show "Location" column in this view even if multi-locations is
  not active

"inventory report" part of b2b task: 2882539

Upgrade PR: odoo/upgrade#3819

Part-of: odoo/odoo#97109

The Forecasted Inventory view has become obsolete, therefore we delete
the code associated with this view. Note that the Forecasted Report
still uses the graph view of this view so we leave it. Because the
Forecasted Report still uses this view + stock.warehouse.orderpoint
relies on the report.stock.quantity model, we leave the model as is.

"forecast inventory" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974
Upgrade PR: odoo/upgrade#3819

Part-of: odoo/odoo#97109

- reorder/rename/remove menu contents for "Inventory" and "Reporting",
  including:
 - removed "Forecasted Inventory" menuitem since this view is no longer
   considered useful (code for view to be removed in separate commit)
 - removed "Stock Moves" (moves report) menuitem
 - renamed "Product Move" (move lines report) menuitem => "Moves
   History", this will also be reflected in any "History" buttons that
   open this view from other views.
 - made "Inventory Report" menuitem visible only when applicable (i.e.
   multi-location or consignment is active/debug mpde)
 - made "Run Scheduler" menuitem only available in debug mode (
   main_flow_tour updated to skip scheduler click since general flow is
   expected to still the same/work)

Goal of renaming/ordering of menuitems is to clean them up and make them
more intuitive for users.

- "Run Scheduler" in mrp menus has also been made debug only viewable as
  well to mirror the inventory change.

"menu" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974

Part-of: odoo/odoo#97109

Purpose
=======

Add a new field "Properties" to be able to light customization of workflows
based on a container model. Those properties acts in some ways like Odoo
fields without requiring specific columns e.g. add new properties on tasks
of a specific project.

Usage
=====

Define properties on a container model (e.g. project) with

```
    attributes_definition = fields.PropertiesDefinition('Message Properties')
```

It defines properties available on subrecords: types, default, value, model for
relational properties,...

Use it on subrecords (e.g. task) with

```
    attributes = fields.Properties(
        string='Properties',
        definition='container_id.attributes_definition',
    )
```

Technical
=========

Container | Properties definition
------------------------------
The properties definition is stored on the container, on a JSON field.
This definition contains the type of the properties, the default value,
the model of the many2one,...
```
[
    {
        'name': 'name',
        'string': 'Name',
        'type': 'char',
        'default': 'Default Name',
    }, {
        'name': 'partner_id',
        'string': 'Partner',
        'type': 'many2one',
        'comodel': 'res.partner',
    },
]
```

Child | Properties values
-------------------------
The value is stored on the child, using a Properties field.
```
{
    'name': 'Mitchel',
    'partner_id': 1337,
}
```

When we read this field, we will automatically read the definition on
the container, and merge both JSON into one, so the web client has the
value of each property, and their definition.

```
[
    {
        'name': 'name',
        'string': 'Name',
        'type': 'char',
        'default': 'Default Name',
        'value': 'Mitchel',
    }, {
        'name': 'partner_id',
        'string': 'Partner',
        'type': 'many2one',
        'comodel': 'res.partner',
        'value': 1337,
    },
]
```

Integrity
---------
If we remove a property on the container, we won't update the child value.

Instead, when we read the child properties, we will filter them based
on the container. So the removed properties will be removed the next time
we write on the field.

In the same logic, the many2one existence is checked when we read the
field. There's no foreign key between the integer stored in the JSON
in the SQL row corresponding to the record in database.

Write
-----
We can write on the Properties field with a list of field definition
and value.

Some types are not JSONifiable (like the date, datetime), they are
stored as string in database and parsed when we read the value.

In order to update the container definition by writing on the child,
you need to add the dict key `definition_changed` or
`definition_deleted`. This is because we need to be able to know
if the definition has been changed without doing extra SQL queries.

Access rights
-------------
A user can add a many2one / many2many property to a model only if he
has the access rights to it.

Many2one / Many2many
--------------------

The model choice of a many2one / many2many properties was subject to
changes.

First implementation stored models in both container and subrecords to easily
spot changes and avoid complex queries when fetching records, trying to
synchronize them, ...

As this leads to storing a lot of duplicated content we choose to instead
reset the value on the child if the model has been change. We generate a
new name for the property. So it behaves like if we removed the property
and created a new one.

```
{
    'name': 'Mitchel',
    'partner_id': (1337, 'res.partner'),
}
```

To be able to restore the old value (e.g. if by mistake we changed the
model, and go back to the old model), we store the initial states.

Task-2852259

closes odoo/odoo#95184

Related: odoo/enterprise#29830
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

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

Purpose
=======

Make the onchange work for the properties fields. When changing the
container field, we need to update the properties definition.

Task-2852259

Part-of: odoo/odoo#95184

Purpose
=======

Add a new field "Properties" to be able to light customization of workflows
based on a parent model. Those properties acts in some ways like Odoo fields
without requiring specific columns e.g. add new properties on tasks of a
specific project.

Usage
=====

Define properties on a parent model (e.g. project) with

```
    attributes_definition = fields.PropertiesDefinition('Message Properties')
```

It defines properties available on children: types, default, value, model for
relational properties,...

Use it on children records (e.g. task) with

```
    attributes = fields.Properties(
        string='Properties',
        definition='parent_id.attributes_definition',
    )
```

Technical
=========

Parent | Properties definition
------------------------------
The properties definition is stored on the parent, on a JSON field.
This definition contains the type of the properties, the default value,
the model of the many2one,...
```
[
    {
        'name': 'name',
        'string': 'Name',
        'type': 'char',
        'default': 'Default Name',
    }, {
        'name': 'partner_id',
        'string': 'Partner',
        'type': 'many2one',
        'comodel': 'res.partner',
    },
]
```

Child | Properties values
-------------------------
The value is stored on the child, using a Properties field.
```
{
    'name': 'Mitchel',
    'partner_id': 1337,
}
```

When we read this field, we will automatically read the definition on
the parent, and merge both JSON into one, so the web client has the
value of each property, and their definition.

```
[
    {
        'name': 'name',
        'string': 'Name',
        'type': 'char',
        'default': 'Default Name',
        'value': 'Mitchel',
    }, {
        'name': 'partner_id',
        'string': 'Partner',
        'type': 'many2one',
        'comodel': 'res.partner',
        'value': 1337,
    },
]
```

Integrity
---------
If we remove a property on the parent, we won't update the child value.

Instead, when we read the child properties, we will filter them based
on the parent. So the removed properties will be removed the next time
we write on the field.

In the same logic, the many2one existence is checked when we read the
field. There's no foreign key between the integer stored in the JSON
in the SQL row corresponding to the record in database.

Write
-----
We can write on the Properties field with a list of field definition
+ value.

Some types are not JSONifiable (like the date, datetime), they are
stored as string in database and parsed when we read the value.

In order to update the parent definition by writing on the child,
you need to add the dict key `definition_changed` or
`definition_deleted`. This is because we need to be able to know
if the definition has been changed without doing extra SQL queries.

Access rights
-------------
A user can add a many2one / many2many property to a model only if he
has the access rights to it.

Many2one / Many2many
--------------------

The model choice of a many2one / many2many properties was subject to
changes.

First implementation stored models in both parent and children to easily
spot changes and avoid complex queries when fetching records, trying to
synchronize them, ...

As this leads to storing a lot of duplicated content we choose to instead
reset the value on the child if the model has been change. We generate a
new name for the property. So it behaves like if we removed the property
and created a new one.

To be able to restore the old value (e.g. if by mistake we changed the
model, and go back to the old model), we store the initial states.

Task-2852259

Part-of: odoo/odoo#95184

Removes legacy component js_class `lazy_column_list` as it loads
legacy views.

closes odoo/odoo#98881

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

closes odoo/odoo#98842

X-original-commit: 3b56ebff5e0afdfa10a1660def4d1a51a2487bb6
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

closes odoo/odoo#98693

Related: odoo/enterprise#30666
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

closes odoo/odoo#98562

Related: odoo/enterprise#30639
Signed-off-by: Raphael Collet <rco@odoo.com>

Part-of: odoo/odoo#98562

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.

closes odoo/odoo#98551

Related: odoo/enterprise#30643
Related: odoo/upgrade#3812
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>