Skip to content
This repository
Browse code

Added documentation for page permission management

  • Loading branch information...
commit 074041a8628b3f5b2d7f7e25f93750d3b6f92e70 1 parent 35f76b0
Ioan Alexandru Cucu authored September 19, 2012
56  docs/advanced/permissions_reference.rst
Source Rendered
... ...
@@ -0,0 +1,56 @@
  1
+##########
  2
+Permissions
  3
+##########
  4
+
  5
+In django-cms you can set two types of permissions:
  6
+
  7
+1. View restrictions for restricting view access to regular users
  8
+2. Page permissions for allowing staff users to only have rights on certain sections of the site
  9
+
  10
+To enable these features, ``settings.py`` requires:
  11
+
  12
+    CMS_PERMISSION = True
  13
+
  14
+*****************
  15
+View restrictions
  16
+*****************
  17
+
  18
+View restrictions can be set-up from the *View restrictions* formset on any cms page.
  19
+Once a page has at least one view restriction installed, only users with granted access will be able to see that page.
  20
+Mind that this restriction is for viewing the page as an end-user (frontend view), not viewing the page in the admin interface!
  21
+
  22
+View restrictions are also controlled by the *CMS_PUBLIC_FOR* setting. Possible values alre ``all`` and ``staff``.
  23
+This setting decides if pages without any view restrictions are public to everyone or staff only.
  24
+
  25
+
  26
+****************
  27
+Page permissions
  28
+****************
  29
+
  30
+After setting ``CMS_PERMISSION = True`` you will have three new models in the admin index:
  31
+
  32
+1. Users (page)
  33
+2. User groups (page)
  34
+3. Pages global permissions
  35
+
  36
+Using *Users (page)* you can easily add users with permissions over cms pages.
  37
+
  38
+You would be able to create an user with the same set of permissions using the usual *Auth.User* model, but using *Users (page)* is more convenient.
  39
+
  40
+A new user created using *Users (page)* with given page add/edit/delete rights will still not be able to make any changes to pages straight away.
  41
+He must first be assinged to a set of pages over which he may exercise these rights.
  42
+This is done using the *Page permissions* formset on any page.
  43
+
  44
+The *Page permission* formset has multiple checkboxes defining different permissions: can edit, can add, can publish, can move and can change permission.
  45
+These define what kind of actions the user/group can do on the pages on which the permissions are being granted through the *Grant on* dropdown.
  46
+
  47
+*Can change permission* referes to whether the user can change permissions to his subordinate users. Bob is the subordinate of Alice if one of:
  48
+
  49
+* Bob was created by Alice
  50
+* Bob has has at least one page permission set on one of the pages on which Alice has the *Can change permissions* right
  51
+
  52
+
  53
+**Note:** Mind that even though a new user created using *User (page)* has rights to change a page, that doesn't give him the right to add a plugin within that page.
  54
+In order to be able to add/change/delete plugins on any page, you will need to go through the usual *Auth.User* model and give the new user permissions to each plugin you want him to have access to.
  55
+For example, if you want the new user to be able to use the text plugin, you will need to give him the following rights: ``text | text | Can add text``, ``text | text | Can change text``, ``text | text | Can delete text``.
  56
+
1  docs/index.rst
Source Rendered
@@ -39,6 +39,7 @@ Advanced
39 39
     advanced/sitemap
40 40
     advanced/templatetags
41 41
     advanced/cli
  42
+    advanced/permissions_reference
42 43
 
43 44
 
44 45
 *****************

0 notes on commit 074041a

Please sign in to comment.
Something went wrong with that request. Please try again.