From afcb89ab3aa8af4fbd46d84f7b2fb0a8bce5b7d7 Mon Sep 17 00:00:00 2001 From: Xavier Morel Date: Fri, 29 Aug 2014 13:39:07 +0200 Subject: [PATCH] [ADD] port security reference doc --- doc/reference/cmdline.rst | 6 +-- doc/reference/data.rst | 3 +- doc/reference/module.rst | 17 +------- doc/reference/security.rst | 88 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 93 insertions(+), 21 deletions(-) diff --git a/doc/reference/cmdline.rst b/doc/reference/cmdline.rst index 5999f9fa1ad..140405d0037 100644 --- a/doc/reference/cmdline.rst +++ b/doc/reference/cmdline.rst @@ -17,13 +17,11 @@ Running the server .. option:: -i , --init= - comma-separated list of modules to :ref:`install - ` before running the server. + comma-separated list of modules to install before running the server. .. option:: -u , --update= - comma-separated list of modules to :ref:`update - ` before running the server. + comma-separated list of modules to update before running the server. .. option:: --addons-path diff --git a/doc/reference/data.rst b/doc/reference/data.rst index 90121bfc03e..bd98ded3e8b 100644 --- a/doc/reference/data.rst +++ b/doc/reference/data.rst @@ -52,8 +52,7 @@ following attributes: ``context`` context to use when creating the record ``forcecreate`` - in :ref:`update mode `, whether the - record should be created if it doesn't exist. + in update mode whether the record should be created if it doesn't exist Requires an :term:`external id`, defaults to ``True``. diff --git a/doc/reference/module.rst b/doc/reference/module.rst index 933b263f7ba..14e7847f1da 100644 --- a/doc/reference/module.rst +++ b/doc/reference/module.rst @@ -2,6 +2,8 @@ Modules ======= + + .. _reference/module/manifest: Manifest @@ -60,21 +62,6 @@ Available manifest fields are: automatically adds CRM campaigns tracking to sale orders without either ``sale`` or ``crm`` being aware of one another -.. _reference/module/lifecycle: - -Lifecycle -========= - -.. _reference/module/lifecycle/install: - -Install -------- - -.. _reference/module/lifecycle/update: - -Update ------- - .. _semantic versioning: http://semver.org .. _existing categories: https://github.com/odoo/odoo/blob/master/openerp/addons/base/module/module_data.xml diff --git a/doc/reference/security.rst b/doc/reference/security.rst index 15dbd1c0c7e..72742f0639c 100644 --- a/doc/reference/security.rst +++ b/doc/reference/security.rst @@ -4,13 +4,101 @@ 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, +thus applying security mechamisms to users. + .. _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 group *A* +which allows writing and group *B* which allows deleting, he can both write +and delete. + +If no group is specified, the access control applies to all users, otherwise +it only applies to the users belonging to the specific 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 ` 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 + + although access rules do + +Field Access +============ + +.. versionadded:: 7.0 + +An ORM :class:`~openerp.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:`~openerp.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... + +Workflow transition rules +========================= + +Workflow transitions can be restricted to a specific group. Users outside the +group can not trigger the transition. + +.. _foo: http://google.com +.. _time module: https://docs.python.org/2/library/time.html