Permission System Terminology
In uPortal, a permission represents a permission for a principal to perform some activity on a target.
Term | Description |
---|---|
Principal | The entity to which the permission is being granted or denied. This value must be a person or group. Examples: John Smith, All Students |
Activity | The activity represented by the permission. The activity is generally some action within the portal, such viewing or editing some uPortal entity type. Activities are associated with an owner and are registered in the database via the import/export system. Examples: Create Users, View Stack Traces, Subscribe to a Fragment |
Target | The target of the permission. This value might be a user, group, portlet, string, or any other object recognized by the activity's owner. Examples: Map Portlet, Stack Trace |
Owner | Permissions category used to organize activities. Owners are registered in the database via the import/export system. Examples: Groups, uPortal System |
Users and groups may potentially be both principals and targets for various permissions. For example, we might grant Portal Administrators (principal) the permission to view users (activity) in Everyone (target).
Permission Types and Inheritance
Permissions may be granted, denied, or inherited.
Type | Description |
---|---|
GRANT | Grant this permission to the principal. |
DENY | Deny this permission to the principal. |
INHERIT | Inherit permissions from any parent groups. This type has the same effect as not setting any explicit permissions. If no parent permission can be found, the portal system will default to denying the permission. |
Permissions set on a group-type principal will be inherited by that group's children unless more targeted permissions are set on the children.
Permissions on group-type targets can also be inherited by that target's children. For example, if we give Amy Administrator the permission to view All Portlets, she will receive permission to view the Maps Portlet because the Maps Portlet is part of the All Portlets group.
Superusers
Any user granted the superuser permission will receive all permissions regardless of the portal's permission registrations. It is not possible to block a superuser from receiving a permission, and DENY permissions will have no effect. By default, Portal Administrators receive the superuser permission.
Editing Permissions
Permission assignments may be edited through the Permissions Administration portlet or through the import/export system. Permission owner and activity registrations may be updated through import/export.