Product permissions

When subscribing to a product, the core problem to solve is that of granting the subscriber permission to use nodes created by the product publisher. For good reason, Metrici does not allow a user from one account to permit a user from another account to access their nodes, other than as an anonymous user. A special approach is therefore required for a publisher to make their product available to a subscriber.

Product publication utilitises a special feature in the permissions in which anyone can grant permissions to their account authority, i.e. the user who created their account (or, precisely, the user who is the owner of their account node), and the account authority can in turn grant those permissions on to other users that they have created. Specifically, the publisher grants the node-grant-use permission to the account authority, which permits the account authority to grant read and link type permissions (node-read, node-read-member, node-read-all-members, node-use-type, node-link, node-use-draft, package-read, package-read-all-members, package-link, package-use-draft, node-grant-use), but not update, package use or administration permissions.

Identifying what permissions are required and granting them to the account authority is complicated, and is looked after by instances of Product, which are generated by instances of Product Builder. The salient parts of this are:

  • The publisher lists packages that contain the nodes that make up the product in the Package List member type.
  • From this, the derivation script in Interpret Product Descriptor creates a manifest in Offer Manifest Items that describes the permissions that the subscribers to the product need.
  • From this, the derivation script in Grant Publish creates a standard permission manifest in Manifest Items that describes the permissions that the account authority needs in order to grant permissions to the subscriber, and then gives the account authority permission to use the manifest and also to access the product node. This means that the account authority now has authority to grant permissions on the product nodes.
  • Product installation is carried out by executing a method on the subscriber's account. This creates a subscription node with is an instance of Subscription.
  • The subscription node links back to the product using the Product member type, and uses the Derive Subscription Manifest derivation to create a standard Manifest Items manifest from the Offer Manifest Items from the product.
  • The account authority grants node-use-manifest on the subscription node to the subscriber's primary user group and node-grant-use-manifest to the subscriber. This means that any of the primary users in the subscriber's account can use the product, and that the subscriber can grant permissions to other user groups also. (Question - why not let all of the primary users grant use of the manifest?)

The permissions are all granted using manifests, and the manifests are all created using derivation. The permissions that the subscriber has can therefore be updated by the publisher, for example when a new version of the product is released.

The approach above dictates the core structure of product packaging, subscription and installation. It involves instances of the following:

  • Product Builder which is used to describe the product.
  • Product which is generated from the product builder, and which is used as the basis for installation.
  • Subscription which is created by the account authority and is used to grant permission on the product to the subscriber.

As well as their core role in managing permissions, these types are used to manage other aspects of product packaging, subscription and installation. They are examined in more detail in the following sections.