17/Desarrollador:Roles

(Redirigido desde «Desarrollador:Roles»)
Saltar a: navegación, buscar


Los roles o papeles y los permisos aparecerán en Moodle 1.7 y estarán disponibles en la versión de desarrollo de Moodle.


Definiciones

Un rol es un identificador de estado de los usuarios en algún contexto. Por ejemplo, profesor, estudiante y moderador del foro son ejemplos de roles.

Una capacidad es una descripción de alguna característica particular de Moodle. Las capacidades son asociadas con roles. Por ejemplo, "mod/forum:replypost" es una capacidad.

Un permiso es algun valor que es asignado a una capacidad para un rol particular. Por ejemplo, permitir o prevenir.

Un contexto es un "espacio" in Moodle, tales como cursos, módulos de actividades, bloques, etc.

El sistema existente

Actualmente en Moodle, tenemos un sistema fijo de los roles es decir administrador primario, administradores, creador del curso, profesores editores, profesores no editores, estudiantes, e invitados. Para cada rol, la capacidad o las acciones que pueden realizar son fijas. Por ejemplo, el rol del estudiante permite al usuario enviar una asignación, pero no permite que el usuario observe/edite el trabajo de otros usuarios. Usando esta disposición nos limitamos a un sistema algo rígido de las capacidades para cada rol. Si deseamos, decir a un estudiante o a un grupo particular que puede marcar asignaciones en un curso particular, no puedemos hacer eso sin dar a estos usuarios privilegios del profesor.

Los nuevos roles y capacidades del sistema

Moodle 1.7

Los roles tienen dos funciones principales:

  1. define la lista de permisos - la definición de rol es global para todos los contextos, pero puede cambiarse en contextos locales
  2. reemplaza los antiguos métodos de matriculación - la asignación de roles en el contexto de un curso es similar a los antiguos procesos de matriculación.

El nuevo sistema permitirá a los usuarios autorizados definir un número arbitrario de roles (ej.: un profesor).

Un rol consiste en una lista de permisos para posibles acciones diferentes dentro de Moodle (ej.: borrar discusiones, añadir actividades,...).

Los roles pueden aplicarse a usuarios en un contexto (ej.: asignar a Fred como un profesor en un curso en particular).

Aquí están los posibles contextos, listados de los más generales a los más específicos.

  1. CONTEXT_SYSTEM -- el sitio entero
  2. CONTEXT_PERSONAL -- tú mismo
  3. CONTEXT_USER -- otro usuario
  4. CONTEXT_COURSECAT -- una categoría de un curso
  5. CONTEXT_COURSE -- un curso
  6. CONTEXT_GROUP -- un grupo
  7. CONTEXT_MODULE -- un módulo de actividad
  8. CONTEXT_BLOCK -- un bloque

Un usuario autorizado será capaz de asignar un número arbitrario de roles a cada usuario en cualquier contexto.

Las habilidades pueden tener los siguientes permisos:

  1. CAP_INHERIT
  2. CAP_ALLOW
  3. CAP_PREVENT
  4. CAP_PROHIBIT

Si no se define ningún permiso, entonces los permisos de las habilidades son inherentes desde un contexto que es más general que el actual contexto. Si definimos unos valores de permisos differentes para las mismas capacidades en diferentes contextos, decimos que estamos sobreescribiendo las capacidades en contextos más específicos.

Desde que las capacidades en cada rol puedan ser diferentes, podría haber conflicto en las capacidades. Esto se resuelve imponiendo la regla que la capacidad definida para un contexto más específico gane, a menos que una prohibición se encuentre en un contexto específico menor.

Por ejemplo, Mark tiene rol de estudiante a nivel de curso, el cual le permite escribir en un wiki. Pero Mark también tiene asignado el rol de Visitante en el módulo a nivel de contexto (para un wiki particular) el cuál le previene de escribir en el wiki (sólo lectura). Así mismo, para el wiki en particular, Mark no será capaz de escribir en el wiki desde que el contexto más específico gane.

Si ponemos una PROHIBICIÓN en una capacidad, esto significa que la capacidad no puede ser sobreescrita y SIEMPRE tendrá un permiso de prevención (negación). La prohibición siempre gana. Por ejemplo, Jeff tiene un rol de estudiante travieso que le prohibe de postear en cualquier foro (para el sitio global), pero se le ha asignado el perfil de facilitador en el "Foro de ciencias" en el curso de Ciencia y Matemática 101. Como la prohibición siempre gana, Jeff es incapaz de postear en en "Foro de Ciencias".

