Desenvolvimento: Funções

'Funções e permissões' está em Moodle 1,7 onwards.

Definições

Um papel é um identificador do utilizador do estado em alguns contexto. Por exemplo: Teacher, Fórum Estudante e moderador são exemplos de papéis.

A capacidade é uma descrição de alguma característica particular Moodle. Capacidades estão associadas a papéis. Por exemplo,mod / forum: replyposté uma potencialidade.

A permissão é algum valor que é atribuído para uma capacidade de um determinado papel. Por exemplo, permitir ou impedir.

Um contexto é um "espaço" no Moodle, tais como cursos, atividades módulos, blocos etc

O sistema existente

Em versões anteriores à v1.7, Moodle utiliza um determinado conjunto de papéis ou seja primário admin, administradores, naturalmente criadores, editando professores, não de edição de professores, alunos e convidados. Para cada função, a capacidade ou ações que eles podem executar são fixos. Por exemplo, o papel aluno permite ao usuário enviar uma missão, mas não permite ao utilizador navegar / editar outros utilizadores de trabalho. Ao usar esta configuração, limitar-nos a uma visão bastante rígida conjunto de capacidades para cada papel. Se queremos, digamos um determinado aluno ou grupo para poder marcar atribuições de um determinado curso, não podemos fazê-lo sem dar esses usuários professor privilégios.

Os novos papéis e as capacidades sistema

Com v1.7 e superior, Moodle introduz um sistema de papéis e as capacidades.

Papel tem duas funções principais:

Define lista de permissões - papel definição é global para todos os contextos, mas pode ser alterado pelo contexto local que sobrepõe
Substituir antigas curso matrículas - papel cessão em curso contexto é semelhante à antiga inscrição processo

O novo sistema permitirá que os usuários autorizados para definir um número arbitrário de papéis (por exemplo, um professor)

Um papel consiste de uma lista de permissões para diferentes acções possíveis dentro Moodle (por exemplo, apagar discussões, adicionar atividades etc)

Funções podem ser aplicados para os usuários em um contexto (por exemplo, atribuir Fred como professor em um determinado curso)

Aqui estão os possíveis contextos, listados do mais geral ao mais específico.

CONTEXT_SYSTEM - todo o site
CONTEXT_USER - outro usuário
CONTEXT_COURSECAT - um curso categoria
CONTEXT_COURSE - um curso
CONTEXT_MODULE - uma actividade módulo
CONTEXT_BLOCK - um bloco

Observe que CONTEXT_PERSONAL (presente em 1,7-1,8) nunca foi implementado e foi removido em 1,9. CONTEXT_GROUP também não é aplicado e não pode ser utilizado.

[[Imagem: Moodle-contextos-1.8.png | direito | polegar | Um diagrama dos contextos em Moodle 1,8, baseado no texto diagrama por Martin Dougiamas. Clique no mapa para ver uma visão mais detalhada do mesmo.]]

Um usuário autorizado será capaz de atribuir um número arbitrário de papéis para cada usuário, em qualquer contexto.

Capacidades podem ter as seguintes permissões:

CAP_INHERIT
CAP_ALLOW
CAP_PREVENT
CAP_PROHIBIT

Se nenhuma permissão está definida e, em seguida, a capacidade permissão é herdado de um contexto que seja mais geral do que o actual contexto. Se conseguirmos definir permissão valores diferentes para a mesma capacidade em contextos diferentes, dizemos que somos superiores à capacidade no contexto mais específico.

Uma vez que as capacidades de cada um papel poderia ser diferente, poderia haver conflito no capacidades. Esta é resolvida pela aplicação da regra de que a capacidade definida para um contexto mais específico irá vencer, a menos que um proibir seja encontrada num contexto menos específicas.

Por exemplo, Mark tem um aluno no curso papel nível, o que lhe permite escrever em um wiki. Mas Mark também got atribuído um papel ao visitante um módulo contexto nível (de um determinado wiki), que o impeça de escrever para o wiki (somente leitura). Portanto, para este particular wiki, Mark, não será capaz de escrever para o wiki mais uma vez que o contexto específico vitórias.

Se conseguirmos definir um proibir sobre uma capacidade, isso significa que a capacidade não pode ser ultrapassada e SEMPRE vai ter uma permissão de impedir (negar). Proibir sempre vence. Por exemplo, Jeff tem uma naughty estudante papel que lhe proíbe, em qualquer das anteriores fóruns (para todo o site), mas ele é também atribuído um papel facilitador no "Fórum Ciência" no curso Ciências e Matemática 101. Desde sempre proibir vitórias, Jeff não pode postar no "Fórum Ciência".

