addons/document/doc/access_permissions.rst

   1 Access control in the Document Management system
   2 ================================================
   3
   4 The purpose is to let the DMS act as a real-life management system for
   5 the file handling of some small business.
   6 The key concept, there, is the separation of access according to users
   7 and groups.
   8
   9 Fact 1: Users, in general, must NOT see each other's documents, not even
  10 their names (because they usually imply sensitive data, like eg. a doc:
  11 "Acme Company's Patent 012356 about fooobars.odf" )
  12 Fact 2: Users, sometimes, fail to comprehend complex ACL schemes, so we
  13 owe to keep things simple, a main principle applied all over the place.
  14 Fact 3: our system has both statically placed files and directories, as
  15 well as dynamic (aka "resources" in our terminology) nodes.
  16
  17 We allow/limit the access based on 3 factors (fields):
  18   - The "owner" field, which holds the user that created or "owns" the
  19     file or directory.
  20   - The "group_ids" field, on directories, which specifieds group-wise
  21     access
  22   - The "company_id" field, for multi-company access rules [1]
  23
  24 [1] at multi-company setups, we may want the same file hierarchy to apply
  25 to different companies, and also nodes to be company-specific in it.
  26
  27 Principle of "owner"
  28 ----------------------
  29 Files or directories that have an empty "owner" field are public. All users
  30 will be able to _read_ them. Only the OpenERP Administrator or specified
  31 groups, however, will be able to modify them!
  32 Files or directories that have an "owner" are private. Only their users will
  33 be able to read or modify (including delete) them.
  34 By default, all user's files are created with "owner" field set, thus private.
  35
  36 Principle of "group_ids"
  37 -------------------------
  38 Directories that have any group ids set will only (apart from their owner)
  39 allow members of these groups to read them.
  40 Directories that are created into the above directories will initially inherit
  41 (that is, copy) the group_ids of their parents, so that they also allow
  42 access to the same users.
  43
  44 Implementation note
  45 ---------------------
  46 Most of the principles are applied through record rules (see ir.rule object),
  47 so an administrator can actually readjust them.
  48 In order to have logical "areas" of folders, where different policies apply
  49 (like group folders, personal areas), default values for directories' owners
  50 and group_ids can be tuned (through the 'set default' functionality of
  51 fields).
  52
  53 Summary
  54 --------
  55
  56 Table of permissions and behavior
  57
  58 || Type | Owner set | Groups set | Description                              ||
  59 || Public |    -    |     -      | Public-readable folders, admin can write ||
  60 || Group  |    -    |     X      | Group can read, write, delete in them    ||
  61 || Group-read | X   |     X      | Group can read[2], owner can write/delete ||
  62 || Private |   X    |     -      | Only owner can read, write, delete in.   ||
  63
  64 [2] hint: using a wide group, like "Internal users" at this setup creates the
  65     effect of public-readable folders, with write permission to a non-admin user.