Tasks and Roles: Difference between revisions

From IHRIS Wiki
Line 41: Line 41:




=Permissions and the Permission Parser=
=Permisos y Analizador de Permisos=
The permission parser allows logical expressions to combine severals types permissions, such as ''task'', ''roles'', into a ''permission string''.
El analizador de permisos permite expresiones lógicas para combinar varios tipos de persmisos, tales como ''tarea'', ''roles'', en una ''cadena de permisos''.


We can assign tasks, roles and permissions to DOM nodes by:
Podemos asignar tareas, roles y permisos a los nodos DOM al:
*Setting the attribute ''role''.  <br/>If the values is X, this results in the permission string ''role(X)'' which is passed to the permission parser
*Establecer el atributo ''rol''.  <br/>Si el valor es X, esto resulta en la cadena de permiso ''rol(X)'' que se pasa al analizador de permisos
*Setting the attribute ''task''. <br/>If the values is X, this results in the permission string ''task(X)'' which is passed to the permission parser
*Establecer el atributo ''task''. <br/>Si el valor es X, esto resulta en la cadena de permiso  ''task(X)'' que se pasa al analizador de permisos
*Setting the attribute ''permission.''
*Establecer el atributo ''permiso.''
If the node fails any of the role, task or permission checks it will remove the node
Si el nodo falla cualquiera de las revisiones rol, tarea o permiso, eliminará el nodo


==Permission Types: task and role==
==Permission Types: task and role==

Revision as of 18:47, 28 September 2013

iHRIS utiliza un mecanismo de seguridad basado en Roles y Tareas para limitar el acceso a las diversas partes del sistema. A un usuario se le asigna un rol y un rol es un conjunto de tareas que ese rol puede realizar.

Este artículo describe como se definen los roles y tareas en Datos Magic y utilizados por el sistema iHRIS.

Roles

Un rol es una colección de tareas que pueden asignarse a la cuenta de un usuario.

  • los nombres de los roles se definen como los secundarios de ruta de magic data /I2CE/roles/names
  • un rol $role tiene un display definido en /I2CE/roles/names/$role/display_name
  • los roles pueden heredar tareas de otro al agregarlo como el valor de un nodo secundario de /I2CE/roles/names/$role/trickle_up
    Por ejemplo, en iHRIS Manage en el /I2CE/roles/names/hr_staff tenemos:
    • display_name => HR Staff
    • trickle_up => Array
      • 0 => admin
      • 1 => hr_manager

dice que el rol de hr_staff aparece como 'HR Staff' y que un hr_manager o admin tiene todas las tareas que tiene un hr_staff.

Tareas

Una tarea puede ser tanto una colección de sub-tareas que tiene esta tarea y la descripción de alguna acción cuyo permiso se puede verificar. La información de las tareas se guarda en datos magic bajo /I2CE/tasks/. Para crear una tarea se crea un nodo secundario de tipo escalar de /I2CE/tasks/task_description. El nombre del nodo es el nombre utilizado para referenciar la tarea. El valor del nodo es la descripción de la tarea que se muestra en la página de Manejo de Tareas y Roles. Por ejemplo, el nodo de magic data /I2CE/tasks/task_description puede verse así:

  • custom_report_admin => Permite la administración del Sistema de Informes Personalizados
  • custom_reports_can_access => Permite acceso mínimo al Sistema de Informes Personalizados
  • custom_reports_delete => Permite eliminación de datos acerca de los informes personalizados
  • custom_reports_can_access_relationships => Permite acceso a las Relaciones de Informes Personalizados

Puede definir la sub-tarea de una tarea $task al especificar /I2CE/tasks/task_trickle_down_task. Por ejemplo, el nodo de datos magic /I2CE/tasks/task_trickle_down/custom_reports_admin puede verse así:

  • 0 => custom_reports_can_access
  • 1 => custom_reports_delete_reports

lo que dice que la tarea de 'custom_report_admin' tiene todas las tareas y derechos definidos por 'custom_reports_can_access' y 'custom_reports_delete_reports.'

Las tareas que se asignan a un rol $role son los valores de los secundarios bajo /I2CE/tasks/role_trickle_down/$role

Un usuario con el rol 'admin' tiene todas las tareas.

Usos de las Tareas y Roles

Las tareas y roles se utilizan en varios lugares:

  • La clase principal I2CE_Page revisa los permisos básicos de la página.
  • Varias páginas revisan los roles específicos y las tareas en su método action().
  • Antes de mostrar el HTML la clase I2CE_Template, verifica que todas las tareas, roles y permisos esten satisfechos en cada nodo.

Task and Role Administration

For deployment across many computers, tasks and roles should be set up in an appropriate module configuration file.

For setting tasks and roles dynamically, the module 'tasks-roles' provides the page named 'roles' and the page named 'tasks' that allows creating new roles and tasks as well as defining the permission inheritance.


Permisos y Analizador de Permisos

El analizador de permisos permite expresiones lógicas para combinar varios tipos de persmisos, tales como tarea, roles, en una cadena de permisos.

Podemos asignar tareas, roles y permisos a los nodos DOM al:

  • Establecer el atributo rol.
    Si el valor es X, esto resulta en la cadena de permiso rol(X) que se pasa al analizador de permisos
  • Establecer el atributo task.
    Si el valor es X, esto resulta en la cadena de permiso task(X) que se pasa al analizador de permisos
  • Establecer el atributo permiso.

Si el nodo falla cualquiera de las revisiones rol, tarea o permiso, eliminará el nodo

Permission Types: task and role

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)

Permission Type: module

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:

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

Permission Type: form

The 'forms' module adds in the form type. The permission string with 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

A permission type (such as role, task, form or module) in a permission string behaves essentially like a function. 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). The permission parser turns [argM] into $argM according to the following rules:

  • if [argM] starts with a $ then it refers to template data and the following rules apply:
    • The string has the form $abcd. The value of $argM becomes the template display data with name 'abcd.'
    • The string has the form ${WXYZ}abcd. The value of $argM becomes the template data with category 'WXYZ' and with name 'abcd.'
  • <NODE> becomes the instance of DOMNode (if any) that the permission string was called on
  • <TEMPLATE> becomes the instance of I2CE_Template (if any) that the permission parser was called on
  • <USER> becomes the instance of I2CE_User that is this session
  • if [argM] starts with a single quote ' then it is a string until the next non-escaped ' is found
  • if [argM] starts with a double quote " then is is a string until the next non-escaped " is found.
    In addition the following substitution rules apply:
    • any substring starting with $ and consisting of alpha-numeric characters, - or _ is interpreted as template display data to be substituted
      For example "my name is $name" becomes "my name is Joe" if the template data named 'name' and with type DISPLAY is "Joe"
    • any substring starting with {$ is read until an enclosing } is found. The string between the ${ and } is the name of DISPLAY template data which is then substituted.
    • To prevent the above, { and $ may be escaped with a \
  • any other string of alpha-numeric characters (and a few permitted punctuation marks) is interpreted as a string

Arguments may be separated by a comma a space or a |.

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