User Management and Permissions Guide

Key points:

• Users and user groups are elements within the Users and Groups themes respectively.
• By default, there is a user called Administrator. This user is the repository administrator, has full privileges, and is responsible for creating any number of users and user groups required. You cannot delete the Administrator user, and you cannot restrict their permissions.

Note: The only other default user is the Anonymous user. This provides login free, but highly limited, access to a repository on the web. 

• By default, there are two user groups: Administrators and Everyone.
• The Administrator user implicitly belongs to the Administrators user group.
• All users (excluding the Anonymous user) implicitly belong to the Everyone user group.
• Element and library permissions are assigned to user groups, but can also be assigned to individual users if required.
• Users can belong to more than one user group.
• Users inherit their permissions from the user groups they belong to, but individual users can have permissions that override their user group permissions. Permissions are cumulative.

We recommend that you use user groups to establish levels of access, and then assign users to an appropriate user group.

The Users and Groups themes

Users and user groups are elements belonging to the Users and Groups themes respectively. You create new ones just like any other element in MooD.

Users elements have the following default fields:

• Default
• Windows Login Name. The Active Directory domain and user login name for use within Active Publisher.
• Home Page. Each user and user group can have a Home Page. This is the model displayed when a user logs into a repository by means of Active Enterprise. The model can be the user’s model, a specific element’s model, or the model associated with the user group that the user is a member of. For example:

Groups elements have the following default fields:

• Members. The users who are members of the user group, and therefore inherit its permissions. For example:

• Home Page. This functions the same for Users and Groups elements. See the previous Home Page description.

Types of permission

Before looking at the actual permissions, you should understand the three types of permission used in MooD, and how they interact.

• Element permissions

Apply to each element in a theme either individually or collectively by means of inheritance. Element permissions can be set by user group. This means that the same elements can have different permissions for different user groups. If necessary, element permissions can be also be set for individual users. These override any permissions attained through user group membership, but are in turn overridden by any library permissions.

• Library permissions

Grant management permissions previously exclusive to users in the Administrator user group to other user groups or users. Permissions are organized and granted by area (library), for example, Matrices, Queries, Synchronizations, and Users and Groups. This allows you to devolve management permissions without granting full Administrator user access. Again, if a user has specific library permissions, they take precedence over those attained by means of their user group membership.

Note: Individual Users elements cannot be given singular, across the board permission over an entire library. They can only have permissions for specific groups or items within a library. For example, queries can be organized into groups, with each group containing any number of individual queries. Users elements can be granted permission over individual queries or groups of queries, but not the entire Queries library itself. Only Groups elements can be given permission over an entire library category by means of a single permissions setting.

Library permissions also take precedence over any element permissions. For example, if a user belongs to one user group where editing of an element is denied, but also to one user group that has the power to manage matrices, then they will be able to edit that element’s matrices.

• Field permissions

Apply to fields in themes (and consequently elements). Field permissions control whether fields are visible and editable in Business Architect, or when published on the web using Active Enterprise or Web Publisher. 

If you'd like to read more about this matter, please click the attachment.