Permitir e prevenir cancelará se uns aos outros para fora fixado para a mesma capacidade no mesmo contexto nível. Se isso acontecer, nos referimos ao nível precedente contexto para determinar a permissão para que a capacidade.

Isto pode soar mais complexo do que é realmente na prática. O resultado é que o sistema pode ser suficientemente flexível para permitir que praticamente qualquer combinação de permissões.

Capability-localização mudanças na v1.9

Ao resolver os conflitos entre a "permitir" e "prevenir", em v1.7 e v1.8 a localização da capacidade é tida em conta, embora com menos peso do que a localização do papel cessão. Na v1.9 o processo foi simplificado, que consideramos localização do papel cessão quando se tratar de permitir / impedir conflitos, mas ignorar que a capacidade foi definida (desde que ela se aplica ao contexto).

Por exemplo - para a situação em que há

Dois papéis atribuídos a um usuário em um contexto (por exemplo, aluno e professor papel papel)
Um sobrepor sobre um desses papéis (por exemplo, papel aluno), no mesmo contexto

Então

1 .7/1.8 'O override utilizados para sempre'conquistar as definições do combinado papéis.

.91 'A override é combinado com o aluno papel primeiro. E, em seguida, as funções são combinadas. Esta é mais lógico, uma vez que o substituirá é agindo como uma modificação do papel do aluno.

