Permissions

Permissions constrain the types of actions that a user can perform on an object. The Administrator object types, environments, hosts, nodes, resource templates, logging appenders, and applications, have permissions that grant access of a particular type to lists of users and groups. Enterprise-level permissions control whether a user can manage users and create top-level objects (which are not controlled by the permission settings of other objects.

Permission Types

There are three types of permissions—View, Edit, and Owner—that are generally applicable to any type of object. These permissions allow the following actions:

  • View Browse objects in a list or view details for an object. Excludes the viewing of object permissions.
  • Edit
    • Perform all the actions allowed with View.
    • Edit the properties of an object.
    • Add items to a parent object. For example, if a you have Edit permission for an environment, then you can add a node, application, or any other type of object that belongs to an environment to that environment. When you add an object, its parent’s permissions are copied into that new object. Additionally, you are granted Owner permission for that object.
  • Owner
    • Perform all the actions allowed with Edit.
    • View and modify object permissions.
    • Delete the object.

In addition to the View, Edit, and Owner permission types, there are object-specific permission types and enterprise permission types.

Object-specific permission types grant permissions for actions that apply only to specific types of objects. For example, environments have a Create Node permission type. In order to be able to create nodes in an environment, a user would require either Edit or Create Node permission for the environment. The ability to perform runtime actions such as start, stop, install, uninstall, deploy, and undeploy is also controlled by object-specific permission types. For example, nodes have a Start-Stop permission type.

Enterprise permission types grant permissions for actions that apply to objects whose parent is the enterprise object. Many Administrator objects such as nodes and resource instances are created under a parent object that can be created by a user. For example, an environment is the parent of a node. Permissions on user-created parent objects control who can create new child objects. For example, if you have Edit permission for an environment, you can create a node in that environment. The parent of other objects, such as environments, resource templates, and hosts is the enterprise object. The permissions of such objects are managed in the Enterprise Permissions screen. For example, the permission type to create an environment in the Enterprise Permissions screen is Create Environment. Enterprise permission types can be granted by superusers.

Permission States

If you select multiple objects of the same type and open the Permissions screen, the checkbox can take the following values:

  • - the selected objects do not grant that permission type to the user or group.
  • - the selected objects grant that particular type of permission to the user or group.
  • - at least one of the selected objects grants the permission type to the user or group. For example, if you select nodes Node1, Node2, and Node3, and appears next to a user in the Edit column, the user might have been granted Edit permission for Node1 and Node2, but not to Node3.

To change the permission state:

  • - The first click toggles to . Converting into grants the user or group the chosen permission type for all selected objects for which the user or group does not have the permission type. If a selected object already has the permission type, the value doesn't change.
  • or - Click toggles between the on and off states.

Default Permissions and Permission Propagation

  • The default permission for any object is no permission.
  • When you create an object, you are granted Owner permission for the object.
  • When a child object is created, the View permissions from the parent object are propagated to the child object. For example, a user that had View permission for an environment will have View permission for a newly created node in that environment. However, if you change the View permission on the parent environment at a later time, the change is not propagated to the nodes.
  • When a group is granted a permission, all the group members, including the members of any child groups of a parent group, are granted the permission.
  • When a user is in multiple groups where the groups have varying permissions, the user is granted the union of all permissions.