You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The django CMS permissions system is flexible, granular and multi-layered - it can however also sometimes seem a little
6
-
confusing!
5
+
The django CMS permissions system is flexible, granular and multi-layered.
7
6
8
-
It's important to understand its parts and how they interact in order to use it effectively.
9
7
10
-
In django CMS permissions can be granted:
8
+
****************
9
+
Permission modes
10
+
****************
11
11
12
-
* that determine **what actions a user may perform**
13
-
* that determine **on which parts of the site they may perform them**
12
+
Permissions operate in two different modes, depending on the :setting:`CMS_PERMISSION` setting.
14
13
15
-
These two dimensions of permissions are independent of each other. See :ref:`permission-strategies` below.
16
-
17
-
18
-
***********************
19
-
``CMS_PERMISSION`` mode
20
-
***********************
21
-
22
-
The first thing to understand is that as far as permissions are concerned django CMS operates in one of two modes, depending
23
-
on the :setting:`CMS_PERMISSION` setting:
24
-
25
-
* ``False`` (the default): only the standard Django Users and Groups permissions will apply
26
-
* ``True``: as well as standard Django permissions, django CMS applies a layer of permissions control
27
-
affecting *pages*
28
-
29
-
30
-
``CMS_PERMISSION`` mode *off*
31
-
=============================
32
-
33
-
When django CMS's own permission system is disabled, you have no control over permissions over particular pages. In other
34
-
words, *row-level controls on pages* do not exist.
35
-
36
-
You still have control over **what functionality** particular users and groups have in the CMS, but not over **which
37
-
content** they can exercise it on.
14
+
* Simple permissions mode (``CMS_PERMISSION = False``): only the standard Django Users and Groups
15
+
permissions will apply. This is the default.
16
+
* Page permissions mode (``CMS_PERMISSION = True``): as well as standard Django permissions, django
17
+
CMS provides row-level permissions on pages, allowing you to control the access of users to
18
+
different sections of a site, and sites within a multi-site project.
38
19
20
+
.. _key-user-permissions:
39
21
22
+
********************
40
23
Key user permissions
41
-
--------------------
24
+
********************
42
25
43
-
You can find the permissions you can set for a user or groups in the Django admin, in the *Authentication and Authorization*
44
-
section.
26
+
You can find the permissions you can set for a user or groups in the Django admin, in the
27
+
*Authentication and Authorization* section. These apply equally in Simple permissions mode and
28
+
Page permissions mode.
45
29
46
-
Filtering by ``cms`` will show the ones that belong to the CMS application. Permissions that a CMS editor will need are
47
-
likely to include:
30
+
Filtering by ``cms`` will show the ones that belong to the CMS application. Permissions that a CMS
31
+
editor will need are likely to include:
48
32
49
33
* ``cms | cms plugin``
50
34
* ``cms | page``
@@ -54,108 +38,104 @@ likely to include:
54
38
* ``cms | placeholder reference``
55
39
* ``cms | title``
56
40
57
-
Most of these offer the usual add/change/delete options, though there are some exceptions, such as ``cms | placeholder |
58
-
Can use Structure mode``.
41
+
Most of these offer the usual add/change/delete options, though there are some exceptions, such as
42
+
``cms | placeholder | Can use Structure mode``.
59
43
60
-
Users with permission to do something to a CMS model will be able to do it to *all* instances of that model when
61
-
``CMS_PERMISSION`` mode is *off*
44
+
See :ref:`use-permissions-on-groups` below on applying permissions to groups rather than users.
62
45
63
46
64
-
``CMS_PERMISSION`` mode *on*
65
-
============================
47
+
************************************
48
+
Permissions in Page permissions mode
49
+
************************************
66
50
67
-
When django CMS's permission system is enabled, a new layer of permissions is **added**, and permissions over CMS page-related
68
-
models will need to be provided **in addition** to those granted in Django's *Authentication and Authorization* models.
51
+
In Page permissions mode, you also need to give users permission to the right pages and sub-sites.
69
52
70
-
In other words, **both** Django's and django CMS's permissions will need to be granted over pages if an editor is to have
71
-
access to them.
72
53
73
-
By default, when ``CMS_PERMISSION`` mode is enabled, users will not be able to edit CMS pages unless they are Django
74
-
superusers. This is rarely desirable, so you will probably wish to configure the CMS permissions to provide more nuanced
75
-
control.
54
+
.. _global-and-per-page-permissions:
76
55
77
-
See :ref:`page-permissions` below for more.
56
+
Global and per-page permissions
57
+
===============================
78
58
79
-
New admin models
80
-
----------------
81
-
82
-
When ``CMS_PERMISSION`` is enabled, you'll find three new models available in the admin:
83
-
84
-
* :ref:`Pages global permissions <pages-global-permissions>`
85
-
* *User groups (page)*
86
-
* *Users (page)*
59
+
This can be done in two ways, *globally* or *per-page*.
87
60
88
-
You will find that the latter two simply reflect the Django Groups and User permissions that already exist in the system. They are a simpler representation of the available permissions, specific to page editing. You'll often find it more useful
89
-
to use the Django Groups and User permissions.
90
-
91
-
:ref:`Pages global permissions <pages-global-permissions>` are described below.
61
+
.. _pages-global-permissions:
92
62
93
-
.. _page-permissions:
63
+
**Global page permissions** apply to all pages (or all pages on a sub-site in a multi-site
64
+
project). Global page permissions are managed in the admin at *django CMS* > *Pages global
65
+
permissions*.
94
66
95
-
Page permissions
96
-
================
67
+
**Per-page permissions** apply to a specific page and/or its children and/or its descendants.
68
+
Per-page permissions are managed via the to
8000
olbar (*Page* > *Permissions*) when on the page in
69
+
question, in edit mode.
97
70
98
-
When ``CMS_PERMISSION`` is enabled, unless you simply make your users superusers, you'll need to give each one either global
99
-
permission, or permission over specific pages (:ref:`preferably via their membership of a group <use-permissions-on-groups>`
100
-
in either case).
71
+
Your users (unless they are Django superusers) will need at least one of global page permissions or
72
+
per-page permissions granted to them in order to be able to edit any pages at all.
101
73
102
-
Both global and specific permission granting are described below.
74
+
They will **also** need appropriate :ref:`user permissions <key-user-permissions>`, otherwise they
75
+
will have no edit rights to pages.
103
76
77
+
.. _page-permission-options:
104
78
105
-
.. _pages-global-permissions:
79
+
Page permission options
80
+
=======================
106
81
107
-
Global page permissions
108
-
-----------------------
82
+
Both global page permissions and per-page permissions can be assigned to users or groups of users.
83
+
They include:
109
84
110
-
*Pages global permissions* are available in the admin, in the *django CMS* section.
85
+
* *Can add*
86
+
* *Can edit*
87
+
* *Can delete*
88
+
* *Can publish*
89
+
* *Can change advanced settings*
90
+
* *Can change permissions*
91
+
* *Can move*
111
92
112
-
The first two options for a global permission concern **whom** they apply to.
93
+
.. _important:
113
94
114
-
Then there is list of **what actions** the editor can perform. The editors will need at least *some* of these if they are to
115
-
manage pages.
95
+
Even though a user may have *Can edit* permissions on a page, that doesn't give them
96
+
permissions to add or change plugins *within* that page. In order to be able to
97
+
add/change/delete plugins on any page, you will need to go through :ref:`the standard Django
98
+
permissions <key-user-permissions>` to provide users with the actions they can perform, for
99
+
example:
116
100
117
-
Finally, there's a list of the **sites** they can perform the actions on.
101
+
* ``cms | page | Can publish page`` to publish it
102
<
A25C
span class="diff-text-marker">+
* ``cms | cms plugins | Can edit cms plugin`` to edit plugins on the page
118
103
119
104
120
105
.. _pages-specific-permissions:
121
106
122
-
Page-specific permissions
123
-
-------------------------
107
+
Per-page permissions
108
+
====================
124
109
125
-
The CMS permissions system also provides permissions control for particular pages or hierarchies of pages in the site -
126
-
row-level permissions, in other words.
127
-
128
-
These are controlled by selecting *Permissions* from the *Page* menu in the toolbar when on the page (this options is only
129
-
available when ``CMS_PERMISSION`` mode is on).
110
+
Per-page permissions are controlled by selecting *Permissions* from the *Page* menu in the toolbar
111
+
when on the page (this options is only available when ``CMS_PERMISSION`` mode is on).
130
112
131
113
*Login required* determines whether anonymous visitors will be able to see the page at all.
132
114
133
115
*Menu visibility* determines who'll be able to see the page in navigation menus - everyone, or logged in or anonymous users
134
116
only.
135
117
136
-
*View restrictions* determine which groups and users will be able to see the page. Adding a view restriction will allow you
137
-
to set this. Note that this doesn't apply new restrictions to users who are also editors with appropriate permissions.
118
+
.. _view-restrictions:
138
119
139
-
*Page permissions* determine what editors can do to a page (or hierarchy of pages). They work just like the *Pages global
140
-
permissions* described above, but don't apply globally. They are **added to** global permissions - they don't override them.
120
+
*View restrictions* determine which groups and users will be able to see the page when it is
121
+
published. Adding a view restriction will allow you to set this. Note that this doesn't apply any
122
+
restrictions to users who are also editors with appropriate permissions.
141
123
142
-
The *Can change permission* refers to whether the user can change the permissions of a "subordinate" users Bob is the
143
-
subordinate of Alice if one of:
124
+
*Page permissions* determine what editors can do to a page (or hierarchy of pages). They are
125
+
described above in :ref:`page-permission-options`.
144
126
145
-
* Bob was created by Alice
146
-
* Bob has at least one page permission set on one of the pages on which Alice has the *Can change permissions* right
147
127
148
-
.. _important:
128
+
New admin models
129
+
----------------
149
130
150
-
Even though a user may have permissions to change a page, that doesn't give them permissions to add or change plugins
151
-
*within* that page. In order to be able to add/change/delete plugins on any page, you will need to go through the
152
-
standard Django permissions to provide users with the actions they can perform.
131
+
When ``CMS_PERMISSION`` is enabled, as well as :ref:`Pages global permissions
132
+
<pages-global-permissions>` you will find two new models available in the CMS admin:
153
133
154
-
Even if a *page permission* allows a user to edit pages in general (global) or a particular page (specific), they will
155
-
still need ``cms | page | Can publish page`` permission to publish it, ``cms | cms plugins | Can edit cms plugin`` to
156
-
edit plugins on the page, and so on.
134
+
* *User groups (page)*
135
+
* *Users (page)*
157
136
158
-
This is because the page permissions system is an additional layer over the Django permissions system.
137
+
You will find that the latter two simply reflect the Django Groups and User permissions that
138
+
already exist in the system, and can be ignored.
159
139
160
140
161
141
.. _permission-strategies:
@@ -164,49 +144,42 @@ subordinate of Alice if one of:
164
144
Permission strategies
165
145
*********************
166
146
167
-
For a simple site with only a few users you may not need to be concerned about this, but with thousands of pages belonging to
168
-
different departments and users with greatly differing levels of authority and expertise, it is important to understand who
169
-
is able to do what on your site.
170
-
171
-
172
-
Two dimensions of permissions
173
-
=============================
174
-
175
-
As noted earlier, it's useful to think of your users' permissions across two dimensions:
176
-
177
-
* what sort of things this user or group of user should be allowed to do (e.g. publish pages, add new plugins, create new
178
-
users, etc)
179
-
* which sections of the site the user should be allowed to do them on (the home page, a limited set of departmental pages,
180
-
etc)
147
+
For a simple site with only a few users you may not need to be concerned about this, but with
148
+
thousands of pages belonging to different departments and users with greatly differing levels of
149
+
authority and expertise, it is important to understand who is able to do what on your site.
181
150
182
151
183
152
.. _use-permissions-on-groups:
184
153
185
154
Use permissions on Groups, not on Users
186
155
=======================================
187
156
188
-
Avoid applying permissions to individual users unless strictly necessary. It's far better to apply them to Groups, and add
189
-
Users to Groups. Otherwise, you risk ending up with large numbers of Users with unknown or inappropriate permissions.
157
+
Avoid applying permissions to individual users unless strictly necessary. It's far better to apply
158
+
them to Groups, and add Users to Groups. Otherwise, you risk ending up with large numbers of Users
159
+
with unknown or inappropriate permissions.
190
160
191
161
192
162
Use Groups to build up permissions
193
163
==================================
194
164
195
-
Different users may require different subsets of permissions. For example, you could define a *Basic content editor* group,
196
-
who can edit and publish pages and content, but who don't have permission to create new ones; that permission would be
197
-
granted to a *Lead content editor* Group. Another Group could have permissions to use the weblog.
198
-
199
-
Some users should be allowed to edit some pages but not others. So, you could create a *Pharmacy department* and a *Neurology
200
-
department* group, which don't actually have any permissions of their own, but give each one
201
-
:ref:`pages-specific-permissions` on the appropriate landing page of the website.
165
+
Different users may require different subsets of permissions. For example, you could define a
166
+
*Basic content editor* group, who can edit and publish pages and content, but who don't have
167
+
permission to create new ones; that permission would be granted to a *Lead content editor* Group.
168
+
Another Group could have permissions to use the weblog.
202
169
203
170
Then, when managing a user, place the user into the appropriate groups.
204
171
205
172
206
-
Global or specific page permissions?
207
-
====================================
173
+
Two dimensions of permissions
174
+
-----------------------------
175
+
176
+
You can divide your users' permissions across two dimensions:
208
177
209
-
In a simple site, if you have ``CMS_PERMISSION`` enabled, add a global permission so that all editors can edit all pages.
178
+
* what sort of things this user or group of user should be allowed to do (e.g. publish pages, add
179
+
new plugins, create new users, etc)
180
+
* which sections of the site the user should be allowed to do them on (the home page, a limited set
181
+
of departmental pages, etc)
210
182
211
-
If you need more control, only allow select users access to the global permission, but add specific page permissions to
212
-
pages as appropriate for the other editors.
183
+
Groups are very useful for managing this. For example, you can create a *Europe* group for editors
184
+
who are allowed to edit the Europe page hierarchy or sub-site. The group can then be added to a
185
+
:ref:`global or per-page permission <global-and-per-page-permissions>`.
0 commit comments