Managing User Privileges

 

Overview of the Trialex User Privileges

Security is an important topic especially in a multi-user environment such as the Trialex System.  As more users work on various projects, it is necessary to assign users different privileges so that users can collaborate without interfering with each other's work.  The Trialex System manages privileges for each object defined to the level design.    The objects in the level design are usually a study or a project.  The different kinds of privileges granted to a user for a particular object include:

  • Read - ability to view data, reports, programs and their attributes
  • Write - ability to edit and change the various objects within the specified study
  • Execute - ability to execute SAS programs within the specified study
  • Own - ability to grant other users privileges to the current study

Multiple users can have ownership privileges.  This implies that once the ownership is granted to a user, that user can grant or remove privileges to that specified object or study.  This is therefore a security model based upon trust among team members.  The ownership for a project or study is initiated by the first person to create the object during study creation or study copy.  This creator of the new study will have the ability to grant permission to others.

Viewing Existing Privileges

Viewers can view privileges to all objects defined to the Trialex System through the user privileges icon located in the administration tools area.

upriv.gif (1101 bytes)
User Privileges

The main user privileges screen looks like:

upriv1.jpg (51817 bytes)

This view shows all the objects including projects and studies which the current user named Bill Statis has access to.  In the event where the list becomes too long to fit on one page, the system will break up the list into blocks of ten items with navigational links such as shown here:

(1-10 of 20 objects) next>

When the user has many studies to mange, another way of navigating to a specific item is to use the Current Object pull down menu.  This will flip the current page to include the selected study if the user has permission to the selected study.  If the user does not have permission to the selected object, the following message will be prompted.

upriv2.jpg (12262 bytes)

In this event, it is recommended that the user click on the View button to the right of the current object.  This will display a list of users who have permission to the selected object as shown below.

upriv3.jpg (20481 bytes)

 

Updating Privileges

Users have the ability to update the objects which they own.  This is accomplished by selecting or deselecting the corresponding check boxes.

Read    Write     Execute     Own  

In the case where the user does not own the current object, the user does not have permission to update the privileges.   The view still displays the permissions but the check boxes are displayed in a non-editable format as shown below.

xRead     xWrite     xExecute        _Own 

Once the user has modified the privileges accordingly, the Update button must be clicked before the privileges are updated.  If the user clicks on the < Back button without first clicking on the Update button, no privileges will be updated.

Granting Privileges

Users must have ownership privileges before they are permitted to grant permissions to others.  This is accomplished either by the default condition of creating a new object or having privileges granted from another user.  The ability to grant privileges is indicated through a Grant button to the right of the permissions.

Read    Write     Execute     Own     

Once the user has clicked on the Grant button, the following dialog box appears:

upriv4.jpg (22902 bytes)

The information displayed in the Grant Privileges dialog box include:

  • Level - The current level of the selected object as defined in the level design
  • Name - The current name of the selected object
  • User - The current user name
  • Creator - The user name of the creator or the one that created this object in the level design
  • Privileges - The privileges to be granted.  Note that this is defaulted to the privileges the current user has.  If all permissions are deselected, this removes privileges for the designated user.
  • Grant to - A list of the users who will be granted the permissions. 

Once the OK button is clicked, the permissions will be granted and a list of what is applied will be shown.   An example may be:

NOTE: Privileges for:Study 2 has been updated for:bill.
NOTE: Privileges for:Study 2 has been updated for:stan.

Requesting Privileges

The Trialex System privileges are based on trust.  This means that users who have ownership permission can grant permissions to others users.  This is different than a centralized administrator who is responsible for granting all privileges.  The request for permissions is therefore directed toward those team members who have ownership of the object of interest. 

In order to request privileges, the first step is to select the desired object from the Current Object pull down menu. 

upriv5.jpg (31827 bytes)

Click on the View button to display all the users who have ownership permission to the selected object.   The user would then need to contact the owners and have them grant the desired permissions.

Administrator versus User Differences

Although the Trialex System's security model is based on trust, an administrator has the ability to set privileges to objects if it is needed.  This is intended to be used as a back up in the event that the users with ownership privileges are not available for administration. 

The main difference between the user's view of the privileges and the administrator's view is seen in the Current User view.   A non-administrator will see their name listed as shown here for Bill.

upriv6.jpg (11878 bytes)

An administrator will have a pull down selection list of all the users on the system as shown here.

upriv7.jpg (10240 bytes)

This means that the administrator can switch between users and act on behalf of the selected user.  This allows the administrator to grant privileges on objects that normally the administrator does not have permission to.  This is not the recommended method of managing privileges but it is a useful backup in the event that the owner is not available.

 
     Meta-Xceed Inc.© 2007