Permissions

h1. Permissions and roles

h2. Permissions

Permissions appear from version 2.0.

They allow the admin to define what roles has what permissions.

Chamilo works with a strong contextual focus on courses and the course "space", so many of the permissions you would otherwise find in a global, platform-wise setting would not apply in our context, or would make management so complex it would just repel most users.

Here is the (evolving) list of permissions for Chamilo 2:

Chamilo permission code	Meaning
analytics:view
assignment:create
assignment:delete
assignment:edit
assignment:grade
assignment:submit
assignment:view
backup:backup
backup:copy
backup:restore
badge:configurecriteria
badge:create	This allows a user to create and duplicate badges
badge:edit
badge:delete
badge:awar
badge:view
calendar:create	Create global calendar events
calendar:edit
calendar:delete
certificate:create
certificate:delete
certificate:edit
certificate:generate
certificate:generateall
certificate:issue
certificate:manage
certificate:viewall
class:assigncourse
class:assignsession
class:assignuser
class:create	Manage global classes of users
class:delete
class:edit
class:view
cms:create
cms:delete
cms:edit	Edit and change publication status
course:create
course:delete
course:downloadcoursecontent
course:edit	Edit own course's properties
course:editall	Edit all course's properties
plugin:manage	Enable/disable/configure plugins
quiz:create	Create a quiz
quiz:delete
quiz:edit
quiz:grade
quiz:viewliveresults
role:create	not yet available
role:managepermissions	Assign or remove permissions from roles
session:create
session:delete
session:edit	Edit own session's properties
session:editall	Edit all sessions' properties
session:assigncourse	Assign a course to a session (to assign users, use user:assignsession)
site:editsettings
site:maintenanceaccess	not yet implemented
skill:coursecompetencymanage	Assign skills through course gradebooks
skill:usercompetencyreview	Add comments on other user's acquired skills
skill:create
skill:delete
skill:edit
survey:create	Add a survey (global or inside own course)
survey:edit
survey:delete
survey:view
ticket:comment
ticket:manage	Manage the tickets system
ticket:report
ticket:seeissues	See issue details for issues where they are involved
ticket:viewallissues
tool:editvisibility	Allow setting the visibility of a tool in a course (depends on context)
url:manage	Manage Multi-URL configuration (=tenant in Moodle)
url:assignusers
url:assigncourses
url:assignclasses
user:create
user:delete
user:edit
user:assigncourse
user:assignclass
user:assignsession
user:editrole

h2. Roles

Roles are defined in config/packages/security.yaml under the array role_hierarchy. These roles are assigned through the roles field in the user table.

New roles cannot be created through the interface at the moment, but once created in security.yaml, they will appear in the permissions assignation page in the administration section of Chamilo.

This is a non-updated list of roles, from security.yaml:

    role_hierarchy:
        ROLE_STUDENT: [ROLE_USER]
        ROLE_ADMIN:
            - ROLE_USER
            - ROLE_STUDENT
            - ROLE_TEACHER
            - ROLE_QUESTION_MANAGER
            - ROLE_SESSION_MANAGER
            - ROLE_CURRENT_COURSE_TEACHER
            - ROLE_CURRENT_COURSE_SESSION_TEACHER
            - ROLE_CURRENT_COURSE_GROUP_TEACHER
        ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH] # Admin that can log in as another user.
        ROLE_GLOBAL_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH] # The user that installed the platform.
        ROLE_TEACHER: [ROLE_STUDENT]
        ROLE_RRHH: [ROLE_TEACHER, ROLE_ALLOWED_TO_SWITCH]
        ROLE_QUESTION_MANAGER: [ROLE_STUDENT]
        ROLE_SESSION_MANAGER: [ROLE_STUDENT, ROLE_ALLOWED_TO_SWITCH]
        ROLE_STUDENT_BOSS: [ROLE_STUDENT]
        ROLE_INVITEE: [ROLE_STUDENT]

        ROLE_CURRENT_COURSE_STUDENT: [ROLE_CURRENT_COURSE_STUDENT] # Set in the CidReqListener
        ROLE_CURRENT_COURSE_TEACHER: [ROLE_CURRENT_COURSE_TEACHER, ROLE_CURRENT_COURSE_STUDENT] # Set in the course listener
        ROLE_CURRENT_COURSE_GROUP_STUDENT: [ROLE_CURRENT_COURSE_GROUP_STUDENT] # Set in the CidReqListener
        ROLE_CURRENT_COURSE_GROUP_TEACHER: [ROLE_CURRENT_COURSE_GROUP_TEACHER, ROLE_CURRENT_COURSE_GROUP_STUDENT]
        ROLE_CURRENT_COURSE_SESSION_STUDENT: [ROLE_CURRENT_COURSE_SESSION_STUDENT]
        ROLE_CURRENT_COURSE_SESSION_TEACHER: [ROLE_CURRENT_COURSE_SESSION_STUDENT, ROLE_CURRENT_COURSE_SESSION_TEACHER]
        ROLE_ANONYMOUS: [ROLE_ANONYMOUS]

Each role is assigned permissions by default and through the permissions management panel.

h2. Contributing

If you would like to suggest the incorporation of a new permission, please simply open a new issue and start with "Permissions: ".

h2. On cross-LMS standardization

Given we started later to implement permissions, we tried to keep similarities with capabilities in Moodle, but after trying to understand the structure of those, we had to give up to avoid having inconsistency all over in the permissions naming. Also, sorry for people hoping for standardization, but our systems are so different and it wouldn't make sense.

In our context, some capabilities do not make sense. For example, a user should always be able to see his/her own results if the learning objects are configured to show results. An "analytics/listowninsights" doesn't seem to make much sense for us, so we don't implement it (you can say that it's "always on").

Other capabilities are added because the corresponding feature does not exist or is very different there, like the CMS feature.

Some feature are false friends: sessions are not the same in both systems, triggering poential confusion for someone trying to use the same base naming.