Permitir y prevenir se cancelarán el uno al otro si se ponen para las mismas capacidades en el mismo nivel de contexto. Si esto ocurre, nos referiremos al nivel de contexto anterior para determinar los permisos para la capacidad.

Puede sonar más complejo de lo que es en realidad en la práctica. El resultado es que el sistema puede ser lo suficientemente flexible para permitir muchas curiosas combinaciones de permisos.

Actualizando desde 1.6

Una mejora será proporcionada por la versión 1.7. Los roles existentes (admin, profesor, estudiante, etc), y las capacidades existentes serán conservados automáticamente. Esto se hace creando roles por defecto para los niveles del sitio/curso, y asignando los usuarios actuales a estos roles. Los roles por defecto tendrán capacidades por defecto asociadas a ellos, reflejando los que teníamos en la versión 1.6. Sin modificaciones, Moodle funcionará exactamente igual antes y después de la Actualización.

Administradores

A los usuarios Admin se les asignara el rol de admin por defecto en el contexto del sistema (sitio)

Creadores de Cursos

Este rol será asignado por defecto a usuarios Admin en el contexto de sitio o sistema.

Profesores

Los usuarios que eran profesores tendrán el rol de profesor (o no-corregir papel del profesor) en todos los cursos que eran profesores.

Estudiantes

Los usuarios que eran estudiantes tendrán el rol del estudiante por defecto en todos los cursos en los que eran estudiantes.

Invitados

Todavía habrá un solo usuario invitado sin rol por defecto en el nivel del sitio. Para cada curso que permita el acceso de invitados, el rol de invitado será asignado al usuario invitado para ese contexto del curso. El control de invitados para el curso será modificado a partir dos a tres opciones (los invitados necesitan siempre incorporar la clave de inscripción - con./desc.). Se comprueba que este ajuste ahora fuerza a los invitados a incorporar la clave.

Capacidades

Ésta será una lista comprensiva de capacidades (no está completa todavía). Es importante que los nombres de la capacidades sean únicos.

Capacidades de Nivel Central

