Except for the home page and the Library, users require a user name and password (6 digit mixed case and mixed alphanumeric) to gain access to functionality.

Once logged in, the framework limits access to functionality through what is exposed to a user and what actions the user is permitted to perform on what is exposed.

Visibility

The framework manipulates the visibility of applications and nodes of the content directory on the basis of the role(s) that have been assigned to them by their system administrator(s).

The visibility of individual records are determined by the position of the user's organisation in the organisation hierarchy in a way that records are visible within the record owner's organisation as well as any organisation lower down in the organisation hierarchy.  This is done by way of adjusting the root of the organisation dimension in the filtering mechanism. 

This model can accommodate several hierarchies but each additional hierarchy increases the maintenance overhead.   Examples of hierarchies could include:

      Government entities such as national government, provincial government, metropolitan, district and local municipalities.

      Programme entities such as NMMU, PMMU and PMU.

Note:  There are exceptions (such as gazetted allocations) where visibility is not restricted.

Permitted Actions

The actions that a user is permitted to perform on a visible record depend on the role(s) assigned to the user by his/her system administrator(s), the permissions associated with such role(s), the devolution option of municipality and the current workflow status associated with the record.

In addition to record level permissions, the model also caters for field level permissions linked to workflow status.  The project budget section may for example be changed until the registration has been signed off by the SMM.  Thereafter it can only be changed by means of an addendum that goes through the same approval process.