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>

The goal is to get rid of the use of `groups_id` for backend views
to be able to cache the arch of the view more easily.

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

Changing the invisible attributes for the presence icon
is a bit weird:
- when a user logged in, you could see the green ball next to his name,
- but when he checks in in the attendance app, the green ball disapear,
  hidding his presence status.

Maybe in the past, there was a smart button
also showing the presence status,
therefore the information was twice in the form
view, and this is maybe why this change of attributes
was put in place,
but this is no longer the case,
there is no other way to see an employee has signed in or checked in
from the form view once he checked in in the attendance app,
which is weird.
It therefore has been decided to remove this change of attribute
in this inherited view.

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

See the related commit in the enterprise part of this pull request.
Here is the commit message for easyness:

In this case, the renaming of the label to "planned date"
is done directly in the base view,
in the community part of this pull request.

It made no sense to change the label from "Dates" to "Date Planned"
when you became a planning user, for all projects.

Either it should be "Planned date" for everyone,
either it should be "Planned" date only for projects using planning.
But not when the user is granted "Planning / User".

It was decided to make this label by default in the base view

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

The revision achieves the same thing,
grouping the project by stages when the "Project stages" features is
enabled,
without having to require a view for that purpose.

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

This one is a tricky case

The `create` button should not be visible in the tree and form views
of stock locations when the multi locations feature is not enabled.

If you don't have the group, you do not see the menu bringing
you to the locations list, but though it's still possible
to reach the location form view through a many2one link
on a location field missing the `groups="stock.group_stock_multi_locations"`
e.g. on the stock move form.

If you managed to reach a location form whatever the way,
if you do not have the multi locations enabled,
you shouldn't see the create button.

As we would like to remove the `groups_id` feature of the `ir.ui.view`,
we must find an alternative.
This is the only case using `groups_id` to remove the create/edit
button, so it's not like it's such a common way
to achieve this goal.

The right way to achieve this should be an ACL,
preventing you to create a location at all (even through xmlrpc)
if you do not have the multi-location feature enabled.
Though, currently, there is an ACL giving the right to inventory
managers to create locations, and this is unfortunately impossible
in the ACLs model to make a combined group rule, like you need both
the groups multi-locations and inventory manager to be allowed to create
locations.

Hence, as alternative, we enable/disable the view
removing the create button from the list and form views
when the multi-locations is enabled/disabled in the settings.

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

Besides, in this case, overriding `_compute_product_updatable`
is actually what is already done in other modules to achieve the same
goal:

- https://github.com/odoo/odoo/blob/7b56fc4c7197e6dc2d7a46093c9abcb1b851db3a/addons/sale/models/sale_order_line.py#L852
- https://github.com/odoo/odoo/blob/7b56fc4c7197e6dc2d7a46093c9abcb1b851db3a/addons/sale_project/models/sale_order_line.py#L53
- https://github.com/odoo/odoo/blob/7b56fc4c7197e6dc2d7a46093c9abcb1b851db3a/addons/sale_stock/models/sale_order_line.py#L211

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

Part-of: odoo/odoo#98551

The goal being to get rid of the `groups_id` feature for backend views

Part-of: odoo/odoo#98551

Move the `website.group_website_designer` from the view groups_id
to the view architecture,
the goal being to get rid of the `groups_id` feature for backend views.

The use case here is really not clear:
- First, to access the settings, you must be admin,
meaning you always have the group `website.group_website_designer` when
you see the settings, hence it's not really useful to specify the group.
- Second, imagine you could access the settings without being admin,
it wouldn't make sense to let users not having the designer group to
update the terms without the website features, as they would
override the work of the designer who designed the terms using
the website features, with the rich HTML and everything

Part-of: odoo/odoo#98551

Having a back-end view with as group `base.group_user` in its `groups_id`
doesn't make sense since portal users use the frontend
to access their documents.

Part-of: odoo/odoo#98551

Part-of: odoo/odoo#98551

Revision 7fd74226
takes care to prevent employees to modify manually their attendances,
by removing the edit button from the attendance list.

This is only visual, this doesn't actually
prevent users to change their attendances,
for instance through XMLRPC.

Besides, with the group comment:
```xml
    <record id="group_hr_attendance" model="res.groups">
        <field name="name">User</field>
        <field name="category_id" ref="base.module_category_human_resources_attendances"/>
        <field name="comment">The user will gain access to the human resources attendance menu, enabling him to manage his own attendance.</field>
    </record>
```

To me:
- Employees should be able to sign in and sign out only
- Attendance users should be able to modify their own attendances only
- Attendance managers can modify attendances of anybody.

Hence, instead of removing the edit button on the view,
change the ACLs so employees do not have the rights to modify their
attendances at all.

Part-of: odoo/odoo#98551

Part-of: odoo/odoo#98551