Para mais detalhes, ver [https://tracker.moodle.org/browse/MDL-11218 MDL-11218]

Atualizando de 1,6

Um bom atualização será fornecida com 1,7. Os papéis existentes (admin, professores, estudantes, etc), e as capacidades existentes serão automaticamente guardadas. Isto é feito através da criação padrão papéis no site / curso níveis, e atribuindo a actual usuários para essas funções em conformidade. O padrão papéis terão padrão capacidades que lhes estão associadas, espelhando o que temos em 1,6. Sem modificações, Moodle funcionará exactamente o mesmo antes e depois da atualização.

Administradores === ===

Admin usuários será atribuído o padrão legado admin papel no sistema (site) contexto

Curso Criadores === ===

Curso Criadores será atribuído o padrão legado curso criador papel no sistema (site) contexto

Professores === ===

Os usuários que foram professores será atribuído o padrão legado professor papel (ou não-edição professor papel), em todos os cursos eram professores.

Estudantes === ===

Os usuários que foram alunos será atribuído o padrão estudante papel em todos os cursos eram aluno.

Convidados === ===

Ainda haverá um único hóspede usuário com nenhum padrão papel no nível local. Para cada curso, que permite o acesso hóspede, o hóspede papel será atribuído ao hóspede usuário para o referido curso contexto. O convidado para controlar o curso será modificado de três para duas opções (hóspedes sempre necessário digitar inscrição chave - on / off). Esta definição está marcada como agora para forçar convidados a entrar chave.

Capacidades

Esta será uma lista exaustiva das capacidades (não é completa até o momento). É importante que a capacidade nomes são únicos.

Core-level Capacidades

Moodle núcleo capacidade nomes começam com "moodle / '. A próxima palavra indica que tipo de núcleo capacidade é, a última palavra é a real capacidade própria. Os recursos para o Moodle núcleo são definidas em lib / db / access.php

Moodle / legado de hóspedes - legado capacidades são usados para usuários existentes transição para o novo sistema de papéis durante a actualização de 1,7 Moodle
Moodle / legado: estudante
Moodle / legado: professor
Moodle / legado: editingteacher
Moodle / legado: coursecreator
Moodle / legado: admin
Moodle / site: doanything - capacidade especial, significava para administradores, se for definido, que sobrepõe todas as outras configurações de capacidade
Moodle / site: config - aplicável em admin / index.php e config.php (pode quebrar mais tarde): 1) admin / config.php 2) admin / configure.php 3) blocos / admin / block_admin.php load_content_for_site ( )
Moodle / site: readallmessages - ler todas as mensagens e história
Moodle / site: approvecourse - aprovar um curso pendentes
Moodle / site: manageblocks - adicionando / removendo / edição blocos (site, evidentemente contextos só por agora): 1) _add_edit_controls moodleblock.class.php
Moodle / site: backup - pode criar um ciclo de backup: 1) curso / category.php 2) block_admin.php
Moodle / site: restaurar - pode restaurar neste contexto: 1) curso / category.php 2) block_admin.php
Moodle / site: importação - pode importar outros cursos neste contexto: 1) block_admin.php
Moodle / site: accessallgroups - poder aceder a todos os grupos independentemente do grupo que o usuário está em
Moodle / site: accessdb - directamente acessando db (phpmyadmin)
Moodle / site: viewfullnames - capazes de ver fullnames de outros usuários
Moodle / site: viewparticipants - capaz de ver participantes
Moodle / site: viewreports - capaz de ver site / curso relatórios
Moodle / site: trustcontent - capacidade de utilização trusttext recurso bypass e limpeza em áreas específicas
Moodle / site: uploadusers - capacidade de upload / atualizar os usuários de arquivo texto; moodle / papel: é necessário atribuir capacidade para curso inscrição
Moodle / blog: ver - ler blogs (utilizável no sistema ou curso contexto)
Moodle / blog: criar - escrever novos posts (utilizável no sistema contexto apenas)
Moodle / blog: manageofficialtags - criar / apagar blog oficial tags que outros possam usar (utilizável no sistema contexto apenas)
Moodle / blog: managepersonaltags - delete blog pessoal tags que outros possam usar (utilizável no sistema contexto só) Observação: os usuários podem sempre adicionar tags próprio pessoal. Esta definição deve ser desligado para estudantes por omissão.
Moodle / blog: manageentries - editar / apagar todas as entradas blog (utilizável no sistema contexto apenas)
Moodle / curso: setcurrentsection - marca curso secção
Moodle / claro: criar - criar cursos: 1) curso / edit.php 2) curso / category.php 3) curso / index.php
Moodle / curso: apagar - criar cursos: 1) curso / category.php
Moodle / curso: update - update curso configurações
Moodle / curso: ver - pode usar esse recurso para encontrar participantes
Moodle / curso: viewparticipants - permite ao utilizador visualizar participante lista
Moodle / curso: viewscales - ver tabelas (ou seja, em uma janela de ajuda?): 1) curso / scales.php
Moodle / curso: manageactivities - adicionando / removendo / edição actividades e recursos (não acho que ele faz qualquer sentido dividir essas)
Moodle / curso: managescales - acrescentar, apagar, editar escalas, escalas mover para cima e para baixo: 1) blocos / block_admin.php 2) curso / scales.php
Moodle / curso: managegroups - gerenciamento de grupos, adicionar, editar, excluir: 1) curso / groups.php 2) curso / group.php
Moodle / curso: managefiles - gerir curso arquivos e pastas
Moodle / curso: managequestions - gerir curso perguntas
Moodle / curso: managemetacourse - gerir criança cursos em metacourse
Moodle / curso: reset - capaz de repor o curso
Moodle / curso: useremail - Posso usar a ativar / desativar email stuff
Moodle / curso: visibilidade - esconder / mostrar cursos: 1) curso / category.php
Moodle / curso: viewhiddencourses - veja escondido cursos
Moodle / curso: activityvisibility - esconder / mostrar atividades dentro de um curso
Moodle / curso: viewhiddenactivities - capazes de ver actividades que têm sido escondidos
Moodle / curso: sectionvisibility - esconder / mostrar seções
Moodle / curso: viewhiddensections - vista oculto seções
Moodle / curso: viewcoursegrades - vistas todos os graus em curso
Moodle / curso: viewhiddenuserfields - visualizar todos os campos ocultos usuário
Moodle / curso: managegrades - gere graus definições em curso
Moodle / categoria: criar - criar categoria: 1) curso / index.php
Moodle / categoria: apagar - delete categoria: 1) curso / index.php
Moodle / categoria: update - update categoria configurações (espécie e renomear), este é actualmente um administrador capacidade de: 1) curso / category.php
Moodle / categoria: visibilidade - esconder / mostrar categorias: 1) curso / index.php
Moodle / usuário: viewusergrades - visualizar o seu próprio ou outro usuário do graus (com o contexto especificado)
Moodle / usuário: criar - criar usuário: 1) utilizador / edit.php
Moodle / usuário: apagar - delete user: 1) admin / user.php
Moodle / usuário: readuserblogs - leia blog entries
Moodle / usuário: update - update configurações do usuário: 1) utilizador / edit.php
Moodle / usuário: viewdetails - visualizar informações de identificação pessoal usuário (por exemplo, nome, fotografia).
Moodle / usuário: viewhiddendetails - usuário visualizar detalhes marcado como "oculto"
Moodle / calendário: manageownentries - crie / edite / exclua
Moodle / calendário: manageentries - crie / edite / exclua
Moodle / papel: atribuir - atribuir papéis aos usuários
Moodle / papel: sobrescreve - pode sobrepor papel capacidades (dependendo do contexto)
Moodle / papel: gerenciar - crie / edite / exclua papéis, definir capacidade permissões para cada papel
Moodle / papel: unassignself - unassign-se de seus próprios papéis
Moodle / papel: viewhiddenassigns - visualizar papel atribuições que foram marcadas como escondidas
Moodle / pergunta: importação - importações perguntas (nível?) - Sim, pergunta permissões atualmente precisam de ser evidente a nível .-- Tim Hunt
Moodle / pergunta: exportação - exportações perguntas (nível?)
Moodle / pergunta: managecategory - adicionar / excluir / editar pergunta categorias (nível?)
Moodle / pergunta: gerenciar - adicionar / editar / apagar uma questão (nível)

