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>
*: 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
closesodoo/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/97478closesodoo/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
closesodoo/odoo#99078
X-original-commit: f9068079bd3535146727f710bc7a3aca863524ab
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
closesodoo/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/30832closesodoo/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.
closesodoo/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
closesodoo/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
closesodoo/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
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 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
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
FrancoisGe