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
While refactoring the move_line_list_views.js in owl, we provided the
account.move id and model + "generate" a thread in the front-end for
account.move.line instead of only providing account.move.line model and id.
This allows us to get rid of this hacky special case
Task-id: 2857743
Part-of: odoo/odoo#96672
Denis Ledoux