Usuário de nível Capacidades

Moodle / usuário: readuserposts-leia usuário individual lugares no perfil página (mãe?)
Moodle / usuário: readuserblogs-leia usuário individual blogs no perfil página (mãe?)
Moodle / usuário: viewuseractivitiesreport de leitura individual actividade relatório sobre perfil página (mãe?)
Moodle / usuário: editprofile - editar perfil (normalmente utilizado em CONTEXT_USERID e CONTEXT_SYSTEM)

Módulo de nível Capacidades

As capacidades são armazenada em um banco de dados tabela quando um módulo é instalado ou atualizado. Sempre que a capacidade definições são actualizadas, o módulo número de versão deve ser bumped up, para que a tabela de dados podem ser atualizados.

A convenção de nomes segue para recursos que são específicos para os módulos e blocos é "mod / mod_name: capacidade". A parte antes do cólon é o caminho completo para o módulo do Moodle código. O módulo capacidades são definidas no mod / mod_name / db / access.php.

Cessão
# Mod / atribuição: vista-leitura a cessão descrição
# Mod / cessão: apresentar - vire à atribuição de
# Mod / cessão: grau - classificação, visualização da lista de tarefas apresentadas
Chat
# Mod / chat: chat - permite que um usuário para participar deste bate-papo
# Mod / chat: readlog - permite ao utilizador ler passado chat sessão logs
# Mod / chat: deletelog - permite ao utilizador apagar passado chat logs
Choice
# Mod / escolha: escolha - fazer uma escolha
# Mod / escolha: readresponses - ler todas as respostas
# Mod / escolha: deleteresponses - apaga todas as respostas
# Mod / escolha: downloadresponses - download respostas
Database
# Mod / dados: viewentry - lê as outras pessoas da entrada
# Mod / dados: writeentry - adicionar / editar e excluir (próprio) cadastros
# Mod / dados: managetemplates - acrescentar, apagar, editar campos e modelos
# Mod / dados: manageentries - editar / apagar todas as entradas
# Mod / dados: comment - comment
# Mod / dados: managecomments - editar / apagar todos os comentários
# Mod / dados: taxa - uma taxa de entrada
# Mod / dados: viewrating
# Mod / dados: aprovar - aprova uma entrada
# Mod / dados: uploadentries - batch upload de entradas
Exercício
# Mod / exercício: avaliar
Forum
# Mod / forum: viewdiscussion
# Mod / forum: viewdiscussionsfromallgroups
# Mod / forum: viewhiddentimedposts
# Mod / forum: startdiscussion
# Mod / forum: replypost
# Mod / forum: viewrating
# Mod / forum: viewanyrating
# Mod / forum: taxa
# Mod / forum: createattachment
# Mod / forum: deleteownpost
# Mod / forum: deleteanypost
# Mod / forum: splitdiscussions
# Mod / forum: movediscussions
# Mod / forum: editanypost
# Mod / forum: viewqandawithoutposting
# Mod / forum: viewsubscribers
# Mod / forum: managesubscriptions
# Mod / forum: throttlingapplies
Glossário
# Mod / glossário: escrever - adicionar entradas
# Mod / glossário: manageentries - adicionar, editar, apagar entradas
# Mod / glossário: managecategories - criar, apagar, modificar as categorias
# Mod / glossário: comentário - comentar uma entrada
# Mod / glossário: managecomments - editar, apagar comentários
# Mod / glossário: importação - importação glossários
# Mod / glossário: exportação - exportação glossários
# Mod / glossário: aprovar - aprovar glossários
# Mod / glossário: taxa - taxas glossário
# Mod / glossário: viewrating - ver avaliações
Hotpot
# Mod / hotpot: tentativa - tentar uma hotpot
# Mod / hotpot: viewreport - analisar e visualizar relatórios
# Mod / hotpot: grau - (grau? E) regrade
# Mod / hotpot: deleteattempt - apaga tentativas
Label
# None
Lams
# Mod / lams: participar - original estudante
# Mod / lams: gerenciar - original professor
Aula
# Mod / aula: editar - adicionar e editar páginas
# Mod / aula: gerenciar - vista estudante tentativas
Quiz
# Mod / quiz: grau - comment, sobrepor grade, manual grade
# Mod / quiz: preview - inspeciona o quiz
# Mod / quiz: viewreports - vista quiz resultado relatórios
# Mod / quiz: gerenciar - add / delete / mover (para cima ou para baixo) perguntas de um questionário
# Mod / quiz: tentativa - a tentativa quiz - Tim Hunt
Resource
Scorm
# Mod / scorm: viewgrades
Survey
# Mod / vistoria: download - downloads survery resultado
# Mod / vistoria: participar - participar / fazer vistoria
# Mod / vistoria: readresponses - ler todos do usuário responese
Wiki
# Mod / wiki: participar - original aluno, o que significa que depende do tipo de curso e estabelecimento
# Mod / wiki: gerenciar - original professor, gere atribuído grupo; moodle / site: accessallgroups é necessária para gerir todos os grupos
# (Em espera no novo wiki)
Workshop
# Mod / workshop: participar - original aluno, permite ao usuário apresentar e avaliar
# Mod / workshop: gerenciar - original professor, o usuário pode gerenciar outros
# (Em espera no novo Workshop)

