Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[16.0][IMP] base_group_backend: allow read on calendar.event and remove Dashboard menu for backend users #326

Merged
merged 3 commits into from
Jan 20, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 23 additions & 58 deletions base_group_backend/README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -28,58 +28,39 @@ Group backend

|badge1| |badge2| |badge3| |badge4| |badge5|

This module was written to extend the standard functionality regarding users
and groups management by adding a new `Backend user` group that only gives access
to odoo backend (`/web`):
This module adds two "Backend User" groups (``group_backend`` and ``group_backend_ui_users``) with restricted access to odoo backend only (``/web``), with less and more controlled access than the native "Internal User" group.

* minimal default access:
* users and partners (this is necessary to access your own data)
* mail activity, notification and channel
* presence
* minimal default menu
* notification
* activities
* minimal default access rules
The problem with the "Internal User" group (``base.group_user``) is that it can be used by any new module added to your project, so you don't control clearly this group's accesses.

The problem with the `Internal user` is when you want to gives access to the
backend to a really thin part of your business to some users, it's quite hard
to properly maintain those roles over the project life, a lot of models use
that group (`base.group_user`) by default which makes hard to maintains.
The UI access is provided only for ``group_backend_ui_users`` :

So that helps creating well-defined user groups with more controls.
* minimal default access rules to access the user's own data:
* users and partners
* mail activity, notification and channel
* presence
* minimal default menu to restrict the available ones:
* notification
* activities

This modules does 3 things:
* It hijack the has_group method of res.users by returning True for group_backend users when the requested group is group_user (The need for this needs to be investigated)
* It sets the res_users.share to False for group_backend users. This allows those users to access the backend.
* It sets the bare minimum permission in the ir.model.access.csv to display the backend

We suggest to use this module with its compagnon `base_user_role`


Here is an example where a backend ui user can only access and use the dummy app. No other application are available to this user. You may define your own application instead of the dummy one.
Here is an example where a user from ``group_backend_ui_users`` can only access and use the Dummy App. No other application is available to this user (you may define your own application instead of the Dummy one).

.. figure:: https://raw.githubusercontent.com/OCA/server-backend/16.0/base_group_backend/static/description/dummy_app.png
:alt: Dummy app for demo


We suggest to use this module with its companion ``base_user_role``.

Limitations
~~~~~~~~~~~

At the time of writing, Odoo uses `res.users.share == False` to give the
backend access.
However to be able to access the backend without any errors some basic rights are necessary.
This module change the way `res.users.share` is computed to allow `group_backend users` to use the backend.
At the time of writing, Odoo uses ``user.share == False`` and ``user.has_group("base.group_user") == True`` to give the backend access to ``user``.

So technically, the module does 2 things :

This avoids to write a lot of overwrite in different controllers from
different modules ('portal', 'web', 'base', 'website') with hard coded statements
that check if user is part of the `base.group_user` or `share == False` group.
* It sets the ``share`` parameter to ``False`` for ``group_backend`` users.
* It hijacks the ``has_group`` method of res.users by returning ``True`` for ``group_backend`` users when the requested group is ``base.group_user``

.. warning::

Using this module and grant a user with `group_backend`'s group is
equivalent to grant `group_user`'s group everywhere `has_group`
has been used.
This avoids to write a lot of overwrite in different controllers from different modules ('portal', 'web', 'base', 'website') with hard coded statements that check if user is part of the ``base.group_user`` or ``share == False`` group.

.. IMPORTANT::
This is an alpha version, the data model and design can change at any time without warning.
Expand All @@ -94,37 +75,21 @@ that check if user is part of the `base.group_user` or `share == False` group.
Configuration
=============

To allow `group_backend` to interact with a model you can either add access rules to the group
or you can add `implied_ids` to `group_backend`.
To allow a user from the ``group_backend_ui_users`` group to interact with a specific model you can either add an access rules to this model for ``group_backend_ui_users`` or you can add ``group_backend_ui_users`` to the ``implied_ids`` of a new specific group.

.. note::

Be aware users can only belong to one group from the user type category
(`base.module_category_user_type`). So your other groups can't inherit both
internal users and backend users.
The Backend groups are from the "User types" category (``base.module_category_user_type``), the same category as "Internal User" (``base.group_user``), "Portal" (``base.group_portal``) or Public (``base.group_public``). Be aware that a user can only belongs to **one group of this category**.

Usage
=====

To use this module, you need to:

#. Go to Configuration / Users / Users, choose a user and set the user type.

You get a users that is only able to access to the Odoo backend which you
can attach other groups that not implies other kind of users (`portal`,
`internal users`)
To use this module, add a user to the group "Backend user" or "Backend UI user" through the user's form page.

.. figure:: https://raw.githubusercontent.com/OCA/server-backend/16.0/base_group_backend/static/description/backend_ui.png
:alt: Backend UI user

