[FIX] website_membership support negative ids

[odoo/odoo.git] / doc / 04_security.rst

diff --git a/doc/04_security.rst b/doc/04_security.rst
index 52d5643..bb0ce46 100644 (file)
--- a/doc/04_security.rst
+++ b/doc/04_security.rst
@@ -1,6 +1,8 @@
-=================================================
-Security in OpenERP: users, groups and user roles
-=================================================
+.. _security:
+
+==================================
+Security in OpenERP: users, groups
+==================================
 
 Users and user roles are critical points concerning internal security in
 OpenERP. OpenERP provides several security mechanisms concerning user roles,
@@ -47,16 +49,15 @@ groups define the user access rights.
 
 Figure 3: Example of group membership for a given user
 
-
-Record rules
-============
+Rights
+======
 
 Security rules are attached to groups. You can assign several security 
 rules at the group level, each rule being of one of the following types :
 
  - access rights are global rights on an object,
  - record rules are records access filters,
- - record field rules are fields access filters,
+ - fields access right,
  - workflow transition rules are operations rights.
  
 You can also define rules that are global, i.e. they are applied to all
@@ -70,7 +71,7 @@ that suit all applications. Therefore, like SAP, OpenERP is by default
 pre-configured with best-practices.
 
 Access rights
-+++++++++++++
+=============
 
 Access rights are rules that define the access a user can have on a particular
 object . Those global rights are defined per document type or model. Rights 
@@ -97,14 +98,49 @@ users of that group will see business opportunities in which he or she is
 flagged as the salesman. The rule can be salesman = connected_user. With 
 that rule, only records respecting the rule will be displayed.
 
-Record field rules
-++++++++++++++++++
-
-Every field of an OpenERP object can be access-controlled. Record field is 
-a right to see or write a particular field on an object. For example, you 
-can limit the right to have access to the margin of a sale order to the 
-sales managers group only.
 
+Field access rights
++++++++++++++++++++
+
+.. versionadded:: 7.0
+
+OpenERP now supports real access control at the field level, not just on the view side.
+Previously it was already possible to set a ``groups`` attribute on a ``<field>`` element
+(or in fact most view elements), but with cosmetics effects only: the element was made
+invisible on the client side, while still perfectly available for read/write access at
+the RPC level.
+
+As of OpenERP 7.0 the existing behavior is preserved on the view level, but a new ``groups``
+attribute is available on all model fields, introducing a model-level access control on
+each field. The syntax is the same as for the view-level attribute::
+
+    _columns = {
+        'secret_key': fields.char('Secret Key', groups="base.group_erp_manager,base.group_system")
+     }
+
+There is a major difference with the view-level ``groups`` attribute: restricting
+the access at the model level really means that the field will be completely unavailable
+for users who do not belong to the authorized groups:
+
+* Restricted fields will be **completely removed** from all related views, not just
+  hidden. This is important to keep in mind because it means the field value will not be
+  available at all on the client side, and thus unavailable e.g. for ``on_change`` calls.
+* Restricted fields will not be returned as part of a call to
+  :meth:`~openerp.osv.orm.fields_get` or :meth:`~openerp.osv.orm.fields_view_get`
+  This is in order to avoid them appearing in the list of fields available for
+  advanced search filters, for example. This does not prevent getting the list of
+  a model's fields by querying ``ir.model.fields`` directly, which is fine. 
+* Any attempt to read or write directly the value of the restricted fields will result
+  in an ``AccessError`` exception.
+* As a consequence of the previous item, restricted fields will not be available for
+  use within search filters (domains) or anything that would require read or write access.
+* It is quite possible to set ``groups`` attributes for the same field both at the model
+  and view level, even with different values. Both will carry their effect, with the
+  model-level restriction taking precedence and removing the field completely in case of
+  restriction.
+
+.. note:: The tests related to this feature are in ``openerp/tests/test_acl.py``.
+ 
 Workflow transition rules
 +++++++++++++++++++++++++
 
@@ -154,3 +190,4 @@ accesses of every users of OpenERP.
 There are user groups that are between normal groups and the super user. 
 Those groups are Administration / Configuration and Administration / Access Rights. 
 It gives to the users of those groups the necessary rights to configure access rights.
+