Los nombres de las capacidades de la base de Moodle comienzan con “moodle/”. La palabra siguiente indica qué tipo de capacidad de la base es, y la ultima palabra es la capacidad real en si misma. Las capacidades para la base de Moodle se definen en lib/db/access.php

  1. moodle/legacy:guest - las capacidades heredadas se utilizan para los usuarios existentes de la transición al nuevo sistema de roles durante la actualizacion a Moodle 1.7
  2. moodle/legacy:student
  3. moodle/legacy:teacher
  4. moodle/legacy:editingteacher
  5. moodle/legacy:coursecreator
  6. moodle/legacy:admin
  7. moodle/site:doanything - capacidad especial, para los admins, si se setea, elimina el resto de los ajustes de capacidades
  8. moodle/site:config - aplicable en admin/index.php y config.php (se puede analizar más adelante) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()
  9. moodle/site:readallmessages - lee todos los mensajes e historicos
  10. moodle/site:approvecourse - aprueba cursos pendientes
  11. moodle/site:manageblocks - agrega/elimina/ edita bloques (en el contexto de sitio, cursos solo por ahora) : 1)_add_edit_controls moodleblock.class.php
  12. moodle/site:backup - puede crear una copia de seguridad del curso : 1)course/category.php 2)block_admin.php
  13. moodle/site:restore - puede recuperar en este contexto : 1)course/category.php 2)block_admin.php
  14. moodle/site:import - puede importar otros cursos en este contexto : 1)block_admin.php
  15. moodle/site:accessallgroups - puede acceder a todos los grupos sin importar en que grupo el usuario este
  16. moodle/site:accessdb - accede a la base de datos directamente
  17. moodle/site:viewfullnames - puede ver los nombres completos de otros usuarios
  18. moodle/site:viewparticipants - puede ver participantes
  19. moodle/site:viewreports - puede ver reportes de curso/sitio
  20. moodle/site:trustcontent - capacidad de utilizar la característica del trusttext y de puentear la limpieza en áreas específicas
  21. moodle/site:uploadusers - capacidad de cargar/actualizar usuarios desde archivos de texto; moodle/role: es necesario asignar la capacidad para inscribir en el curso
  22. moodle/blog:view - leer blogs (usable en contexto del sistema o del curso)
  23. moodle/blog:create - escribir los nuevos post del blog (usables en contexto del sistema solamente)
  24. moodle/blog:manageofficialtags - crear/eliminar las etiquetas oficiales del blog que otros pueden utilizar (usable en contexto del sistema solamente)
  25. moodle/blog:managepersonaltags - crear/eliminar las etiquetas oficiales del blog que otros pueden utilizar (usable en contexto del sistema solamente)
  26. moodle/blog:manageentries - corregir/eliminar todas las entradas del blog (usables en contexto del sistema solamente)
  27. moodle/course:setcurrentsection - marcar la sección del curso
  28. moodle/course:create - crear cursos : 1)course/edit.php 2)course/category.php 3)course/index.php
  29. moodle/course:delete - borrar cursos : 1)course/category.php
  30. moodle/course:update - actualizar seteos de cursos
  31. moodle/course:view - puede usar esto para buscar cursos
  32. moodle/course:viewparticipants - permite a un usuario ver la lista de participantes
  33. moodle/course:viewscales - ver escalas (ej. en una ventana de ayuda?) : 1)course/scales.php
  34. moodle/course:manageactivities - agregar/eliminar/editar actividades y recursos (no piense que tiene algún sentido de dividir éstos)
  35. moodle/course:managescales - agregar/eliminar/editar escalas, mover escalas arriba y abajo : 1)blocks/block_admin.php 2)course/scales.php
  36. moodle/course:managegroups - administrar grupos, agregar, modificar, borrar : 1)course/groups.php 2)course/group.php
  37. moodle/course:managefiles - administrar carpetas y archivos del curso.
  38. moodle/course:managequestions - administrar preguntas del curso.
  39. moodle/course:managemetacourse - administrar los cursos correspondientes a un metacurso.
  40. moodle/course:reset - permite resetear el curso
  41. moodle/course:useremail - puede usar la característica habilitar/deshabilitar e-mail
  42. moodle/course:visibility - ocultar/mostrar cursos : 1)course/category.php
  43. moodle/course:viewhiddencourses - puede ver cursos ocultos
  44. moodle/course:activityvisibility - ocultar/mostrar actividades de un curso
  45. moodle/course:viewhiddenactivities - puede ver actividades ocultas
  46. moodle/course:sectionvisibility - ocultar/mostrar secciones
  47. moodle/course:viewhiddensections - puede ver secciones ocultas
  48. moodle/course:viewcoursegrades - puede ver todas las calificaciones en el curso
  49. moodle/course:viewhiddenuserfields - puede ver todos los campos de usuario ocultos
  50. moodle/course:managegrades - administrar configuración de escalas/calificaciones en un curso
  51. moodle/category:create - crear categoría de cursos : 1)course/index.php
  52. moodle/category:delete - borrar categoría de cursos : 1)course/index.php
  53. moodle/category:update - actualizar configuraciones de categorías (ordenar y renombrar) actualmente esta es una capacidad del administrador : 1)course/category.php
  54. moodle/category:visibility - ocultar/mostrar categorías : 1)course/index.php
  55. moodle/user:viewusergrades - ver sus propias calificaciones o las de otros (dentro de un contexto especificado)
  56. moodle/user:create - crear usuarios : 1) user/edit.php
  57. moodle/user:delete - borrar usuarios : 1) admin/user.php

moodle/user:readuserblogs - leer entradas de blog.

  1. moodle/user:update - actualizar configuración de usuario : 1) user/edit.php
  2. moodle/user:viewdetails - ver detalles de identificación personal del usuario (ej. nombre, foto).
  3. moodle/user:viewhiddendetails - ver detalles de usuario marcados como "ocultos".
  4. moodle/calendar:manageownentries - crear/editar/borrar entradas de calendario propias.
  5. moodle/calendar:manageentries - crear/editar/borrar entradas de calendario.
  6. moodle/role:assign - asignar roles a usuarios.
  7. moodle/role:override - puede anular capacidades de un rol (dependiendo del contexto).
  8. moodle/role:manage - crear/editar/borrar roles, configurar permisos de capacidades para cada rol.
  9. moodle/role:unassignself - desasignarse uno mismo de sus roles.
  10. moodle/role:viewhiddenassigns - ver asignaciones de rol que han sido marcadas como ocultas.
  11. moodle/question:import - importar preguntas en un curso.
  12. moodle/question:export - exportar preguntas de un curso.
  13. moodle/question:managecategory - agregar/borrar/editar categorías de preguntas de un curso.
  14. moodle/question:manage - agregar/editar/borar una pregunta de un curso.

