document: access permissions documentation, draft.
bzr revid: p_christ@hol.gr-20101027102324-zcvyhz13iw75tb0k
This commit is contained in:
parent
0f5a276365
commit
24d70f724b
|
@ -0,0 +1,65 @@
|
||||||
|
Access control in the Document Management system
|
||||||
|
================================================
|
||||||
|
|
||||||
|
The purpose is to let the DMS act as a real-life management system for
|
||||||
|
the file handling of some small business.
|
||||||
|
The key concept, there, is the separation of access according to users
|
||||||
|
and groups.
|
||||||
|
|
||||||
|
Fact 1: Users, in general, must NOT see each other's documents, not even
|
||||||
|
their names (because they usually imply sensitive data, like eg. a doc:
|
||||||
|
"Acme Company's Patent 012356 about fooobars.odf" )
|
||||||
|
Fact 2: Users, sometimes, fail to comprehend complex ACL schemes, so we
|
||||||
|
owe to keep things simple, a main principle applied all over the place.
|
||||||
|
Fact 3: our system has both statically placed files and directories, as
|
||||||
|
well as dynamic (aka "resources" in our terminology) nodes.
|
||||||
|
|
||||||
|
We allow/limit the access based on 3 factors (fields):
|
||||||
|
- The "owner" field, which holds the user that created or "owns" the
|
||||||
|
file or directory.
|
||||||
|
- The "group_ids" field, on directories, which specifieds group-wise
|
||||||
|
access
|
||||||
|
- The "company_id" field, for multi-company access rules [1]
|
||||||
|
|
||||||
|
[1] at multi-company setups, we may want the same file hierarchy to apply
|
||||||
|
to different companies, and also nodes to be company-specific in it.
|
||||||
|
|
||||||
|
Principle of "owner"
|
||||||
|
----------------------
|
||||||
|
Files or directories that have an empty "owner" field are public. All users
|
||||||
|
will be able to _read_ them. Only the OpenERP Administrator or specified
|
||||||
|
groups, however, will be able to modify them!
|
||||||
|
Files or directories that have an "owner" are private. Only their users will
|
||||||
|
be able to read or modify (including delete) them.
|
||||||
|
By default, all user's files are created with "owner" field set, thus private.
|
||||||
|
|
||||||
|
Principle of "group_ids"
|
||||||
|
-------------------------
|
||||||
|
Directories that have any group ids set will only (apart from their owner)
|
||||||
|
allow members of these groups to read them.
|
||||||
|
Directories that are created into the above directories will initially inherit
|
||||||
|
(that is, copy) the group_ids of their parents, so that they also allow
|
||||||
|
access to the same users.
|
||||||
|
|
||||||
|
Implementation note
|
||||||
|
---------------------
|
||||||
|
Most of the principles are applied through record rules (see ir.rule object),
|
||||||
|
so an administrator can actually readjust them.
|
||||||
|
In order to have logical "areas" of folders, where different policies apply
|
||||||
|
(like group folders, personal areas), default values for directories' owners
|
||||||
|
and group_ids can be tuned (through the 'set default' functionality of
|
||||||
|
fields).
|
||||||
|
|
||||||
|
Summary
|
||||||
|
--------
|
||||||
|
|
||||||
|
Table of permissions and behavior
|
||||||
|
|
||||||
|
|| Type | Owner set | Groups set | Description ||
|
||||||
|
|| Public | - | - | Public-readable folders, admin can write ||
|
||||||
|
|| Group | - | X | Group can read, write, delete in them ||
|
||||||
|
|| Group-read | X | X | Group can read[2], owner can write/delete ||
|
||||||
|
|| Private | X | - | Only owner can read, write, delete in. ||
|
||||||
|
|
||||||
|
[2] hint: using a wide group, like "Internal users" at this setup creates the
|
||||||
|
effect of public-readable folders, with write permission to a non-admin user.
|
Loading…
Reference in New Issue