All data access within Metrici is controlled through permissions.
A permission permits all members of a user group to do something.
Permissions are set at the node level, not the node version level. If you can read one version, you can read them all.
Permissions can be set with the permissions screen, with the Create Permission service, or using the ScriptNode.grant() method from a script.
The following permissions can be set for a node:
|node-read||Read the node, at least its name and reference, but not to read any of its members. Implied by any other node permission except node-use-development.|
Read members of a particular type. Implied by node-update-member.
Deprecated - read permissions are not set at the individual member type level, use node-read-all-members.
|node-read-all-members||Read all members. Implied by node-update-all-members.|
Update members of a particular type. Implied by node-administer and node-update-all-members.
Deprecated - update permissions are not set at the individual member type level, use node-update-all-members.
|node-update-all-members||Update all members.|
|node-link||Link to the node, i.e. make it a target of a member. Implied by node-administer.
node-link permission allows the user to create an inherited copy of a node, and effectively grants the user the ability to read all the members and use the type.
|node-use-type||Use the node as a type to create new nodes. Implied by node-administer and node-link.|
|node-use-draft||Use the draft version of the node, if there is one. Implied by node-administer or any node update permission. Deprecated, no longer used.|
|node-execute||Execute scripts on the node. Implied by node-administer.|
|node-administer||Administer the node.|
|node-grant-use||Permission to grant the following permissions on the node:
node-read, node-read-member, node-read-all-members, node-use-type, node-link, node-use-draft,
|node-use-manifest||Have all the permissions in the [[manifest]] defined within the node.|
|node-grant-use-manifest||Grant node-use-manifest on the node.|
You must have permission to set node permissions.
node-administer gives you the permission to set any permission.
node-grant-use and node-grant-use-manifest gives you permission to set some permissions.
The node-read-member and node-update-member permissions are set by internal processes only, and can not be set from the user interface or scripts.
Most node permissions can also be set at the package level, i.e. permissions set on the package node that apply to all the nodes in the package package (but not nodes in sub packages).
|package-read||Read any node in the package.|
|package-read-all-members||Read all members of any node in the package.|
|package-update-all-members||Update all members of any node in the package.|
|package-link||Link to any node in the package.|
|package-use-draft||Use the draft version of any node in the package. Deprecated, no longer used.|
|package-execute||Execute scripts on any node in the package.|
|package-administer||Administer any node in the package. Implied by node-administer on the package.|
|package-use||Create new nodes within the package. Implied by node-administer or package-administer.|
Package permissions have similar implications to node permissions.
You must have node-administer or package-administer to set package permissions.
node-administer implies package administer. However, package-administer does not imply node-administer. It is therefore possible to create a package and permit someone else to administer nodes within it, without giving them administer permission over the package itself.
Use draft permission
The node-use-draft and package-use-draft permissions are deprecated (they were never not set). All node permissions apply to all versions of the nodes, and additional permissions are not required to access draft permissions.
node-use-draft and package-use-draft can be set, but are ignored.
Within a script, a user who has read all members permission on a node (directly, or implied) will have the equivalent of read permission on any linked-to nodes navigated to through the script. This allows scripts to check the identity of linked nodes, but does not otherwise permit access to node data.
If permitted, you can grant read, link, use-draft and use-type permissions to public. This means that anyone can use the node in the given way.
When a public permission is granted, the node is only available when directly accessed by reference. It does not appear in the node search screen. (This is deliberate, to stop rogue nodes from turning up in searches).
If permitted, you can grant read, use-draft and execute permissions to anonymous. This means that any not signed on user can read the the node. Signed on users can access the node through the UI, but as they are accessing it their user identity is masked.
Anonymous users have very limited permissions - for example anonymous users cannot copy nodes.
You can grant other permission types to anonymous, but these will only have the effect of read-type or execute permissions. For example, if you grant node-administer on a package to anonymous, then anonymous users will be able to read and execute the node and all the package contents, but not administer it.
User group permissions
There are a separate set of permissions for user groups.
|create-usergroup||Create new user groups. Global permission.|
|create-owning-usergroup||Create an owning user group. Both create-usergroup and create-owning-usergroup are required to create an owning user group. Global permission.|
|administer-usergroup||Administer a user group.|
|administer-owning-usergroup||Administer an owning user group. This gives authority to update and delete the user group. Typically granted with own-users.|
|own-users||Maintain users within a user group. This gives authority to update and delete users in an owning user group. Typically granted with administer-owning-usergroup.|
|sign-on-as||Sign on as users within a user group.|
|grant-to-usergroup||Grant permissions to a user group or to users within the user group, or include users within the group in other groups. Implied by administer-usergroup and own-users.|
Although they are global permissions, the create-usergroup, create-owning-usergroup and maintain-profile (see below) are managed as if they were attributes of owning user groups.
There are permissions that grant the ability to perform various functions globally. They are a permisson to do something, not a permission on something.
|create-high-level-package||Ability to create high-level packages. Used in account creation.|
|Create a new user group or ownining user group. See user group permissions above.|
|super||Grant any permission. See section below. Admin only.|
|submit-service||Run internal services not authorised for normal use. Admin only.|
|update-password||Update any user's password. Admin only.|
|maintain-profile||Maintain your own profile (user name and password).|
|maintain-users||Update any user. Admin only.|
|global-sign-on-as||Sign on as any user. Admin only.|
|grant-global||Authority to grant global permissions that do not give access to data: create-usergroup, create-owning-usergroup, maintain-profile, create-high-level-package and grant-global. Used to implement principle of least priviledge in account creation.|
Each node version has a node owner. This defaults to the user that initially created the node, and is reset each time the node type is changed. The node owner's authority is used in derivation and extension scripts.
Querying node permissions
The Script Node object (and the underlying node controller objects) provide a series of mayXXX() methods to query different types of permission. These resolve permission rules. For example, they look at packages to determine package-level permissions. For this reason, there is not a one-to-one correspondence between the permission types used to set permissions and the methods used to query permissions.
All the mayXXX() methods can optionally take a user identifier. If this is not passed, the user identifier associated with the object is used. If you are checking permissions of the associated user, do not pass the user identifier. The methods that use the associated user are more efficient because they cache the permissions.
The packages temp, sandbox and purge are intended for public use. Premissions for these are defined on Public Manifest (system.app.public_manifest). New owning user groups are automatically granted node-use-manifest on these.
Within an instance of Metrici (not an account), the admin user and other high-level users will have super permission. This permits the user to grant permissions on any node (or any other resource). Users with super permission typically also have permissions to grant to any user group, including public.
Super permission does not grant the user permission to navigate to and access the node, only to set permissions. Some manual effort is required to set permissions.
If you have super user priviledges, you can open up the permission screen for a node using the URL:
domain is the internet domain you are signed on to, e.g. admin.metrici.com, and
node is the node reference, e.g. library.core.ConstantType.
You will need to grant yourself Node administer before you set any permissions.
Tip: If you are admin, you can use the following Show Node Permissions utility to bring up the permission page for a node.
The Permission Manager (library.permission.PermissionManagerType) node type can be used to provide role-based, profile-based permission management across all the nodes within a package, including sub-packages. Using it you can:
- Apply rules which indicate which user roles should have which permissions based on node tags.
- Generate permission manifests for each role.
- Assign users and user groups to the roles.
The Permission Manager Updater (library.permission.PermissionManagerUpdaterType) node type can be used to maintain the permissions automatically when the package structure changes.
Note that this has now largely been replaced by the Permission Manifest Manager.
A permission token is a string which represents a resource and a required permissions, such as "read the node somecompany.content.myPage". Permission tokens are an efficient way of one process encapsulating the permissions required to do something and another process checking that a user is indeed permitted, for example to decide whether or not to show a link to a particular user.
Permissions tokens are returned by various services, and can be created from the scripting API using the getXXXToken() methods on Script Node. Permission tokens can then be checked using the checkPermissionToken() method on Script Application.