Capacidades de nivel de usuario

  1. moodle/user:readuserposts - lee los posts del usuario en la página del perfil
  2. moodle/user:readuserblogs - lee el blog del usuario en la página del perfil
  3. moodle/user:viewuseractivitiesreport-lee el informe de actividades de la página del perfil
  4. moodle/user:editprofile - edita el perfil (se usa normalmente en el contexto de usuario y en el de sistema: CONTEXT_USERID y CONTEXT_SYSTEM)

Capacidades de nivel de módulo

Las capacidades se cachean en una tabla de la base de datos cuando se instala o actualiza un módulo. Cuando haya pasado esto, la versión del módulo se modificará para que también se pueda actualizar la tabla de base de datos.

El convenio de nombre que se ha especificado para los módulos y los bloques es 'mod/mod_name:capacidad'. La parte anterior a los dos puntos es la ruta completa del módulo en el código de Moodle. La capacidad de los módulos están definidas en mod/mod_name/db/access.php

  1. Tarea
    1. mod/assignment:view- lee la descripción de la tarea
    2. mod/assignment:submit - permite enviar la tarea
    3. mod/assignment:grade - evalua y lista las tareas enviadas
  2. Chat
    1. mod/chat:chat - permite a los usuarios participar en este chat
    2. mod/chat:readlog - permite a los usuarios leer los registros de sesiones de chats anteriores
    3. mod/chat:deletelog - permite a los usuarios borrar los registors de chats anteriores
  3. Consulta
    1. mod/choice:choose - hace una consulta
    2. mod/choice:readresponses - lee todas las respuestas
    3. mod/choice:deleteresponses - elimina todas las respuestas
    4. mod/choice:downloadresponses - permite descargar las respuestas
  4. Base de datos
    1. mod/data:viewentry - lee las entradas de otras personas
    2. mod/data:writeentry - permite añadir, editar y borrar sus propias entradas (del usuario)
    3. mod/data:managetemplates - añade, borra y edita campos y plantillas
    4. mod/data:manageentries - añade/borra todas las entradas
    5. mod/data:comment - permite hacer comentarios
    6. mod/data:managecomments - editar/borrar todos los comentarios
    7. mod/data:rate - evalua una entrada
    8. mod/data:viewrating - muestras las evaluaciones de las entradas
    9. mod/data:approve - aprueba una entrada
    10. mod/data:uploadentries - batch upload of entries
  5. Exercise
    1. mod/exercise:assess
  6. Foro
    1. mod/forum:viewdiscussion
    2. mod/forum:viewdiscussionsfromallgroups
    3. mod/forum:viewhiddentimedposts
    4. mod/forum:startdiscussion
    5. mod/forum:replypost
    6. mod/forum:viewrating
    7. mod/forum:viewanyrating
    8. mod/forum:rate
    9. mod/forum:createattachment
    10. mod/forum:deleteownpost
    11. mod/forum:deleteanypost
    12. mod/forum:splitdiscussions
    13. mod/forum:movediscussions
    14. mod/forum:editanypost
    15. mod/forum:viewqandawithoutposting
    16. mod/forum:viewsubscribers
    17. mod/forum:managesubscriptions
    18. mod/forum:throttlingapplies
  7. Glosario
    1. mod/glossary:write - añade entradas
    2. mod/glossary:manageentries - añade, edita y borra entradas
    3. mod/glossary:managecategories - crea, elimina y edita categorías
    4. mod/glossary:comment - comentar una entrada
    5. mod/glossary:managecomments - edita y borra comentarios
    6. mod/glossary:import - importa glosarios
    7. mod/glossary:export - exporta glosarios
    8. mod/glossary:approve - aprueba glosarios
    9. mod/glossary:rate - califica glosarios
    10. mod/glossary:viewrating - permite ver calificaciones
  8. Hotpot
    1. mod/hotpot:attempt - realiza un intento en hotpot
    2. mod/hotpot:viewreport - muestra y revisa los informes
    3. mod/hotpot:grade - evalua el hotmpot
    4. mod/hotpot:deleteattempt - elimina los intentos
  9. Etiqueta
    1. none
  10. Lams
    1. mod/lams:participate - estudiante original
    2. mod/lams:manage - profesor original
  11. Lección
    1. mod/lesson:edit - añade y edita páginas
    2. mod/lesson:manage - permite ver los intentos de los estudiantes
  12. Cuestionario
    1. mod/quiz:grade - permite comentarios, actualizar calificación y calificación manual
    2. mod/quiz:preview - previsualiza el cuestionario
    3. mod/quiz:viewreports - permite ver el informe de los resultados del cuestionario
    4. mod/quiz:manage - añadir/borrar/mover (hacia arriba o abajo) preguntas en un cuestionario
    5. mod/quiz:attempt - realizar un intento en el cuestionario--Tim Hunt
  13. Recurso
  14. Scorm
    1. mod/scorm:viewgrades
  15. Encuesta
    1. mod/survey:download - descarga los resultados de la encuesta
    2. mod/survey:participate - permite ver los participantes que hacen la encuesta
    3. mod/survey:readresponses - permite leer las respuestas de todos los usuarios
  16. Wiki
    1. mod/wiki:participate - estudiante original, su significado depende del tipo y la configuración del curso
    2. mod/wiki:manage - profesor original, que controla la asignación de grupos; se necesita moodle/site:accessallgroups para controlar todos los grupos
    3. (En espera del nuevo wiki)
  17. Taller
    1. mod/workshop:participate - estudiante original, permite al usuario ejecutar y evaluar el taller
    2. mod/workshop:manage - profesor original, usuario que puede controlar a los otros
    3. (En espera del nuevo taller)

