Permissions
To control access to functionality in Mercatum, extensive use should be made of permissions. A permission can be created that either grants or restricts access, chosen based on what the default behaviour should be for a user that is not logged in — a session that is not logged in will have no permissions at all.
Both users and accounts can have permissions assigned to them. When a user logs in to the site, their session will inherit the permissions directly from the user and also from their nominated default account. Should they change their account to another they are a member of, their active permissions will be recalculated to reflect those on the new account. Note that a session's permissions are only updated when the account changes, the user logs in/out, or the session goes idle and requires reauthenticating. This means that active sessions are not likely to immediately see the results of changes made to permissions using the administrator.
: permission is set
: permission is not set, either on this user or the selected account
: permission is not set directly on this user, but is inherited either from an account or because they are in a permission set that contains it
: permission is blocked, so this user will not have it regardless of which account they are in
Account permissions
As permissions assigned to an account are inherited by all users of that account, adding permissions to an account is a quick way of granting that permission to all users.
Individual permissions normally assigned to an account can be blocked on a user-by-user basis, either to prevent a user from further abusing functionality or to grant a user privileges that a large account might have restricted by default.
In the case of the latter, consider for example a list of products approved for purchase. For small accounts and the general public (i.e. sessions that are not logged in), it makes sense to allow anyone in the account to modify this list, and so default behaviour should be to allow access. However, for larger accounts with many users it may be prudent to only allow only a small number of account members access to this functionality. To accommodate this, a restrictive permission (e.g. named "restrict approved products") should be added to the account, and then blocked on the users that are allowed to modify the list.
In the administrator, this is achieved by repeatedly clicking the permission on the user until it appears as a . Figure 1 shows the possible modes for a permission. In the case of accounts only the first two, set and unset, are valid.
Permission sets
It is also possible to group together a number of permissions into a set. This set can be used to represent a role on the system to which additional permissions can be added later when new functionality is developed, without requiring the modification of every individual user who carries out that role.
Permission sets are represented as a multi-level hierarchy, so it is possible to create a new set and add an existing one to it. Any change to the original set will automatically be reflected in the new one. This allows you to create a modified version of a role with additional privileges, and assign it to multiple users quickly.
Permission sets cannot be added to accounts, only to users.
In the current version of Mercatum the sets cannot be modified through the administrator, and instead must be created in the database manually. This should change in the future, although only super-users will ever be able to modify them.
Individual entries in a permission set can be blocked on users in the same way as those inherited from accounts.
The Mercatum administrator permissions are themselves modelled as a permission set. Note that this set differs from other sets in that a user cannot grant/revoke permissions in it unless they themselves have that permission. This is to prevent an administrator from escalating their own administrative privileges. Other permissions are not hampered by this restriction as they are used to manage site functionality rather than system administration, and so are deemed to be less important.