Crystal Enterprise uses object security, which means that security is set for each object in the system and not for each user. Thus, for a particular object, certain users and certain groups may do certain things with it, depending on the settings on the object. To modify the security settings for an object, you decide which roles or rights to grant a particular user or group for that object.
A role or access mode is a predefined set of object rights that allows you to set common object security levels quickly. They are designed to cover the most common cases of security rights settings. It is recommended that you start by using roles, and then apply more granular rights if necessary. The rights that are listed for each role are always granted to the principal, and never denied. See the "Appendix A: Object Rights and Access Levels" in the Crystal Enterprise Administrator's Guide for a list of the granular rights granted for each role.
A right is essentially permission to perform an action on an object. When a user or group is granted a right, he or she is given permission to perform an action. For example, if Joel were granted the ceRightDelete for the World Sales Report, he would be allowed to delete the report from the system. Rights may be granted, denied, or not specified at all. Rights can be explicitly set on an object or they can be inherited from a parent folder; rights can also be inherited from a group that the user belongs to. The SDK uses two flags to specify whether or not a user's permissions on an object are inherited: these flags are AdvancedInheritFolders and AdvancedInheritGroups respectively. When rights are inherited, you can still explicitly set rights on the object.
The Crystal Enterprise system defines a base set of rights that apply to all objects in the system. The ceRightDelete, for example, is a base right: it allows a user to delete an object. In addition to the base rights in the system, each type of InfoObject provides a set of rights that are specific to itself. For example, the report object, which can be scheduled, provides a right (ceRightSchedule) that manages whether or not a user can schedule the report. The folder object, which cannot be scheduled, does not supply this right. However, when examining the rights on a folder, you will notice that the folder has this right as well. This right is a part of the folder's available rights.
Available rights are all the rights that have been supplied to the APS by each plugin (and thus each type of InfoObject). See the KnownRights Property. For example, the report plugin supplies a set of rights and makes them known to the APS; Crystal Analysis, which plugs in to Crystal Enterprise, also supplies a set of rights for its objects. Combined, these rights are the available rights in the APS. Each InfoObject in the system supports the available rights regardless of whether or not it uses them. For example, you can set the schedule right (ceRightSchedule) on a folder object even though you can't schedule a folder.
The reason for available rights being shared among all objects is due to the nature of inherited rights. There are two types of inheritance: folder inheritance and group inheritance. In folder inheritance, since one object can belong to another object, it is possible to set rights only on the parent folder and have the child objects inherit rights. That is, a user or group can inherit rights that were set on the parent of the child object. Thus, to further explain the concept of available rights, on a folder you can set ceRightSchedule, which means nothing to the folder, but you can have the reports, which recognize this right and belong in the folder, inherit that right. Group inheritance behaves in much the same way.
Inheritance poses some problems, as is illustrated in the previous example. It is sometimes not always desirable for a user to inherit rights from a group or from the parent object. You can, therefore, choose whether or not you want to use inheritance (group or folder) by setting two flags, ObjectPrincipal.AdvancedInheritFolders, and ObjectPrincipal.AdvancedInheritGroups. These will be demonstrated later.
When these flags are set, you can still explicitly set rights on the child object.
However, things become confusing depending on whether or not the parent object or group has explicitly set a particular right. The Crystal Enterprise object security model is designed such that, if a right is left "not specified" (that is, it is neither explicitly granted or denied) the right is denied by default. Additionally, if contradictory settings result in a right being both granted and denied to a user or group, the right is denied by default. This "denial based" design assists in ensuring that users and groups do not automatically acquire rights that are not explicitly granted. The following table indicates how rights are passed down via inheritance:
| Explicit parent object / group right | Explicit child right | Net right |
|---|---|---|
You can also set owner rights on an object for a user. For example, ceRightOwnerDeleteInstance gives the user the ability to delete an instance object, but only if he or she owns it. This user may not have the right to delete objects that he or she does not own.
Go to the next section: Viewing a user's rights on an object.
| Crystal Decisions, Inc. http://www.crystaldecisions.com Support services: http://support.crystaldecisions.com |