Capacidades de nivel de Matriculación

La convención de los nombres para las capacidades específicas de matriculación es 'enrol/nombre_matriculacion:capacidad'. Éstas se definen en enrol/enrol_name/db/access.php.

  1. Acceso al pago por Authorize.net
    1. enrol/authorize:managepayments - maneja los pagos de los usuarios, las anulaciones, los reembolsos, los borrados, etc.

Bloques

  1. activity_modules
    1. None
  2. admin
  3. admin_2
  4. admin_bookmarks
  5. blog_menu
  6. blog_tags
  7. calendar_month
  8. calendar_upcoming
  9. course_list
  10. course_summary
  11. glossary_random
  12. html
  13. loancalc
  14. login
  15. messages
  16. news_items
  17. online_users
  18. participants
  19. quiz_results
  20. recent_activity
  21. rss_client
    1. block/rss_client:createprivatefeeds
    2. block/rss_client:createsharedfeeds
    3. block/rss_client:manageownfeeds
    4. block/rss_client:manageanyfeeds
  22. search
  23. search_forums
  24. section_links
  25. site_main_menu
  26. social_activities

Questions

I am adding question categories here because they seem to have been forgotten in the whole scheme of things since having been removed from the quiz module itself. I've made a suggestion on how these could be handled in bug 6118.

See this forum thread for a discussion about the current problems wth publishing question categories.Tim Hunt 18:50, 8 August 2006 (WST)

Interfaz de Programación

Aunque el sistema de roles parece complicado a simple vista, su implementación en Moodle es muy simple.

  • Primero hay que definir cada capacidad, para que Moodle pueda mejorar los roles existentes se aprovechen de esto. Esto se hace en el fichero access.php que está dentro del directorio db de cada módulo (como por ejemplo mod/forum/db/access.php). El vector tiene la siguiente estructura (cuidado con la descripción de la herencia del rol):
   'mod/forum:viewforum' => array(
       'captype' => 'read',
       'contextlevel' => CONTEXT_MODULE,
       'legacy' => array(
           'guest' => CAP_PREVENT,
           'student' => CAP_ALLOW,
           'teacher' => CAP_ALLOW,
           'editingteacher' => CAP_ALLOW,
           'coursecreator' => CAP_ALLOW,
           'admin' => CAP_ALLOW
       )
   ),

