|
|
Security Setting of New Objects
New objects are by default created with the following security settings:
Owning User: User who is creating the object
Browse Access Level: 3 - deep
Delete Level: 2 - basic
Update Access Level: 2 - basic
Owning Groups: Primary User Group of the user who is creating the object and (meaning as well as) Owning Group(s) of the parent object of the new object
Please note that the User Group Users (e.g. Standard\\Users) is not added to the list of Owning Groups of newly created top-level objects (i.e. objects attached to a segment, even if Users is an Owning Group of the segment)
Please note that a users's Primary user group is set by the segment administrator with the operation Create User. To change an existing user's primary group, the segment administrator simply executes the operation Create User again with a new parameter for primary user group.
In the context of activity management there are various operations that set/change the Owning Groups of objects based on the settings of an assigned Activity Tracker and not based on the settings of the user who executes the operation.
If you see N/P in a field instead of a more meaningful value you probably do not have browse access to the respective object (N/P stands for No Permission).
Security Example
In this chapter we discuss security for an example security organization (see Figure 4-3) and then show what individual users are allowed to do on example data (see Figure 4-4). Please note that this example security organization has educational value but it is not well suited for the real world. See chapter Real World Example for a more realistic setup.
The example organization consists of 4 User Groups (Administrators, Users, Unspecified, and Unassigned) and 1 User (admin-Standard) created by openCRX. In addition, there are 5 User Groups (Sales, SalesTeamA, SalesTeamB, Accounting, and AccountingTeamA) and 8 Users (head-Sales, salesrep1, salesrep2, salesrep3, salesrep4, head-Accounting, accountant1, accountant2) created by the segment administrator:
The above chart reads as follows (just to give a few examples, i.e. many more statements could be made about the above chart):
UserGroup SalesTeamA is a subgroup of UserGroup Sales
UserGroup SalesTeamB is a subgroup of UserGroup Sales
UserGroup AccountingTeamA is a subgroup of UserGroup Accounting
UserGroups Sales, SalesTeamA, SalesTeamB, Accounting, and AccountingTeamA are subgroups of UserGroup Users
UserGroup Users is a supergroup of UserGroups SalesTeamA (UserGroup Users is also a supergroup of UserGroups Sales, SalesTeamB, Accounting, and AccountingTeamA)
UserGroup Unspecified is a supergroup of all other UserGroups
User admin-Standard is a member of UserGroup Administrators
Users salesrep1 and salesrep2 are both members of UserGroup SalesTeamA
Role OpenCrxUser is assigned to UserGroup Users
Role OpenCrxAdministrator is assigned to UserGroup Administrators
User admin-Standard has all the permissions of the Role OpenCrxAdministrator (because this User is a member of the UserGroup Administrators)
.
The example data consists of 6 openCRX objects (S, X, Xa, Xb, Y, and Ya):
If you, for example, look at object Xa the following security attributes are set:
Owning User: object Xa is owned by the User salesrep1
Owning Groups: object Xa is owned by the UserGroup SalesTeamA
Browse Access Level is set to deep
Delete Access Level is set to basic
Update Access Level is set to basic
Similarly, Figure 4-4 contains information about the security attributes of all the other openCRX objects.
Next, we will analyze for a few of the example users which objects they are able to browse to, which objects they are allowed to delete, and which objects they have permission to update. The whole discussion is based on the security organization as it was presented in Figure 4-3. Let's start with the user admin-Standard. On the following chart, green indicates that access is granted, red indicates that access is not granted:
Please note that the user admin-Standard is granted permission to delete object S; due to the definition of the delete access level, deleting object S will also delete its composite objects (recursively!), i.e. admin-Standard can actually delete all objects by deleting object S! It is not possible, however, that user admin-Standard navigates to - for example - object Xb and then deletes object Xb as delete access is not granted on object Xb (even though browse level access to object Xb is granted).
Let's now look at the user head-Sales. On the following chart, green indicates that access is granted, red indicates that access is not granted:
Please note that the user head-Sales is granted permission to delete objects X and Y; due to the definition of the delete access level deleting object X will also delete its composite objects (recursively!), i.e. head-Sales can actually delete object Xb by deleting object X! Similarly, head-Sales can delete object Ya by deleting object Y. It is not possible, however, that user head-Sales navigates to - for example - object Xb and then deletes object Xb as delete access is not granted on object Xb (even though browsing to object Xb is possible).
On the following chart, green indicates that access is granted to the user salesrep1, red indicates that access is not granted to salesrep1:
Please note that the user salesrep1 is granted permission to delete object X; due to the definition of the delete access level deleting object X will also delete all its composite objects (recursively!), i.e. salesrep1 can actually delete object Xb by deleting object X! It is not possible, however, that user salesrep1 navigates to - for example - object Xb and then deletes object Xb as delete access is not granted on object Xb (even though browsing to object Xb is possible).
On the following chart, green indicates that access is granted to the user salesrep2, red indicates that access is not granted to salesrep2:
On the following chart, green indicates that access is granted to the user salesrep2, red indicates that access is not granted to salesrep2:
On the following chart, green indicates that access is granted to the user salesrep2, red indicates that access is not granted to salesrep2:
Please note that the user salesrep4 is granted permission to delete object Y; due to the definition of the delete access level deleting object Y will also delete all its composite objects (recursively!), i.e. salesrep4 can actually delete object Ya by deleting object Y! It is not possible, however, that user salesrep4 navigates to - for example - object Ya and then deletes object Ya as delete access is not granted on object Ya (even though browsing to object Ya is possible).
The following figure shows access permissions of the users head-Accounting, accountant1, and accountant2. Green indicates that access is granted, red indicates that access is not granted:
