Ariadne has a user and group management system comparable to that of Windows NT. User can be grouped together in groups. Each user or group can be assigned different grants on each 'directory'. However, grants are a bit more complex in Ariadne. Instead of the simple read, write and execute grant, Ariadne defines a number of basic grants.

Basic Grants

  • add  The add grant allows a user to add another object under the current object. Which object types are allowed to be added is defined in the current directory.
  • config  The config grant allows a user to configure the current object. Allowing the user to use the config tab in the menu and adjust caching, rights of other users on this object, and children of this object. In effect this grant makes the user an administrator of part of the tree.
  • read  Read is the most basic grant. It allows a user to read the content of the current object and its children.
  • edit  This grant allows the user to edit the normal data fields of the current object and its children.
  • delete  This grant allows the user to delete the current object and all its children. If any child object cannot be deleted for whatever reason, the parent also won't be deleted.
  • layout  With the layout grant a user can add and change object templates (PINP). This allows a user to change the appearance of an Ariadne site per object.
  • none  This is really not a grant used in the system, but it is convenient to use as a placeholder where you want to remove all grants set in parent objects for a specific group or user. This is only effective if this is the only grant set in an object for this group or user.

Assigning grants

Assigning grants to a user or group is a two step process. First you must select the user or group. You can either type in the full path to the user or group object, or use the browse button to select it. Then you must enter the grants in the grants input field to the right.

You can assign grants simply by listing them, seperated by either spaces or comma's. e.g:

  read, add, edit, delete

It is also possible to start with the grants that are currently set for that user, and add or delete grants from it:

  {}, -config, +layout

And finally you can also copy the grants from another user of group and add or delete grants from there:

  {users}, +config, +layout

Finally press the add button to assign the grants to the user or group.

Mixing User and Group Grants

The way group and user grants work to create a set of grants for a user is a bit complex. When a user wants to access a certain object, the system checks from the object, via it's parents back to the root for the first object which has grants specific for that user. It then checks again for each group of which the user is a member, but it will stop at the path where user grants were found. All group grants are then added to the user grants.

Note: You can only change grants set for a specific user by setting different grants for that user, not by setting grants for a group. The usergrants will remain.
You can only change grants set for a specific group by setting different grants for that group, all grants for all groups of which a user is a member will be combined.

A few examples, assume that the user is a member of group1 and group2.

  /        user:   read add edit delete 
  /system/ group1: read

This allows the user to still add, edit or delete anything under the /system/ tree, since his user grants have not been overriden.

  /          user:   read add edit delete 
  /anobject/ group1: read layout

This allows the user to layout anything starting with /anobject/, while still allowing adding, editing and deleting objects, since the group grants only add to the user grants.

  /                    user:   read add edit delete 
  /anobject/           group1: read layout 
  /anobject/subobject/ user:   read

This would allow the user only read grants starting with /anobject/subobject/, since the user grants are overriden there. Group grants before this object don't add their grants.

More complex situations are possible, but the main rule is: group grants add to user grants or other group grants, they can only overrule previous grants set for the same group; user grants overrule all grants for a specific user.

Grant Types

The basic grants introduced above are actually 'global' grants. This means that when you set such a grant, it will affect both the current object, on which the grant was set, and all objects below it, it's children. There are two more grant types, 'local' and 'child'.

The local grant only applies to the object on which it is defined. When you assign a local grant 'edit' to an account for an object, the user or group of users can only edit that exact object, not any of its children. A local grant is set by prefixing the basic grant with a '=' sign. e.g.: 

  =edit

The child grant is the exact opposite: it only applies to the children of the object on which it is defined. This can be usefull for public accounts in which you want a number of people to add and edit content, but you'd rather not that they can also edit or even delete the root directory under which all this content is kept. A child grant is set by prefixing the basic grant with a '>' sign. e.g:

  >edit

One common mistake is to assign the child grant '>add' to an object. This will make it impossible for the account to create children directly below that object, the add grant already implicitly affects only new objects created below a parent object.

Grant Modifiers

Grant modifiers enable you to even more closely control what a user can and cannot do. A grant modifier allows you to specify a grant only for a specific class of objects. You could assign the 'add' grant to an account with the modifiers set to 'ppage' and 'pdir', allowing the account only to add objects of these two classes.

It is important to note that modifiers don't use the class inheritance information. Even though the pnewspaper class is an extension of the pdir class, the account won't be able to create a newspaper. You will need to add a full list of classes for the given grant.

Grant modifiers can be specified by listing them between brackets after the basic grant. e.g: 

  add(pdir, ppage)

Grant modifiers can be mixed with grant types.

It is also possible to create your own templates, class or object, which check on modifiers that are not classes. It is beyond the scope of this document however.

Custom Grants

Sometimes the set of basic grants described above are not enough. Ariadne makes it very easy to define your own grants and check against them. 

The specific grant a user needs for a certain action is defined and checked against in each template. Class templates (PHP) define the grant needed with a CheckLogin() function. In object templates (PINP) the same can be done with the CheckGrant() function, but these always require at least the 'read' grant.

Once a template uses a grant identifier, that grant can be used exactly like the basic grants described above. One way to use this is to create a more role based access mechanism, without having to define numerous differen groups. E.g. by creating specific templates for an editorial staff which check against the grant 'editor'.