En donde: captype = tipo de capacidad; contextlevel = nivel de contexto; legacy = herencia; guest = invitado; student = estudiante; teacher = profesor; editingteacher = profesor con derechos de edición; coursecreator = creador de cursos; admin = administrador.

  • Para cargar o cambiar esas capacidad es necesario cambiar la versión del módulo. No es necesario proporcionar los cambios o las diferencias, ya que Moodle examinará el vector y lo ordenará.
  • Tienes que encontrar el contexto con el que está trabajando el usuario para cada página, que se hace usando la función get_context_instance(). Por ejemplo, en el módulo del foro:
 $context = get_context_instance(CONTEXT_MODULE, $cm->id);
  • Entonces, en donde quieras ver si el usuario actual tiene privilegios para hacer algo, sólo hay que llamar a has_capability() de esta forma:
   if (!has_capability('mod/forum:viewforum', $context)) {
       print_error('nopermissiontoviewforum');
   }
  • Si lo que quieres es imponer una capacidad y finalizar con un mensaje de error en el caso que el usuario no tenga permisos, entonces lo más sencillo es usar la función require_capability():
   require_capability('mod/forum:viewforum', $context);
  • Observa que se pueden añadir parámetros extra para personalizar el mensaje de error, de lo contrario los usuarios recibirán por defecto el mensaje "Sin permisos" que lista los permisos que le faltan al usuario.

Como resultado del nuevo sistema de roles, todas las llamadas a las funciones isadmin(), iscoursecreator(), isteacheredit(), isteacher(), isstudent(), y isguest() se reemplazarán por llamadas a las funciones has_capability() o require_capability(). Sin embargo, estas funciones se conservarán por compatibilidad con código antiguo, que realmente usará la herencia de capacidades para ver si se puede hacer la acción deseada.

Metacourses

The behaviour of metacourses in Moodle 1.7 changed slightly, in that where it used to just synch students from child courses to the parent course, it will now synch ALL roles. Teachers etc of the child courses will have the same role in the meta course. Technically metacourse synchronises all role assignments in CONTEXT_COURSE with its child courses; the only exception are users with moodle/course:managemetacourse capability, these users are synchronized only upwards, they are not unenrolled from metacourse when unenroling from child course or when removing the child from metacourse.

In order to import/enrol other courses into metacoure you need to have moodle/course:managemetacourse capability. You can add manually only participants with moodle/course:managemetacourse, all other participants are automatically synced with child courses - if you try to manually enrol user without this capability error is displayed. Similar error is shown also when you try to manually unenrol participant from meta course while still being enrolled in child course.

Sample setup:

  • metacourse manager has been assigned role with moodle/course:managemetacourse capability in system or course category context
  • students are enrolled in several child courses
  • teachers are enrolled in separate child course(s)


Problem areas we are working on

Student view

The "Student view" button has been removed completely.

If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.

Teacher forum

Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.

We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.

Enrolment plugins

Process of logging in

  1. load_user_capability() is called to load all the capabilities
  2. check_enrolment_plugins() is called at the top of load_user_capability() to check all the enrolment plugins.
  3. For each active plugin:
    1. Check for setup_enrolments($user) and run it. This function will do all the processing needed to assign or unassign roles from the current user.
  4. load_user_capability() continues and loads up all the roles
  5. load_defaultuser_role() is called to add default site permissions (all users)

Process of checking access to a course

require_login($course->id) is called by the script and has logic like this:

  1. Is the user a guest at site level?
    1. Yes: Does the course allow guests?
      1. Yes: return true (and further capabilities are checked by the script)
      2. No: send the user to course/enrol.php for enrolment
    2. No: continue below
  1. Does the user have moodle/course:view in that (course) context?
    1. Yes: then they can enter (and further capabilities are checked by the script)
    2. No: is guest access allowed on the course?
      1. Yes: assign temporary guest role to that user for that context (in session cache).
      2. No: send the user to course/enrol.php for enrolment.

Process of enrolling

(more soon)

Scenario brainstorming

This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.

Student

Obviously.

Site Designers

Is there a role for people involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.

Educational Authority Adviser

Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.

Educational Inspector

Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.

Second Marker / Moderator

A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.

Peer observer of teaching

Many institutions encourage peer observation of teaching, to encourage reflection on practice. In online environments this will be similar to moderation or inspection. The peer observer would need to be able to experience the course "as a student", but also to be able to view summaries of usage, transcripts of interactions (forums/surveys/polls etc), grades assigned (e.g. in assignments).

External Examiner

Has all the rights of inspectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.

Padres

Un padre tendrá unos o más niños en unas o más instituciones que podrían utilizar unos o más servidores Moodle o una mezcla de plataformas de aprendizaje. El papel de un padre variará dependiendo de la edad de sus niños y si está contribuyendo como un padre o colaborador de la escuela.