Matrícula de nível Capacidades

A convenção de nomes segue para recursos que são específicos para inscrição é 'matricular / enrol_name: capacidade ". A inscrição capacidades são definidas em matricular / enrol_name / db / access.php.

Authorize.net pagamento Gateway
# Matricular / autorizar: managepayments - usuário gerenciar os pagamentos, captura, nula, restituição, apagar etc

Blocos === ===

Activity_modules
# Nenhum
Admin
Admin_2
Admin_bookmarks
Blog_menu
Blog_tags
Calendar_month
Calendar_upcoming
Course_list
Course_summary
Glossary_random

Html #

Loancalc
Login
Mensagens
News_items
Online_users
Participantes
Quiz_results
Recent_activity
Rss_client
# Bloco / rss_client: createprivatefeeds
# Bloco / rss_client: createsharedfeeds
# Bloco / rss_client: manageownfeeds
# Bloco / rss_client: manageanyfeeds
Pesquisa
Search_forums
Section_links
Site_main_menu
Social_activities

Perguntas === === Estou acrescentando pergunta categorias aqui porque eles parecem ter sido esquecidas em todo o esquema das coisas desde que tenham sido removidos do quiz módulo em si. Eu fiz uma sugestão sobre o modo como estas poderiam ser tratados em = bug 6118.

Veja este forum thread para uma discussão sobre os problemas actuais wth publicação pergunta categorias. Tim Hunt 18: 50, de 8 de Agosto de 2006 (WST)

Programming Interface

Embora os papéis do sistema possam parecer complicados a primeira vista, implementá-los em Moodle código é bastante simples.

Você precisa definir capacidade de cada uma, para que possam atualizar Moodle existentes papéis de tirar partido dela. Você faz isso em um access.php dentro da pasta db de qualquer módulo (por exemplo, ver mod / forum / db / access.php). O array contém entradas como este (note as descrições para o legado papéis que fornece compatibilidade futura):

    "Mod / forum: viewforum '=> array (
        'Captype' => 'ler',
        'Contextlevel' => CONTEXT_MODULE,
        'Herança' => array (
            'Hóspede' => CAP_PREVENT,
            'Estudante' => CAP_ALLOW,
            'Professor' => CAP_ALLOW,
            'Editingteacher' => CAP_ALLOW,
            'Coursecreator' => CAP_ALLOW,
            "Admin" => CAP_ALLOW
        )
    ),

