[IMP] Re-write README

This commit is contained in:
Clément Mombereau
2025-01-16 14:35:21 -03:00
parent 623676d784
commit 0ed04587eb
6 changed files with 89 additions and 175 deletions

View File

@@ -28,58 +28,39 @@ Group backend
|badge1| |badge2| |badge3| |badge4| |badge5| |badge1| |badge2| |badge3| |badge4| |badge5|
This module was written to extend the standard functionality regarding users 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.
and groups management by adding a new `Backend user` group that only gives access
to odoo backend (`/web`):
* minimal default access: 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.
* 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` is when you want to gives access to the The UI access is provided only for ``group_backend_ui_users`` :
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.
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: 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).
* 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.
.. figure:: https://raw.githubusercontent.com/OCA/server-backend/16.0/base_group_backend/static/description/dummy_app.png .. figure:: https://raw.githubusercontent.com/OCA/server-backend/16.0/base_group_backend/static/description/dummy_app.png
:alt: Dummy app for demo :alt: Dummy app for demo
We suggest to use this module with its companion ``base_user_role``.
Limitations Limitations
~~~~~~~~~~~ ~~~~~~~~~~~
At the time of writing, Odoo uses `res.users.share == False` to give the 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``.
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.
This avoids to write a lot of overwrite in different controllers from So technically, the module does 2 things :
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.
.. warning:: * 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``
Using this module and grant a user with `group_backend`'s group is
equivalent to grant `group_user`'s group everywhere `has_group` 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.
has been used.
.. IMPORTANT:: .. IMPORTANT::
This is an alpha version, the data model and design can change at any time without warning. This is an alpha version, the data model and design can change at any time without warning.
@@ -94,37 +75,21 @@ that check if user is part of the `base.group_user` or `share == False` group.
Configuration Configuration
============= =============
To allow `group_backend` to interact with a model you can either add access rules to the group 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.
or you can add `implied_ids` to `group_backend`.
.. note:: 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**.
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.
Usage Usage
===== =====
To use this module, you need to: To use this module, add a user to the group "Backend user" or "Backend UI user" through the user's form page.
#. 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`)
.. figure:: https://raw.githubusercontent.com/OCA/server-backend/16.0/base_group_backend/static/description/backend_ui.png .. figure:: https://raw.githubusercontent.com/OCA/server-backend/16.0/base_group_backend/static/description/backend_ui.png
:alt: Backend UI user :alt: Backend UI user
Known issues / Roadmap 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).
======================
Current module depends on `base_install_request` instead of `base`. 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.
We don't need `base_install_request` auto install module but we must override it to set a security group on `App` menu.
This dependency should be remove if possible in future versions.
Bug Tracker Bug Tracker
=========== ===========

View File

@@ -1,8 +1,3 @@
To allow `group_backend` to interact with a model you can either add access rules to the group 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.
or you can add `implied_ids` to `group_backend`.
.. note:: 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**.
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.

View File

@@ -1,52 +1,33 @@
This module was written to extend the standard functionality regarding users 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.
and groups management by adding a new `Backend user` group that only gives access
to odoo backend (`/web`):
* minimal default access: 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.
* 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` is when you want to gives access to the The UI access is provided only for ``group_backend_ui_users`` :
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.
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: 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).
* 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.
.. figure:: ../static/description/dummy_app.png .. figure:: ../static/description/dummy_app.png
:alt: Dummy app for demo :alt: Dummy app for demo
We suggest to use this module with its companion ``base_user_role``.
Limitations Limitations
~~~~~~~~~~~ ~~~~~~~~~~~
At the time of writing, Odoo uses `res.users.share == False` to give the 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``.
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.
This avoids to write a lot of overwrite in different controllers from So technically, the module does 2 things :
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.
.. warning:: * 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``
Using this module and grant a user with `group_backend`'s group is
equivalent to grant `group_user`'s group everywhere `has_group` 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.
has been used.

View File

@@ -1,5 +0,0 @@
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.
This dependency should be remove if possible in future versions.

View File

@@ -1,10 +1,8 @@
To use this module, you need to: To use this module, add a user to the group "Backend user" or "Backend UI user" through the user's form page.
#. 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`)
.. figure:: ../static/description/backend_ui.png .. figure:: ../static/description/backend_ui.png
:alt: Backend UI user :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.

View File