Known issues / Roadmap
======================

Current module depends on `base_install_request` instead of `base`.

We don't need `base_install_request` auto install module but we must override it to set a security group on `App` menu.
If you created a specific group with ``group_backend`` or ``group_backend_ui_users`` in its ``implied_ids``, you need to go through the group's form page in order to add the user to this specific group, because it won't be displayed on the user's form page (a specific group with its own category is displayed on user's form page only if the group inherits the "Internal user" group).

This dependency should be remove if possible in future versions.
This module also **restricts the root menus** displayed to Backend users, so be sure to explicitly add your Backend group to all the necessary root menus for these users.

Bug Tracker
===========
Expand Down
3 changes: 1 addition & 2 deletions base_group_backend/__manifest__.py
Original file line number Diff line number Diff line change
Expand Up @@ -10,8 +10,8 @@
"website": "https://github.com/OCA/server-backend",
"depends": [
"base",
"base_install_request", # weird module, we need to survive with it
"mail",
"calendar",
],
"maintainers": ["FranzPoize", "bealdav"],
"demo": [
Expand All @@ -23,7 +23,6 @@
],
"data": [
"data/res_groups.xml",
"data/ir_ui_menu.xml",
"security/ir.model.access.csv",
],
"installable": True,
Expand Down
8 changes: 0 additions & 8 deletions base_group_backend/data/ir_ui_menu.xml

This file was deleted.

10 changes: 10 additions & 0 deletions base_group_backend/demo/backend_dummy_model.xml
Original file line number Diff line number Diff line change
Expand Up @@ -41,4 +41,14 @@
action="action_dummy_list"
/>

<menuitem id="menu_root_no_group" name="No Group" sequence="100" />
<menuitem
id="menu_dummy_list_no_group"
name="Dummy list No group"
sequence="100"
groups="group_backend_ui_users,base.group_user"
parent="menu_root_no_group"
action="action_dummy_list"
/>

</odoo>
1 change: 1 addition & 0 deletions base_group_backend/models/__init__.py
Original file line number Diff line number Diff line change
@@ -1 +1,2 @@
from . import res_users
from . import ir_ui_menu
22 changes: 22 additions & 0 deletions base_group_backend/models/ir_ui_menu.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# Copyright 2024 Akretion
# License AGPL-3.0 or later (https://www.gnu.org/licenses/agpl).

from odoo import api, models


class IrUiMenu(models.Model):
_inherit = "ir.ui.menu"

