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
Revision 7fd7422647
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
In the `res.partner` form:
- the field `user_id` is set in base,
and is directly within the base res.partner.form form view,
within the `Sales & Purchase` notebook page
(which is in the base module despite what the tab name could make think)
https://github.com/odoo/odoo/blob/f294079a8946e88f0564dc96bf8a9531958697fe/odoo/addons/base/views/res_partner_views.xml#L343
- the field `team_id` is set in the module `sales_team`, and added
in the res.partner.form form view from this `sales_team` module
https://github.com/odoo/odoo/blob/f294079a8946e88f0564dc96bf8a9531958697fe/addons/sales_team/views/res_partner_views.xml#L9
Therefore, there isn't any obvious reason why the context `default_`
keys for `user_id` and `team_id` are set
only once the `crm` module installed,
neither why it only applies if you are a salesperson
(to the group `sales_team.group_sale_salesman`, sets in the view
`groups_id`).
If we have a look to the commit
f0b7600314
The goal described in the commit description is still achieved
by moving these default context keys in their respective module.
Besides, having a closer look in this commit,
`default_user_id` is directly added in the simplified partner form
within the base module, but is added through the crm module
for the regular form. Which doesn't make really sense.
Part-of: odoo/odoo#98551
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
in v14 `_render()` on `ir.ui.view` returned `str`. In v15 it returns
`Markup` instead. This inadvertently changed the behavior of
`_do_request()`. The rendered view stored in `xml_transaction` is
added to the request as the SOAP body and is supposed to be
escaped. This is done by `html_escape(xml_transaction)` but since
`xml_transaction` is already `Markup` it won't escape. On top of that
concatenating the `soap_header` and `soap_footer` `str`s causes them
to be escaped when they shouldn't be.
This commit changes `xml_transaction` to be a single `Markup()` that
inserts the escaped view and password inside of
`<mer:CreditTransaction>`. This has the added benefit of solving an
issue when the password includes a character with a special meaning,
although I'm not aware of a real case where this happened.
opw-2919085
closesodoo/odoo#98759
X-original-commit: 8e51b1df76f35a7c01e5f86920c84b2c1c976d9b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
The bus test "display reconnect notification" sometimes fails because
the notification is removed before the assertion occurs. Let's block
the start method of the worker to block the reconnection until the
assertion is made.
closesodoo/odoo#99160
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This PR adds the 'posted' filter by default on the journal items list
view, when coming from an account's form view.
opw-2896728
closesodoo/odoo#99012
X-original-commit: c976a0920dd8d7910c7635cc1e2bbff47edcafa9
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
This commit converts the old "slide_category_one2many" field to the new
WOWL field API.
Part-of: odoo/odoo#97984
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Several modules need to display records data in a list table in a way
suitable to possibly different record types. Here we refactor the list
renderer to allows to specify columns (and their colspans) record by
record.
Part-of: odoo/odoo#97984
Several modules need to modify some parts of the templates used by the
list renderer. Those being called recursively (and with parameters
sometimes), it is quite lengthy to do. Now the call to templates are done
dynamically so that it is easier to extend the templates by specifying
some static keys of the ListRenderer.
Part-of: odoo/odoo#97984
The aim of this commit is to provide better API points to be able
to extend the behavior of the X2ManyField in conjunction with the
ListRenderer. More precisely, we make possible to specify record by
record if it should be edited/created inline or in a dialog.
Part-of: odoo/odoo#97984
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, X2Many renderers were not easily accessible from the outside,
making it difficult to override them in some extension.
After this commit, the renderers are accessible in the object `components` on the constructor.
Part-of: odoo/odoo#97984
Tiffany Chang (tic)