开发者:角色

角色和权限的功能将会出现在 Moodle 1.7 中，目前在开发者所使用的版本中应该已经有了。

定义

角色是用户在某个环境中的状态。例如教师、学生、论坛管理员都是一种角色。

权力指的是Moodle中一种特定的功能，它会和角色关联起来，例如mod/forum:replypost是一种权力。

权限是指一种权力与某个角色之间的关系。例如允许或拒绝。

环境是指Moodle中的“空间”，例如课程、活动模块及版块等。

已有的系统

在目前的Moodle中，我们有一系列固定的角色，例如主管理员、管理员、课程创建者、有编辑权限的教师、无编辑权限的教师、学生以及访客。对于每一种角色，它所拥有的能力或者说他可以执行的操作是固定的。例如，角色学生允许用户提交昨夜，但不允许用户浏览、修改其他人的作业。通过这种方法表达的角色与权限之间的关系是完全固定的。如果我们希望让某个学生或用户组可以在某个课程中批改作业，那么我们就必须给这些学生教师的权限。

新的角色与权限系统

Moodle1.7 角色有两个重要功能：

定义一系列权限 - 角色定义是全局的，对任何环境都有效，但可以被某个环境中的本地设置所覆盖
替换旧的选课系统 - 再课程这个环境中的角色设置同旧的选课过程很像

新的系统允许被授权的用户定义一系列角色（如教师）

角色拥有一系列执行Moodle中不同操作的权限（例如删除帖子、增加活动等）

角色可以在某个环境中赋予给用户（例如让Fred成为某个课程的教师）

以下是一些已有的环境，列在前面的是最常用的。

CONTEXT_SYSTEM -- 整个站点
CONTEXT_PERSONAL -- 你自己
CONTEXT_USER -- 其他用户
CONTEXT_COURSECAT -- 某个类别的课程
CONTEXT_COURSE -- 一门课程
CONTEXT_GROUP -- 一个用户组
CONTEXT_MODULE -- 一个活动模块
CONTEXT_BLOCK -- 一个版块

被授权的用户可以将角色赋予任何环境下的用户。

我们可以为角色的每一种能力设定下列四种权限：

CAP_INHERIT
CAP_ALLOW
CAP_PREVENT
CAP_PROHIBIT

如果没有定义特定的权限，那么一个角色的权力就从较高较大的环境中继承。如果我们在一个小的环境中修改了某个角色的权力，那么这就称为角色覆盖。

由于每个角色的权力是不一样的，当一个人拥有多个角色的时候就有可能产生冲突。通常，在小环境中指定的权限会生效，除非在大环境中将某个权力指定为“禁止”。

例如，马克是一个课程的“学生”，拥有这个权限，他就可以编辑 Wiki。但是再某个模块的环境中（例如某个特定的 Wiki），它又被分配了“访客”角色，这样他就不能编辑这个 Wiki 了。这就是小环境中的权限生效的例子。

如果设定了“禁止”权限，就表示该角色不再拥有某个特定的权力，即在所有的情况下都是“阻止”的。“禁止”的权限总是生效的。例如，Jeff 的一个角色是“淘气的学生”，这个角色“禁止”它在任何的论坛中发帖子，但他又是“科学与数学”课程中“科学论坛”的版主，由于”禁止“的权限总是生效，于是 Jeff 就不能在”科学论坛“中发帖子了。

如果在一个环境中同时出现了允许和阻止使用某个权力的情况，那么在这个环境中对该权力的分配就不在有效。系统会自动到较高一层的环境中去查看用户是否拥有该权力。

这看上去很复杂，但做起来其实并不困难。这样管理权力的好处就是整个系统可以非常灵活，可以实现不同类型的权力分配。

从1.6升级

升级到1.7的过程将会非常平滑，已有的角色（管理员、教师和学生等）以及已有的各种权力将会保留。系统会通过再站点/课程级别创建缺省的角色并将现有的用户赋予相应的角色来做到这一点。缺省的角色会有缺省的权力和他们相关联，同1.6中的一样。无需任何修改，Moodle在升级前后可以保持同样的行为。

管理员

管理员用户会被赋予系统级的管理员角色

课程创建者

在站点级创建课程

教师

教师在他的课程中将会被赋予教师的角色。

学生

学生将会在其选修的课程中被赋予学生角色。

访客

站点中会有一个没有任何权限的访客用户。对于允许访客访问的课程，访客用户将具有改课程中的访客角色。课程的访客控制选项将从三个变成两个，在新的版本中访客必须要输入密钥才能访问有密钥的课程。

权力

在这里将会列出一系列的“权力”（但它还不完整），保证“权力”名称的唯一性是非常重要的。

这一部分请参考英文原文。

编程接口

元课程

有问题的部分

头脑风暴：角色的应用

这个部分是希望列出一些我们能够支持的角色类型，注意其中的一些是无法在1.7中使用的。