@api.model
@api.returns("self")
def get_user_roots(self):
"""Avoid to display root menus with no defined groups_id to Backend UI Users
like 'spreadsheet_dashboard.spreadsheet_dashboard_menu_root'
or 'base.menu_management'.

"""
res = super().get_user_roots()
if self.env.user.has_group("base_group_backend.group_backend_ui_users"):
return res.filtered(lambda m: m.groups_id)
else:
return res
4 changes: 2 additions & 2 deletions base_group_backend/models/res_users.py
Original file line number Diff line number Diff line change
Expand Up @@ -27,9 +27,9 @@ def has_group(self, group_ext_id):
"base_group_backend.base_group_backend"
) or super().has_group("base_group_backend.group_backend_ui_users")
if has_base_group_backend:
_logger.warning(
_logger.debug(
"Forcing has_group to return True"
+ " for group_backend and base_group_backend_ui_users"
+ " for base_group_backend and base_group_backend_ui_users"
)
return has_base_group_backend
return res
Expand Down
9 changes: 2 additions & 7 deletions base_group_backend/readme/CONFIGURE.rst
Original file line number Diff line number Diff line change
@@ -1,8 +1,3 @@
To allow `group_backend` to interact with a model you can either add access rules to the group
or you can add `implied_ids` to `group_backend`.
To allow a user from the ``group_backend_ui_users`` group to interact with a specific model you can either add an access rules to this model for ``group_backend_ui_users`` or you can add ``group_backend_ui_users`` to the ``implied_ids`` of a new specific group.

.. note::

Be aware users can only belong to one group from the user type category
(`base.module_category_user_type`). So your other groups can't inherit both
internal users and backend users.
The Backend groups are from the "User types" category (``base.module_category_user_type``), the same category as "Internal User" (``base.group_user``), "Portal" (``base.group_portal``) or Public (``base.group_public``). Be aware that a user can only belongs to **one group of this category**.
55 changes: 18 additions & 37 deletions base_group_backend/readme/DESCRIPTION.rst
Original file line number Diff line number Diff line change
@@ -1,52 +1,33 @@
This module was written to extend the standard functionality regarding users
and groups management by adding a new `Backend user` group that only gives access
to odoo backend (`/web`):
This module adds two "Backend User" groups (``group_backend`` and ``group_backend_ui_users``) with restricted access to odoo backend only (``/web``), with less and more controlled access than the native "Internal User" group.

* minimal default access:
* users and partners (this is necessary to access your own data)
* mail activity, notification and channel
* presence
* minimal default menu
* notification
* activities
* minimal default access rules
The problem with the "Internal User" group (``base.group_user``) is that it can be used by any new module added to your project, so you don't control clearly this group's accesses.

The problem with the `Internal user` is when you want to gives access to the
backend to a really thin part of your business to some users, it's quite hard
to properly maintain those roles over the project life, a lot of models use
that group (`base.group_user`) by default which makes hard to maintains.
The UI access is provided only for ``group_backend_ui_users`` :

So that helps creating well-defined user groups with more controls.
* minimal default access rules to access the user's own data:
* users and partners
* mail activity, notification and channel
* presence
* minimal default menu to restrict the available ones:
* notification
* activities

This modules does 3 things:
* It hijack the has_group method of res.users by returning True for group_backend users when the requested group is group_user (The need for this needs to be investigated)
* It sets the res_users.share to False for group_backend users. This allows those users to access the backend.
* It sets the bare minimum permission in the ir.model.access.csv to display the backend

We suggest to use this module with its compagnon `base_user_role`


Here is an example where a backend ui user can only access and use the dummy app. No other application are available to this user. You may define your own application instead of the dummy one.
Here is an example where a user from ``group_backend_ui_users`` can only access and use the Dummy App. No other application is available to this user (you may define your own application instead of the Dummy one).

.. figure:: ../static/description/dummy_app.png
:alt: Dummy app for demo


We suggest to use this module with its companion ``base_user_role``.

Limitations
~~~~~~~~~~~

At the time of writing, Odoo uses `res.users.share == False` to give the
backend access.
However to be able to access the backend without any errors some basic rights are necessary.
This module change the way `res.users.share` is computed to allow `group_backend users` to use the backend.
At the time of writing, Odoo uses ``user.share == False`` and ``user.has_group("base.group_user") == True`` to give the backend access to ``user``.

So technically, the module does 2 things :

This avoids to write a lot of overwrite in different controllers from
different modules ('portal', 'web', 'base', 'website') with hard coded statements
that check if user is part of the `base.group_user` or `share == False` group.
* It sets the ``share`` parameter to ``False`` for ``group_backend`` users.
* It hijacks the ``has_group`` method of res.users by returning ``True`` for ``group_backend`` users when the requested group is ``base.group_user``

.. warning::

Using this module and grant a user with `group_backend`'s group is
equivalent to grant `group_user`'s group everywhere `has_group`
has been used.
This avoids to write a lot of overwrite in different controllers from different modules ('portal', 'web', 'base', 'website') with hard coded statements that check if user is part of the ``base.group_user`` or ``share == False`` group.
5 changes: 0 additions & 5 deletions base_group_backend/readme/ROADMAP.rst

This file was deleted.

12 changes: 5 additions & 7 deletions base_group_backend/readme/USAGE.rst
Original file line number Diff line number Diff line change
@@ -1,10 +1,8 @@
To use this module, you need to:

#. Go to Configuration / Users / Users, choose a user and set the user type.

You get a users that is only able to access to the Odoo backend which you
can attach other groups that not implies other kind of users (`portal`,
`internal users`)
To use this module, add a user to the group "Backend user" or "Backend UI user" through the user's form page.

.. figure:: ../static/description/backend_ui.png
:alt: Backend UI user

If you created a specific group with ``group_backend`` or ``group_backend_ui_users`` in its ``implied_ids``, you need to go through the group's form page in order to add the user to this specific group, because it won't be displayed on the user's form page (a specific group with its own category is displayed on user's form page only if the group inherits the "Internal user" group).

This module also **restricts the root menus** displayed to Backend users, so be sure to explicitly add your Backend group to all the necessary root menus for these users.
2 changes: 2 additions & 0 deletions base_group_backend/security/ir.model.access.csv
Original file line number Diff line number Diff line change
Expand Up @@ -31,3 +31,5 @@ backend_ui_users_res_partner_industry,backend_ui_users_res_partner_industry,base
backend_ui_users_res_users_identitycheck,backend_ui_users_res_users_identitycheck,base.model_res_users_identitycheck,group_backend_ui_users,1,1,1,0
backend_ui_users_res_bank,backend_ui_users_res_bank,base.model_res_bank,group_backend_ui_users,1,0,0,0
backend_ui_users_res_partner_bank,backend_ui_users_res_partner_bank,base.model_res_partner_bank,group_backend_ui_users,1,0,0,0
backend_ui_users_res_calendar_event,backend_ui_users_res_calendar_event,calendar.model_calendar_event,group_backend_ui_users,1,0,0,0
backend_ui_users_res_calendar_attendee,backend_ui_users_res_calendar_attendee,calendar.model_calendar_attendee,group_backend_ui_users,1,0,0,0
Loading
Loading