Roles and Authorization

Contents

  1. Roles and Authorization
  2. Introduction
  3. Roles
    1. Role Types
    2. Detailed List of Roles
  4. User Roles
  5. Transaction Authorization
    1. Transaction Map
    2. Profiles
  6. Example Authorization
  7. Open Points

Introduction

This page describes how user roles and transaction authorization is implemented.

Roles

The types of roles are defined in the database in the Roles table.

Role Types

The following types of roles are defined:

Note that the former Management Roles (PM, LE, Assistants, Deputies, etc.) will be deleted. They attempted to define a project organization, which is unrelated to user roles and transaction authorization.

Detailed List of Roles

User Roles

A UserRole defines the authorization to perform operations, based on:

Transaction Authorization

The ability to run transactions is controlled by UserRole records. Two steps of authorization are performed:

  1. The ability to start a FSM or BT transaction is checked when it is instantiated by the finite state machine (in newBT and newFSM?). Given the following inputs: This is probably incomplete/incorrect

    • a Transaction Name (as defined in app/config/TransactionMap.php) or Transaction Class (a BT or FMS class name)

    • the userId from the global session

    • the current contractId and groupId from the global session

  2. In the transaction class, an additional test is made. The test varies depending on whether a new object is being created or updated/displayed:

    • For a new transaction the contractId (from the session) and groupId of the object (?) is used.

    • For a update and view transaction the contractId and groupId of the object is used.

For view transactions, additional checks based on the type of view may be performed that alter what is displayed.

Transaction Map

The transaction map is defined in app/config/TransactionMap.php

The transaction map is an associative array:

Example extract from the transaction map:

Profiles

The transaction profiles are defined in app/config/Profiles.php

The transaction profiles is a 2-dimensional matrix, defined as an associative array.

Note that, for some transaction names, there is a simply a 0 or 1 instead on an array, that indicates the transaction is allowed or disabled for all roles.

Example showing how the definition of view normal and restricted are defined:

Example Authorization

Scenario: A user wants to add a task note. They have the task view restricted role for the task in question.

  1. Dispatcher.php tries to instantiate the class CommentViewBT with a statement like the following: 

    •          $bt->FiniteStateMachineBase::newBT( "CommentViewBT" );

  2. FiniteStateMachineBase::newBT calls BusinessTransactionBase::newBT, which contains the following code: 

    •       ..
      $authorizer = Authorizer::get( .. );
      if ( ! $authorizer->isAuthorized( $className ) ) {
        .. transaction not authorized
      }
      .. transaction authorized

  3. Authorizer::isAuthorized performs the following check (note that $tranName can be an array): 

    •       ...
      $tranMap = new TransactionMap();
      $tranName = $tranMap->getTransactionName( $cmd );

      return $this->isTransactionAuthorized( $tranName, $userId, $contractId, $groupId );

Open Points

RolesAndAuthorization (last edited 2010-05-19 14:11:09 by 183-56-139)

Copyright 2008-2014, SoftXS GmbH, Switzerland