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.|
|node-read-member||Read members of a particular type. Implied by node-update-member.|
|node-read-all-members||Read all members. Implied by node-update-all-members.|
|node-update||Update members of a particular type. Implied by node-administer.|
|node-update-all-members||Update all members. Implied by node-update.|
|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.|
|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.|
|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 do not of themselves permit the user to do anything, but they make draft versions of the node visible. So if you want to expose a draft node, you need to set both the appropriate permission and node-use-draft.
For package-level permissions this gets more complicated, because if the package is itself draft (i.e. there is only a version 1 and it is not frozen), then it will not be visible for package-level permission checking unless node-use-draft is also set. So if you want to, say, grant package-read-all-members to all members of a package you need to set package-read-all-members, package-use-draft and node-use-draft.
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.|
|create-owning-usergroup||Create an owning user group. Both create-usergrop and create-owning-usergroup are required to create an owning user group.|
|administer-usergroup||Administer a user group.|
|administer-owning-usergroup||Administer an owning user grouo.|
|own-users||Maintain users within a user group.|
|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.|
Users with create-high-level-package can create high-level packages. This is not generally available for normal use.
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 [[metrici.library.utils.ShowNodePermissions]] 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.