[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
|
|
|
|
.. _reference/security:
|
|
|
|
|
|
|
|
================
|
|
|
|
Security in Odoo
|
|
|
|
================
|
|
|
|
|
|
|
|
Aside from manually managing access using custom code, Odoo provides two main
|
|
|
|
data-driven mechanisms to manage or restrict access to data.
|
|
|
|
|
|
|
|
Both mechanisms are linked to specific users through *groups*: a user belongs
|
|
|
|
to any number of groups, and security mechanisms are associated to groups,
|
2021-05-31 16:33:32 +07:00
|
|
|
thus applying security mechanisms to users.
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
|
|
|
|
.. _reference/security/acl:
|
|
|
|
|
|
|
|
Access Control
|
|
|
|
==============
|
|
|
|
|
|
|
|
Managed by the ``ir.model.access`` records, defines access to a whole model.
|
|
|
|
|
|
|
|
Each access control has a model to which it grants permissions, the
|
|
|
|
permissions it grants and optionally a group.
|
|
|
|
|
|
|
|
Access controls are additive, for a given model a user has access all
|
|
|
|
permissions granted to any of its groups: if the user belongs to one group
|
|
|
|
which allows writing and another which allows deleting, they can both write
|
|
|
|
and delete.
|
|
|
|
|
|
|
|
If no group is specified, the access control applies to all users, otherwise
|
|
|
|
it only applies to the members of the given group.
|
|
|
|
|
|
|
|
Available permissions are creation (``perm_create``), searching and reading
|
|
|
|
(``perm_read``), updating existing records (``perm_write``) and deleting
|
|
|
|
existing records (``perm_unlink``)
|
|
|
|
|
|
|
|
.. _reference/security/rules:
|
|
|
|
|
|
|
|
Record Rules
|
|
|
|
============
|
|
|
|
|
|
|
|
Record rules are conditions that records must satisfy for an operation
|
|
|
|
(create, read, update or delete) to be allowed. It is applied record-by-record
|
|
|
|
after access control has been applied.
|
|
|
|
|
|
|
|
A record rule has:
|
|
|
|
|
|
|
|
* a model on which it applies
|
|
|
|
* a set of permissions to which it applies (e.g. if ``perm_read`` is set, the
|
|
|
|
rule will only be checked when reading a record)
|
|
|
|
* a set of user groups to which the rule applies, if no group is specified
|
|
|
|
the rule is *global*
|
|
|
|
* a :ref:`domain <reference/orm/domains>` used to check whether a given record
|
|
|
|
matches the rule (and is accessible) or does not (and is not accessible).
|
|
|
|
The domain is evaluated with two variables in context: ``user`` is the
|
|
|
|
current user's record and ``time`` is the `time module`_
|
|
|
|
|
|
|
|
Global rules and group rules (rules restricted to specific groups versus
|
|
|
|
groups applying to all users) are used quite differently:
|
|
|
|
|
|
|
|
* Global rules are subtractive, they *must all* be matched for a record to be
|
|
|
|
accessible
|
|
|
|
* Group rules are additive, if *any* of them matches (and all global rules
|
|
|
|
match) then the record is accessible
|
|
|
|
|
|
|
|
This means the first *group rule* restricts access, but any further
|
|
|
|
*group rule* expands it, while *global rules* can only ever restrict access
|
|
|
|
(or have no effect).
|
|
|
|
|
|
|
|
.. warning:: record rules do not apply to the Administrator user
|
|
|
|
:class: aphorism
|
|
|
|
|
|
|
|
.. _reference/security/fields:
|
|
|
|
|
|
|
|
Field Access
|
|
|
|
============
|
|
|
|
|
|
|
|
.. versionadded:: 7.0
|
|
|
|
|
|
|
|
An ORM :class:`~odoo.fields.Field` can have a ``groups`` attribute
|
|
|
|
providing a list of groups (as a comma-separated string of
|
|
|
|
:term:`external identifiers`).
|
|
|
|
|
|
|
|
If the current user is not in one of the listed groups, he will not have
|
|
|
|
access to the field:
|
|
|
|
|
|
|
|
* restricted fields are automatically removed from requested views
|
|
|
|
* restricted fields are removed from :meth:`~odoo.models.Model.fields_get`
|
|
|
|
responses
|
|
|
|
* attempts to (explicitly) read from or write to restricted fields results in
|
|
|
|
an access error
|
|
|
|
|
|
|
|
.. todo::
|
|
|
|
|
|
|
|
field access groups apply to administrator in fields_get but not in
|
|
|
|
read/write...
|
|
|
|
|
|
|
|
.. _foo: http://google.com
|
|
|
|
.. _time module: https://docs.python.org/2/library/time.html
|