[ADD] port security reference doc

diff --git a/doc/reference/cmdline.rst b/doc/reference/cmdline.rst
index 5999f9f..140405d 100644 (file)
--- a/doc/reference/cmdline.rst
+++ b/doc/reference/cmdline.rst
@@ -17,13 +17,11 @@ Running the server
 
 .. option:: -i <modules>, --init=<modules>
 
-    comma-separated list of modules to :ref:`install
-    <reference/module/lifecycle/install>` before running the server.
+    comma-separated list of modules to install before running the server.
 
 .. option:: -u <modules>, --update=<modules>
 
-    comma-separated list of modules to :ref:`update
-    <reference/module/lifecycle/update>` before running the server.
+    comma-separated list of modules to update before running the server.
 
 .. option:: --addons-path <directories>
 

diff --git a/doc/reference/data.rst b/doc/reference/data.rst
index 90121bf..bd98ded 100644 (file)
--- 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 <reference/module/lifecycle/update>`, 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 933b263..14e7847 100644 (file)
--- 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 15dbd1c..72742f0 100644 (file)
--- 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 <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
+
+    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