python

• Role Examples
  Examples of how Roles works
• Working with user permissions
  A few examples on interacting with user permissions.

reference

• addAction
  Assigns a SoftLayer_User_Permission_Action object to the group.
• addBulkActions
  Assigns multiple SoftLayer_User_Permission_Action objects to the group.
• addBulkResourceObjects
  Links multiple SoftLayer_Hardware_Server, SoftLayer_Virtual_Guest, or SoftLayer_Virtual_DedicatedHost objects to the group. All objects must be of the same type.
• addResourceObject
  Links a SoftLayer_Hardware_Server, SoftLayer_Virtual_Guest, or SoftLayer_Virtual_DedicatedHost object to the group.
• createObject
  Customer created permission groups must be of type NORMAL. The SYSTEM type is reserved for internal use. The account id supplied in the template permission group must match account id of the user who is creating the permission group. The user who is creating the permission group must have the permission to manage users.
• deleteObject
  Customer users can only delete permission groups of type NORMAL. The SYSTEM type is reserved for internal use. The user who is creating the permission group must have the permission to manage users.
• editObject
  Allows a user to modify the name and description of an existing customer permission group. Customer permission groups must be of type NORMAL. The SYSTEM type is reserved for internal use. The account id supplied in the template permission group must match account id of the user who is creating the permission group. The user who is creating the permission group must have the permission to manage users.
• getAccount
• getActions
• getObject
  Retrieve a SoftLayer_User_Permission_Group record.
• getRoles
• getType
  The type of the permission group.
• linkRole
  Links a SoftLayer_User_Permission_Role object to the group.
• removeAction
  Unassigns a SoftLayer_User_Permission_Action object from the group.
• removeBulkActions
  Unassigns multiple SoftLayer_User_Permission_Action objects from the group.
• removeBulkResourceObjects
  Unlinks multiple SoftLayer_Hardware_Server, SoftLayer_Virtual_Guest, or SoftLayer_Virtual_DedicatedHost objects from the group. All objects must be of the same type.
• removeResourceObject
  Unlinks a SoftLayer_Hardware_Server, SoftLayer_Virtual_Guest, or SoftLayer_Virtual_DedicatedHost object from the group.
• SoftLayer_User_Permission_Group
  The SoftLayer_User_Permission_Group data type contains local attributes to identify and describe the permission groups that have been created within IMS. These includes a name, description, and account id. Permission groups are defined specifically for a single [SoftLayer_Account](/reference/datatypes/SoftLayer_Account). It also contains relational attributes that indicate what SoftLayer_User_Permission_Action objects belong to a particular group, and what SoftLayer_User_Permission_Role objects the group is linked.
• SoftLayer_User_Permission_Group
  The SoftLayer_User_Permission_Group class is one of several classes that make up the customer permission system. It is a role-based system that includes defined actions which can be 'grouped' together using a SoftLayer_User_Permission_Group class. These groups of actions are then used to define roles, and the roles are assigned to users. The SoftLayer_User_Permission_Group is also used to track the resources or account devices to which a user has been granted access. The types of resources that users can be granted access is defined in [SoftLayer_User_Permission_Resource_Type](/reference/datatypes/SoftLayer_User_Permission_Resource_Type). When a [SoftLayer_User_Customer](/reference/datatypes/SoftLayer_User_Customer) is created, a SoftLayer_User_Permission_Group and SoftLayer_User_Permission_Role is created specifically for the user with a group type of SYSTEM. When the UI is used to alter the permissions of a customer user, the actions are added or removed from this group. The api can not be used to alter the permissions in this group. If an account wants to create their own unique permission groups and roles, the UI can not be used to manage them. This is also true for device access. Either, the UI can be used to track the devices to which users are granted access which will use the SYSTEM group, or the api can be used, making the UI information inaccurate. User Customers can be assigned to multiple roles but it is recommended to either use the UI for managing account users permissions or only use the api. Mixing the two will lead to confusing results as the UI will not show any permissions assigned to a user via a customer created role/group combination. Proceed with caution. One or more [SoftLayer_User_Permission_Action](/reference/datatypes/SoftLayer_User_Permission_Action) are assigned to one or more SoftLayer_User_Permission_Group Objects. One ore more SoftLayer_User_Permission_Group objects can be linked to a [SoftLayer_User_Permission_Role](/reference/datatypes/SoftLayer_User_Permission_Role). A single SoftLayer_User_Permission_Group object can be linked to multiple SoftLayer_User_Permission_Role objects. The [SoftLayer_User_Permission_Role](/reference/datatypes/SoftLayer_User_Permission_Role) is assigned to one or more [SoftLayer_User_Customer](/reference/datatypes/SoftLayer_User_Customer). The [SoftLayer_User_Permission_Action](/reference/datatypes/SoftLayer_User_Permission_Action) class defines the permissions that are required in order for a [SoftLayer_User_Customer](/reference/datatypes/SoftLayer_User_Customer) to perform certain actions within IMS. Resources belonging to the user's account can also be linked to permission groups. See [SoftLayer_User_Permission_Resource_Type](/reference/datatypes/SoftLayer_User_Permission_Resource_Type).
• unlinkRole
  Removes a link from SoftLayer_User_Permission_Role object to the group.