Skip to Content

Changes for page Permissions Configuration

Last modified by colinw on 2021/09/10 23:34
From version 11.1
edited by colinw
on 2014/11/10 23:01
Change comment: There is no comment for this version
To version 15.1
edited by colinw
on 2014/11/11 16:50
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,19 +1,30 @@
1 +{{layout}}
2 +{{layout-section ac:type="two_right_sidebar"}}
3 +{{layout-cell}}
1 1  {{warning}}
2 2  This page is currently being written. Although the information below is probably accurate, it may not be complete or may have errors.
3 3  {{/warning}}
4 4  
5 -
8 +{{info}}
9 +The information on this page applies to **iSymphony 3.1+**.
10 +{{/info}}
6 6  
7 -==== **//On this page~://** ====
12 += (% style="color: rgb(0,0,0);" %)Description(%%) =
8 8  
14 +The Permissions resource provides access to query and define permissions for iSymphony. See the reference information below for details about the REST interactions used to define permissions. The rest of this description is provided to make it easier to understand the various interactions that go into the permission system in iSymphony.
15 +{{/layout-cell}}
9 9  
17 +{{layout-cell}}
18 +{{panel title="On this page:"}}
10 10  
11 -{{toc maxLevel="2" indent="1"/}}
12 12  
13 -= Description =
21 +{{toc maxLevel="2" indent="1"/}}
22 +{{/panel}}
23 +{{/layout-cell}}
24 +{{/layout-section}}
14 14  
15 -The Permissions resource provides access to query and define permissions for iSymphony. See the reference information below for details about the REST interactions used to define permissions. The rest of this description is provided to make it easier to understand the various interactions that go into the permission system in iSymphony.
16 -
26 +{{layout-section ac:type="single"}}
27 +{{layout-cell}}
17 17  === Overview ===
18 18  
19 19  In version 3.0 and previous of iSymphony, permissions were defined for 'permissible' objects in the system - each object that could be controlled via permissions (extensions, queues, other users, etc) would store a list of the users allowed to perform actions on it, and which actions each was allowed to perform. Beginning in version 3.1 of iSymphony, the situation has been reversed, to make it easier to administer permissions and hopefully less confusing. Permissions are defined for each user or user group in the system, in a cascading manner. They are evaluated in order of decreasing specificity, and in the case of a conflicting tie, the action is allowed. This must be considered when using the REST system to define permissions. See the documentation for permissions for more details.
... ... @@ -20,11 +20,11 @@
20 20  
21 21  === Defaults ===
22 22  
23 -By default, all users in the system are allowed to perform all actions. Therefore, if a specific permission key has not been defined for a user (either on the user itself, or one of the groups it is a member of), that action should be considered allowed. When defining a permission, the default policy is also allowed, unless the allowed flag is set to false.
34 +By default, all users in the system are allowed to perform all actions. Therefore, if a specific permission key has not been defined for a user (either on the user itself, or one of the groups it is a member of), that action should be considered allowed. When defining a permission, the default policy is also allowed, unless the allowed flag is set to false.
24 24  
25 25  === **Exceptions** ===
26 26  
27 -The heart of the permission system lies in the exceptions to the rules. This allows for powerful combinations to be achieved. Generally, the objects defined by their UUIDs in the exceptions field will be allowed to perform an action if the allowed flag is false, and prevented from performing that action if the allowed flag is true. That is, they will follow the opposite of the general policy for that definition. There are a few special cases.
38 +The heart of the permission system lies in the exceptions to the rules. This allows for powerful combinations to be achieved. Generally, the objects defined by their UUIDs in the exceptions field will be allowed to perform an action if the allowed flag is false, and prevented from performing that action if the allowed flag is true. That is, they will follow the opposite of the general policy for that definition. There are a few special cases.
28 28  
29 29  = Root Resource Paths =
30 30  
... ... @@ -277,7 +277,7 @@
277 277   
278 278  {{/code}}
279 279  
280 -=== (% style="color: rgb(0,0,0);" %)Update(%%) ===
291 +=== Update ===
281 281  
282 282  {{code language="bash"}}
283 283   
... ... @@ -294,3 +294,6 @@
294 294  {{code language="bash"}}
295 295   
296 296  {{/code}}
308 +{{/layout-cell}}
309 +{{/layout-section}}
310 +{{/layout}}