In Early Years (EY=3+4 yr olds) and Key Stage 1 (KS1=5+6 yr olds) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary. In Key Stage 2 (KS2=7-11 yr olds) parents would be more monitoring but may join in as well.

In Key stages 3 (KS3=12-14 yr olds) and 4 (KS4=15+16 yr olds) this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.

In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments. Also in all Key Satges there may be a home-school agreement which may be signed up to. Could this form part of a site policy system that incorporates a tickable list of activities the parent agrees to the child using (blogs/wikis/forums etc.)?

Parent's evenings often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.

In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face.

The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.

In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.

Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.

There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.

Manager

Please add text here...

Weekly Seminar Leader

In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.

Mentor/Mentee

Please add text here...

Community-Designed Rating Criteria

The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?

Visitor

This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.

Guest Speaker

This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have "guest speakers" who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.

Former Student

This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?

===Alumnus=== An ALUMNUS should be able to search for all other ALUMNI of the school, interact with them and be enrolled in a seperate course - which is like a META course with all the content of his learning and interaction - as well as capabilities to be a part of this ALUMNI only course. All the teachers of courses during school years should automatically be a part of the ALUMNI course .. which means when an ALUMNUS is enrolled in a course, the original teachers of all his courses get enrolled ? --Anil Sharma 20:54, 15 July 2006 (WST)

Librarian

Reference Librarians have an active role in most of the courses taught at some schools such as Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.

In schools there is often a book review system. This may be covered by the lending system database but may not in which case a librarian may neeed to have a course area they can create a database template to handle the reviews in which case they may have a normal teacher style role? Off topic but course an integration with common schools database systems would be great.

Teacher

Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.

I think that what is needed is a simple heirarchy of permissions and levels of granularity.

I would take issue with "teachers should have read access to other teacher's courses unless explicitly prohibited." This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--N Hansen 19:54, 12 June 2006 (WST)

Community Education Tutors/Trainers

Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.

Secretary/Student Worker

We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.

Teaching Assistant

Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker

Student - FERPA rights

A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name in any public place. Could include this student only being seen with an "alias" within course spaces. Is this an attribute rather than a role?

Help Desk

Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy of inheritance is needed, full access will be problematic with FERPA.

Admin - Catgory based

Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.

Process Roles

organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:

  • Give a student the role of forum-moderator with edit and chunk-rights
  • Give students different roles & rights in a Webquest design (and change these roles next week
  • Give students different resources, depending of their roles in a rolegame/simulation
  • Give a student the rights to create the section content of next week (and only that week..)

Things to finish for 1.7 Beta

18 Sept 2006

  1. Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]
  2. Address function: isteacher, isadmin, isstudent [Yu]
  3. Remove "view" capabilities from all modules unless required [Vy]
  4. Remove all old references from remaining Blocks [Vy]
  5. Metacourses [Skodak]
  6. Add risks to GUI[Skodak]
  7. Enrolment plugins [Martin and Alastair]
  8. Development:Stats_roles_1.7 [Penny]
  9. Fix Loginas
  10. Add category-level assigns [Yu]
  11. Development:Backup_roles_1.7 [Eloy?]

Proposal for interface enhancement

Martin asked some questions, here are my answers. The sketches below are not worked out proposals. Their task is to visualize the idea. The exact colours and functionality may be defined after possible agreement about the proposals. The Green, orange and red columns support the meaning of the options from "allow" to "prohibit" (If you may want to see larger images please click onto the image or the "Enlarge" icon below the image.)

The list of possible settings is very long and "... the problem is not to overwhelm people with information" .

01 moodle define roles structured.png

1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful different coloured columns and clear sections.

02 moodle define roles collapsed.png

2) A second proposal is to reduce the amount of information the user is shown at the same time. The YUI interface library offers great support to show/hide sections of the page by clicking on specific elements.

For example click on an icon beside the sub heading "Course categories" and show/hide all table rows with the CLASS "course-category".

03 moodle define roles tooltip.png

3) "The main problem is the last column for risk ... we were thinking of putting little icons in there ..." Icons are good when they tell the user more about possible actions/meanings then the letters. I am not sure if this is the case here. For both - icons or letters - the YUI tool-tip function would be able to give the user valuable information about the meaning.

See also