@@ -370,48 +370,45 @@ ul.auto-toc {
!! source digest: sha256:879007f368a0b75ad5da7f5d3e3d1d6ae386da26d27df7fc4dec1a6865cf0233 !! source digest: sha256:879007f368a0b75ad5da7f5d3e3d1d6ae386da26d27df7fc4dec1a6865cf0233
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
<p><a class="reference external image-reference" href="https://odoo-community.org/page/development-status"><img alt="Alpha" src="https://img.shields.io/badge/maturity-Alpha-red.png" /></a> <a class="reference external image-reference" href="http://www.gnu.org/licenses/lgpl-3.0-standalone.html"><img alt="License: LGPL-3" src="https://img.shields.io/badge/licence-LGPL--3-blue.png" /></a> <a class="reference external image-reference" href="https://github.com/OCA/server-backend/tree/16.0/base_group_backend"><img alt="OCA/server-backend" src="https://img.shields.io/badge/github-OCA%2Fserver--backend-lightgray.png?logo=github" /></a> <a class="reference external image-reference" href="https://translation.odoo-community.org/projects/server-backend-16-0/server-backend-16-0-base_group_backend"><img alt="Translate me on Weblate" src="https://img.shields.io/badge/weblate-Translate%20me-F47D42.png" /></a> <a class="reference external image-reference" href="https://runboat.odoo-community.org/builds?repo=OCA/server-backend&amp;target_branch=16.0"><img alt="Try me on Runboat" src="https://img.shields.io/badge/runboat-Try%20me-875A7B.png" /></a></p> <p><a class="reference external image-reference" href="https://odoo-community.org/page/development-status"><img alt="Alpha" src="https://img.shields.io/badge/maturity-Alpha-red.png" /></a> <a class="reference external image-reference" href="http://www.gnu.org/licenses/lgpl-3.0-standalone.html"><img alt="License: LGPL-3" src="https://img.shields.io/badge/licence-LGPL--3-blue.png" /></a> <a class="reference external image-reference" href="https://github.com/OCA/server-backend/tree/16.0/base_group_backend"><img alt="OCA/server-backend" src="https://img.shields.io/badge/github-OCA%2Fserver--backend-lightgray.png?logo=github" /></a> <a class="reference external image-reference" href="https://translation.odoo-community.org/projects/server-backend-16-0/server-backend-16-0-base_group_backend"><img alt="Translate me on Weblate" src="https://img.shields.io/badge/weblate-Translate%20me-F47D42.png" /></a> <a class="reference external image-reference" href="https://runboat.odoo-community.org/builds?repo=OCA/server-backend&amp;target_branch=16.0"><img alt="Try me on Runboat" src="https://img.shields.io/badge/runboat-Try%20me-875A7B.png" /></a></p>
<p>This module was written to extend the standard functionality regarding users <p>This module adds two “Backend User” groups (<tt class="docutils literal">group_backend</tt> and <tt class="docutils literal">group_backend_ui_users</tt>) with restricted access to odoo backend only (<tt class="docutils literal">/web</tt>), with less and more controlled access than the native “Internal User” group.</p>
and groups management by adding a new <cite>Backend user</cite> group that only gives access <blockquote>
to odoo backend (<cite>/web</cite>):</p> The problem with the “Internal User” group (<tt class="docutils literal">base.group_user</tt>) is that it can be used by any new module added to your project, so you dont control clearly this groups accesses.</blockquote>
<p>The UI access is provided only for <tt class="docutils literal">group_backend_ui_users</tt> :</p>
<ul class="simple"> <ul class="simple">
<li>minimal default access: <li><dl class="first docutils">
* users and partners (this is necessary to access your own data) <dt>minimal default access rules to access the users own data:</dt>
* mail activity, notification and channel <dd><ul class="first last">
* presence</li> <li>users and partners</li>
<li>minimal default menu <li>mail activity, notification and channel</li>
* notification <li>presence</li>
* activities</li>
<li>minimal default access rules</li>
</ul> </ul>
<p>The problem with the <cite>Internal user</cite> is when you want to gives access to the </dd>
backend to a really thin part of your business to some users, its quite hard </dl>
to properly maintain those roles over the project life, a lot of models use </li>
that group (<cite>base.group_user</cite>) by default which makes hard to maintains.</p> <li><dl class="first docutils">
<p>So that helps creating well-defined user groups with more controls.</p> <dt>minimal default menu to restrict the available ones:</dt>
<p>This modules does 3 things: <dd><ul class="first last">
* 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) <li>notification</li>
* It sets the res_users.share to False for group_backend users. This allows those users to access the backend. <li>activities</li>
* It sets the bare minimum permission in the ir.model.access.csv to display the backend</p> </ul>
<p>We suggest to use this module with its compagnon <cite>base_user_role</cite></p> </dd>
<p>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.</p> </dl>
</li>
</ul>
<p>Here is an example where a user from <tt class="docutils literal">group_backend_ui_users</tt> 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).</p>
<div class="figure"> <div class="figure">
<img alt="Dummy app for demo" src="https://raw.githubusercontent.com/OCA/server-backend/16.0/base_group_backend/static/description/dummy_app.png" /> <img alt="Dummy app for demo" src="https://raw.githubusercontent.com/OCA/server-backend/16.0/base_group_backend/static/description/dummy_app.png" />
</div> </div>
<p>We suggest to use this module with its companion <tt class="docutils literal">base_user_role</tt>.</p>
<div class="section" id="limitations"> <div class="section" id="limitations">
<h1>Limitations</h1> <h1>Limitations</h1>
<p>At the time of writing, Odoo uses <cite>res.users.share == False</cite> to give the <p>At the time of writing, Odoo uses <tt class="docutils literal">user.share == False</tt> and <tt class="docutils literal"><span class="pre">user.has_group(&quot;base.group_user&quot;)</span> == True</tt> to give the backend access to <tt class="docutils literal">user</tt>.</p>
backend access. <p>So technically, the module does 2 things :</p>
However to be able to access the backend without any errors some basic rights are necessary. <ul class="simple">
This module change the way <cite>res.users.share</cite> is computed to allow <cite>group_backend users</cite> to use the backend.</p> <li>It sets the <tt class="docutils literal">share</tt> parameter to <tt class="docutils literal">False</tt> for <tt class="docutils literal">group_backend</tt> users.</li>
<p>This avoids to write a lot of overwrite in different controllers from <li>It hijacks the <tt class="docutils literal">has_group</tt> method of res.users by returning <tt class="docutils literal">True</tt> for <tt class="docutils literal">group_backend</tt> users when the requested group is <tt class="docutils literal">base.group_user</tt></li>
different modules (portal, web, base, website) with hard coded statements </ul>
that check if user is part of the <cite>base.group_user</cite> or <cite>share == False</cite> group.</p> <p>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 <tt class="docutils literal">base.group_user</tt> or <tt class="docutils literal">share == False</tt> group.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">Using this module and grant a user with <cite>group_backend</cite>s group is
equivalent to grant <cite>group_user</cite>s group everywhere <cite>has_group</cite>
has been used.</p>
</div>
<div class="admonition important"> <div class="admonition important">
<p class="first admonition-title">Important</p> <p class="first admonition-title">Important</p>
<p class="last">This is an alpha version, the data model and design can change at any time without warning. <p class="last">This is an alpha version, the data model and design can change at any time without warning.
@@ -423,43 +420,26 @@ Only for development or testing purpose, do not use in production.
<ul class="simple"> <ul class="simple">
<li><a class="reference internal" href="#configuration" id="toc-entry-1">Configuration</a></li> <li><a class="reference internal" href="#configuration" id="toc-entry-1">Configuration</a></li>
<li><a class="reference internal" href="#usage" id="toc-entry-2">Usage</a></li> <li><a class="reference internal" href="#usage" id="toc-entry-2">Usage</a></li>
<li><a class="reference internal" href="#known-issues-roadmap" id="toc-entry-3">Known issues / Roadmap</a></li> <li><a class="reference internal" href="#bug-tracker" id="toc-entry-3">Bug Tracker</a></li>
<li><a class="reference internal" href="#bug-tracker" id="toc-entry-4">Bug Tracker</a></li> <li><a class="reference internal" href="#credits" id="toc-entry-4">Credits</a></li>
<li><a class="reference internal" href="#credits" id="toc-entry-5">Credits</a></li>
</ul> </ul>
</div> </div>
<div class="section" id="configuration"> <div class="section" id="configuration">
<h2><a class="toc-backref" href="#toc-entry-1">Configuration</a></h2> <h2><a class="toc-backref" href="#toc-entry-1">Configuration</a></h2>
<p>To allow <cite>group_backend</cite> to interact with a model you can either add access rules to the group <p>To allow a user from the <tt class="docutils literal">group_backend_ui_users</tt> group to interact with a specific model you can either add an access rules to this model for <tt class="docutils literal">group_backend_ui_users</tt> or you can add <tt class="docutils literal">group_backend_ui_users</tt> to the <tt class="docutils literal">implied_ids</tt> of a new specific group.</p>
or you can add <cite>implied_ids</cite> to <cite>group_backend</cite>.</p> <p>The Backend groups are from the “User types” category (<tt class="docutils literal">base.module_category_user_type</tt>), the same category as “Internal User” (<tt class="docutils literal">base.group_user</tt>), “Portal” (<tt class="docutils literal">base.group_portal</tt>) or Public (<tt class="docutils literal">base.group_public</tt>). Be aware that a user can only belongs to <strong>one group of this category</strong>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Be aware users can only belong to one group from the user type category
(<cite>base.module_category_user_type</cite>). So your other groups cant inherit both
internal users and backend users.</p>
</div>
</div> </div>
<div class="section" id="usage"> <div class="section" id="usage">
<h2><a class="toc-backref" href="#toc-entry-2">Usage</a></h2> <h2><a class="toc-backref" href="#toc-entry-2">Usage</a></h2>
<p>To use this module, you need to:</p> <p>To use this module, add a user to the group “Backend user” or “Backend UI user” through the users form page.</p>
<ol class="arabic simple">
<li>Go to Configuration / Users / Users, choose a user and set the user type.</li>
</ol>
<p>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 (<cite>portal</cite>,
<cite>internal users</cite>)</p>
<div class="figure"> <div class="figure">
<img alt="Backend UI user" src="https://raw.githubusercontent.com/OCA/server-backend/16.0/base_group_backend/static/description/backend_ui.png" /> <img alt="Backend UI user" src="https://raw.githubusercontent.com/OCA/server-backend/16.0/base_group_backend/static/description/backend_ui.png" />
</div> </div>
</div> <p>If you created a specific group with <tt class="docutils literal">group_backend</tt> or <tt class="docutils literal">group_backend_ui_users</tt> in its <tt class="docutils literal">implied_ids</tt>, you need to go through the groups form page in order to add the user to this specific group, because it wont be displayed on the users form page (a specific group with its own category is displayed on users form page only if the group inherits the “Internal user” group).</p>
<div class="section" id="known-issues-roadmap"> <p>This module also <strong>restricts the root menus</strong> displayed to Backend users, so be sure to explicitly add your Backend group to all the necessary root menus for these users.</p>
<h2><a class="toc-backref" href="#toc-entry-3">Known issues / Roadmap</a></h2>
<p>Current module depends on <cite>base_install_request</cite> instead of <cite>base</cite>.</p>
<p>We dont need <cite>base_install_request</cite> auto install module but we must override it to set a security group on <cite>App</cite> menu.</p>
<p>This dependency should be remove if possible in future versions.</p>
</div> </div>
<div class="section" id="bug-tracker"> <div class="section" id="bug-tracker">
<h2><a class="toc-backref" href="#toc-entry-4">Bug Tracker</a></h2> <h2><a class="toc-backref" href="#toc-entry-3">Bug Tracker</a></h2>
<p>Bugs are tracked on <a class="reference external" href="https://github.com/OCA/server-backend/issues">GitHub Issues</a>. <p>Bugs are tracked on <a class="reference external" href="https://github.com/OCA/server-backend/issues">GitHub Issues</a>.
In case of trouble, please check there if your issue has already been reported. In case of trouble, please check there if your issue has already been reported.
If you spotted it first, help us to smash it by providing a detailed and welcomed If you spotted it first, help us to smash it by providing a detailed and welcomed
@@ -467,7 +447,7 @@ If you spotted it first, help us to smash it by providing a detailed and welcome
<p>Do not contact contributors directly about support or help with technical issues.</p> <p>Do not contact contributors directly about support or help with technical issues.</p>
</div> </div>
<div class="section" id="credits"> <div class="section" id="credits">
<h2><a class="toc-backref" href="#toc-entry-5">Credits</a></h2> <h2><a class="toc-backref" href="#toc-entry-4">Credits</a></h2>
</div> </div>
</div> </div>
<div class="section" id="authors"> <div class="section" id="authors">