Para carregar / alterar esses recursos necessários para o módulo versão lombada. Não há necessidade de proporcionar mudanças ou diferenças como Moodle irá varrer toda a gama e tipo it out.
Em cada página que você precisa para encontrar o contexto em que o usuário está trabalhando, usando o get_context_instance () function. Por exemplo, no fórum módulo:

  $ Context = get_context_instance (CONTEXT_MODULE, $ cm-> id);

Ou para o curso em nível:

  $ Context = get_context_instance (CONTEXT_COURSE, $ id);

Então, sempre que você deseja verificar se o usuário atual tem direito a fazer qualquer coisa, chamada has_capability () como este:

    If (! Has_capability ( "mod / forum: viewforum ', $ context)) (
        Print_error ( 'nopermissiontoviewforum');
    )

Se você quiser simplesmente afirmar uma capacidade e, em seguida, concluir com uma mensagem de erro quando ele não é cumprido (como fizemos anteriormente), então um caminho mais curto que a utilização require_capability () como este:

    Require_capability ( "mod / forum: viewforum ', $ context);

Note-se que existem parâmetros adicionais que você pode especificar para obter uma mensagem de erro personalizada, caso contrário, os usuários obtêm uma automatizados "Não permissões" mensagem que lista a permissão que estavam faltando.

Como resultado das novas funções do sistema, todas as chamadas para isadmin (), iscoursecreator, isteacheredit (), isteacher (), isstudent (), e isguest () terá de ser substituído com chamadas para has_capability () ou require_capability (). No entanto, estas funções serão conservados por alguns para trás compatibilidade com código antigo, usando o legado capacidades para experimentar e exercitar-se sobre o que fazer.

Metacourses

O comportamento dos metacourses em Moodle 1,7 ligeiramente alterada, em que, quando ele apenas usado para sincronizar os estudantes de cursos criança ao progenitor curso, que agora irá sincronizar ALL papéis. Etc professores da criança cursos terão o mesmo papel na meta curso. Tecnicamente metacourse synchronises todos papel com as suas atribuições na CONTEXT_COURSE criança cursos, a única excepção são os usuários com moodle / curso: managemetacourse capacidade, esses usuários são sincronizadas apenas para cima, eles não são unenrolled de metacourse quando unenroling de criança curso ou quando a remoção da criança a partir de Metacourse.

A fim de importação e se matricular em outros cursos metacourse você precisa ter moodle / curso: managemetacourse capacidade. Você pode adicionar manualmente apenas os participantes com moodle / curso: managemetacourse, todos os outros participantes são automaticamente sincronizada com criança cursos - se você tentar inscrever manualmente usuário sem esta capacidade erro é exibida. Similar erro é mostrado também quando você tentar manualmente unenrol participante da meta curso enquanto continuam a ser matriculado no curso criança.

Exemplo de configuração:

Metacourse gerente foi atribuído papel com moodle / curso: managemetacourse capacidade no sistema ou curso categoria contexto
Estudantes estão matriculados em diversos cursos criança
Professores estão matriculados no curso separado filho (s)

Problema áreas estamos trabalhando em

Estudante vista === ===

A "visão Estudante" foi removido completamente.

Se houver tempo e de uma forma segura pode ser encontrada, ela será substituída por um menu para permitir que o usuário assumir um papel temporária no contexto do que evidente.

Docente fórum === ===

Docente fóruns sempre foram uma curiosa exceção ao normal fóruns, uma vez que não faziam parte de um curso como tal, e não foram backup.

Estamos tendo a oportunidade de corrigir esta situação. A atualização converte professor fóruns com conteúdo normal de fóruns na secção 0 do curso, e assegura que apenas os professores podem acessá-los. Se o professor fórum não tinham sido utilizados no curso, então não é convertido e vai desaparecer.

Matrícula plugins === ===

Processo de login na

Load_user_capability () é chamado para carregar todas as capacidades
Check_enrolment_plugins () é chamado, na parte superior do load_user_capability () para verificar todas as matrículas encaixes.
Para cada activo plugin:
# Check para setup_enrolments ($ user) e executá-lo. Esta função irá fazer todo o tratamento necessário para atribuir ou unassign papéis do usuário atual.
Load_user_capability () continua e carrega-se todos os papéis
Load_defaultuser_role () é chamado para adicionar site permissões padrão (todos os utilizadores)

Processo de verificação acesso a um curso

Require_login ($ curso-> id) é chamado pelo script e tem lógica como este:

Será que o usuário um convidado, em nível local?
# Sim: Será que o curso permite convidados?
# # Sim: retornar true (e mais capacidades são controlados pelo script)
# # No: enviar ao usuário curso / enrol.php para inscrições
# No: continuar abaixo

Será que o usuário tenha moodle / curso: ver em que contexto (claro)?
# Sim: então eles podem entrar (e novas capacidades são controlados pelo script)
# Não: é convidado acesso permitido no curso?
# # Sim: atribuir temporária hóspede papel a esse usuário para que o contexto (em sessão cache).
# # No: enviar ao usuário curso / enrol.php para inscrições.

Processo de inscrição

(Mais em breve)

Cenário brainstorming

Esta seção é para brainstorming exemplo alguns papéis que gostaríamos de apoio. Nota alguns destes * * podem não ser possíveis em 1.7.

Estudante === === Obviamente.

Site Designers === === Existe um papel para as pessoas envolvidas na forma como aborda o site, mas não completa administradores? Pensando aqui online de controle de temas, em vez de FTP tema uploading. Mas, em ambos os casos eles caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.

Educational Authority Conselheiro

Alguém que gostaria de navegar no site e pode ser convidado a comentar ou contribuir para discussões particular ou desenvolvimentos na escola. Acesso para este papel seria controlada pela escola no caso da escola nível moodles mas pode ser diferente se houvesse a ser um local amplo Autoridade Moodle.

Educacional Inspetor

Alguém que irá visitar o local para verificar a escola da auto-exame que as observações sobre a escola home relacionamentos, estendendo a sala de aula etc Eles podem querer ver resumos de utilização e relatórios de inquéritos garnering pais e alunos visitantes.

Segunda Marker / Moderador

Um professor dentro ths site, que tem acesso a tarefas e testes de um outro professor do curso para segunda marcação fins. Isto pode precisar de mais funcionalidade adicionando à atribuição módulo para que dois maços de notas / gabarito pode ser dado a um conjunto de atribuições.

Peer observador do ensino

Muitas instituições incentivar peer observação do ensino, incentivar a reflexão sobre a prática. Em ambientes online este será semelhante à moderação ou da inspecção. A peer observador teria de ser capaz de viver o curso ", como um aluno", mas também para poder visualizar resumos de uso, transcrições de interacções (fóruns / inquéritos / sondagens etc), graus atribuídos (por exemplo, em missões).

Examinador externo === === Tem todos os direitos dos inspectores, mas também têm de ser capazes de rever atribuições e feedback, fóruns opinião, glossários etc No entanto, não gostaria de comentar, feedback para o site em tudo.

Parent === === A mãe vai ter um ou mais filhos, em uma ou mais instituições, que podem estar usando uma ou mais instâncias moodle ou uma mistura de Aprendizagem Plataformas. A mãe do papel irá variar de acordo com a idade de seus filhos e se estão contribuindo como um pai ou uma escola adepto.

Em Early Anos (EY = 3 4 yr idade) e Key Stage 1 (KS1 = 5 6 yr idade), podem jogar / aprender sobre uma actividade ou escrever para a criança. Os pais muitas vezes interpretar casa tarefas e ler aos seus filhos talvez preenchimento de uma leitura conjunta diário. Em Key Stage 2 (KS2 = 7-11 yr idade) pais seria mais fiscalização, mas pode entrar em tão bem.

Em Key fases 3 (KS3 = idade 12-14 anos) e 4 (KS4 = 15 +16 yr idade), este muda para mais de um acompanhamento / sensibilização papel onde uma mãe seria de esperar para ter uma síntese das presenças, realização e geral Realização numa semanal / mensalmente / termly ou anual. Os pais serão frequentemente solicitado para assinar e escrever back comentários sobre essa revisão relatório.

Em todos Key Stages existe uma grande necessidade de pais para receber comunicação da escola que se pode confirmar que eles têm recebido através da assinatura de um formulário. Em alguns casos, isto pode também envolver a fazer escolhas a partir de uma lista. Também pode implicar pagamento de uma viagem ou discoteca ser devolvido assim poderia haver a possibilidade de pagamentos electrónicos. Também em todos os principais Satges pode haver uma casa-escola acordo, o qual pode ser assinado até. Isto poderia fazer parte de uma política local que incorpora um sistema tickable lista das actividades a mãe concorda com a criança usando (blogs / wikis / fóruns etc)?

Pais tardes envolvem frequentemente complexos sistemas de reserva que tentam obter pais e professores em conjunto. Fácil de EY/KS1/KS2 muito difícil para KS3/KS4. Wow iria ajudar neste caso, foi incorporado no Learning Platform.

Em alguns casos, é necessário que exista comunicação confidencial entre os pais e os professores, sem que a criança seja parte no presente. Pode envolver ensino e da aprendizagem, mas também poderia envolver um comportamento ou médicos questão. Muitas vezes isso pode ser feito através de uma carta ou selados cara a cara.

A mais recente encarnação do OfSTED com o Self Review Framework (SEF), há uma maior ênfase nas escolas recolha mãe voz através de pesquisas e debates. Há aqui uma clara correspondência com os pais têm acesso a parental votos, questionários e discussões e para as escolas para poder publicar notícias, resultados e relatórios de volta para os pais.

No Reino Unido, o LP quadro e agenda como sendo empurrada pela DfES via Becta salienta que dentro da obrigatoriedade grupos e papéis funcionalidade do papel dos pais é provável que seja necessário para satisfazer o LP Quadro procurement padrão.

Mais uma vez, no Reino Unido, os pais têm o seu próprio direito de acesso independente para uma criança do ensino registros. Obviamente, infantis registros não devem ser postos à disposição das outras partes, incluindo os pais de outras crianças da mesma classe. Assim, seria necessário associar as contas com sua própria mãe da criança contas de tal forma que eles possam, se assim o desejar, ter acesso a ler seu filho graus, respostas e contribuições, mas geralmente não os das outras crianças - isto pode ser problemático No caso das actividades wiki ou forum posts.

Há alguma preocupação de que as crianças do fórum contribuições etc pode ser limitada se os pais são capazes de ler tudo o que eles escrevem; isso pode ser particularmente problemática em áreas como pessoal, Social e Educação em Saúde (PSHE), em que algumas escolas podem optar pela utilização Pouco clara tradição nicks.

Gerente === === Adicione texto aqui ...

Weekly Seminário Leader

Em um seminário universidade, tipicamente 8-15 alunos nos seus 3rd/4th ano, cada aluno é responsável pela liderança um tópico em um estudo série. Peço a cada aluno investigação 5-10 recursos e, em seguida, dar uma apresentação powerpoint para os outros alunos. Esta é seguida por uma discussão em classe e, em seguida, online casa. A casa envolve algumas questões fun quiz e, em seguida, algumas perguntas reflexivo revista. Peço cada seminário líder para preparar a questionários e revistas perguntas, bem como a sua apresentação. Para fazer isso, gostaria de atribuir activity-making/authoring papéis para o estudante - seja por um curto período, ou seja, para toda a duração do curso. Assim, "Permitir Quiz Autor Papel" ou "Permitir Cessão Autor Papel", no curso nível ou, se possível, mesmo a nível temático (em um tópico ou semana formato claro) seria importante.

Mentor / Mentee

Adicione texto aqui ...

Comunidade-Desenhado Rating Critérios

A gradebook tende a ser o domínio do professor. E se comunidade / peer avaliações / marcas também poderia ser inscrito lá? E se peer avaliação critérios poderiam ser concebidas pelos estudantes, não apenas o professor?

Visitante

Este seria um papel em que se poderia permitir que um visitante de uma visita da escola. Este poderia ser um colega interessado em ver o seu curso, ou um jornalista que poderia ser escrito um artigo sobre o próprio site. Eles não devem ser capazes de ver os nomes de todos os alunos em qualquer lugar (por exemplo recente atividade, fórum lugares) pela privacidade razões. 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 (eg 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

Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]
Address function: isteacher, isadmin, isstudent [Yu]
Remove "view" capabilities from all modules unless required [Vy]
Remove all old references from remaining Blocks [Vy]
Metacourses [Skodak]
Add risks to GUI[Skodak]
Enrolment plugins [Martin and Alastair]
Statistics [Penny]
Fix Loginas
Add category-level assigns [Yu]
Backups [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" .

File: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.

File: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".

File: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.

Documentation