Tasks and Roles: Difference between revisions

From IHRIS Wiki
Line 56: Line 56:
==form type==
==form type==
The 'forms' module adds in the form type.  The permission string with [[#Arguments|arguments]:
The 'forms' module adds in the form type.  The permission string with [[#Arguments|arguments]:
  form('form_name', 'form_method', <arg1> , .., <argN>)
  form('form_name', 'form_method', [arg1] , .., [argN])
results in the call:
results in the call:
  $form->form_method($arg1,..,$argN)
  $form->form_method($arg1,..,$argN)

Revision as of 12:24, 13 March 2009

Roles

A role is a collection of tasks that can be assigned to a user's account.

  • role names are defined as the children of the magic data path /I2CE/roles/names
  • a role $role has a display name defined at /I2CE/roles/names/$role/display_name
  • roles can inherit tasks from one another by adding it as a value of a child node of /I2CE/toles/names/$role/trickle_up
    For example, in iHRIS Manage at the /I2CE/roles/names/hr_staff we have:
    • display_name => HR Staff
    • trickle_up => Array
      • 0 => admin
      • 1 => hr_manager

says that the role hr_staff is displayed as 'HR Staff' and that an hr_manager or admin has all the tasks that a hr_staff has.

Tasks

A task can be both a collection of sub-tasks that this task has and description of some action that can be checked for permission. Task information is stored in magic data under /I2CE/tasks/. To create a task you create a scalar type child node of /I2CE/tasks/task_description. That name node of the node is the name used to reference the task. The value of the node is the description of the task displayed in the Task and Role Management page. For example, the magic data node /I2CE/tasks/task_description may look something like:

  • custom_report_admin => Allows administration of the Custom Reporting System
  • custom_reports_can_access => Allows minimal access to the Custom Reporting System
  • custom_reports_delete => Allows deletion of data about custom reports
  • custom_reports_can_access_relationships => Allows access to the Custom Report Relationships

You can define the sub tasks of a task $task by specifying /I2CE/tasks/task_trickle_down_task. For example, the magic data node /I2CE/tasks/task_trickle_down/custom_reports_admin may look like:

  • 0 => custom_reports_can_access
  • 1 => custom_reports_delete_reports

which says that the 'custom_report_admin' task has all the tasks and rights defined by 'custom_reports_can_access' and 'custom_reports_delete_reports.'

The tasks that are assigned to a role $role are the values of the children under /I2CE/tasks/role_trickle_down/$role


A user with the role 'admin' has all tasks.

Permissions and the Permission Parser

The permission parser allows logical expressions to combine severals types permissions, such as task, roles, into a permission string.

We can assign tasks, roles and permissions to DOM nodes by:

  • Setting the attribute role.
    If the values is X, this results in the permission string role(X) which is passed to the permission parser
  • Setting the attribute task.
    If the values is X, this results in the permission string task(X) which is passed to the permission parser
  • Setting the attribute permission.

If the node fails any of the role, task or permission checks it will remove the node

Tasks and Role Types

The task and role type permissions are formed by surrounding a role name with role() or a task name with task(). For example, you can create the following permission string:

(task(can_edit_database_list_facility_type) & task(can_edit_database_list_fav_color) || role(admin)

By default, tasks and roles are 'OR'ed together so the following are all the same:

  • task(can_edit_database_list_facility_type) or task(can_edit_database_list_fav_color)
  • task(can_edit_database_list_facility_type) | task(can_edit_database_list_fav_color)
  • task(can_edit_database_list_facility_type) task(can_edit_database_list_fav_color)
  • task(can_edit_database_list_facility_type,can_edit_database_list_fav_color)
  • task(can_edit_database_list_facility_type can_edit_database_list_fav_color)
  • task(can_edit_database_list_facility_type|can_edit_database_list_fav_color)


Module type permissions

Any public function of a module class can be called by the permission parser. For example, suppose that the module 'my_module' has a method 'my_method()' then we can use as the permission string with [[#Arguments|arguments]:

module('my_module','my_method', [arg1], ... , [argN])

which would results in the call:

$module->my_method($arg1,..,$argN)

where $module is the instance of the module class for the module 'my_module.'

form type

The 'forms' module adds in the form type. The permission string with [[#Arguments|arguments]:

form('form_name', 'form_method', [arg1] , .., [argN])

results in the call:

$form->form_method($arg1,..,$argN)

where $form is the result of getting the form by the name of 'form_name' via template data for node (if there was any) the permission string was assigned to.

Arguments

Suppose that we have the general shape for a piece of a permission string:

type(<ARG1>,<ARG2>,...<ARGN>)

Then this results in the method call:

$permissionParsrer->hasPermission_$type($node,$args)

where $node is the DOMNode the permission string was called on and $args is the array($arg1,..$argN)

A permission type (such as role, task, form or module) in a permission string behaves essentially like a function suppose. T

New Types

A module can add in a fuzzy method of the form hasPermision_$type to the I2CE_PermissionParser class to enable a new permission type. For example the 'forms' module does this by adding in a new permission type 'form.'

Uses

The tasks and roles are used in several places:

  • The main [[Technical Overview: Pages and Templates#Page Logic|I2CE_Page] class checks for basic permission for the page.
  • Several pages perform checks for specific roles and tasks in their action() method.
  • Just before displaying the HTML the I2CE_Template, class verifies that all tasks, roles and permissions are satisfied on each node.

Task and Role Administration