Tasks and Roles

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.'

Permissions and the Permission Parser=

The permission parser allow logical expressions to combine three types of permissions, task, roles, and module. 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:

(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)

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

Module type permissions

Any function of a [[Technical Overview: Mo

Adding new permission types

A module can add in a [[[Technical Overview: Module Structure#Fuzzy Methods|fuzzy method]] of the form hasPermision_$type to the I2CE_PermissionParser class to enable a new permission type of the f

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.