Roles and Capabilities

In Moodle, a role is actually a bundle of capabilities. Plugins can have there own capabilities. That way, whenever you install a new plugin, you can set the capabilities of the plugin for each of the role definitions. A lot of plugins come with preconfigured capability settings for 'legacy' roles, such as 'teacher' and 'student'.

For your own plugin, you can set the capabilities in mod/yourmod/db/access.php. Here's an example snippet:

<?php

defined('MOODLE_INTERNAL') || die();

$capabilities = array(
    'mod/planner:access' => array(
        'captype' => 'write',
        'contextlevel' => CONTEXT_MODULE,
        'legacy' => array(
            'manager' => CAP_ALLOW,
            'student' => CAP_ALLOW,
            'teacher' => CAP_ALLOW,
            'editingteacher' => CAP_ALLOW
        )
    )
);

?>

I had a problem with a plugin which had the 'CAP_PROHIBIT' setting for all legacy roles. On the site where this plugin was used, there were two roles at play:

• National coordinator, a custom, site-wide role which was allowed to actually use the plugin.
• Frontpage student, for which the client (i.e. the site owner) had set the plugin's capability to CAP_PROHIBIT. This role could only be assigned in the 'course' and 'Activity module' context.

Now, even though the users with the 'national coordinator' role did not have the 'frontpage student' role, they were still not allowed to use the plugin.

Only after changing the capability for the 'frontpage student' role, as provided by the plugin, to 'not set' did this problem disappear.

This function returns true if the currently logged in user is admin.

    function is_admin() {
       return has_capability('moodle/site:config', get_context_instance(CONTEXT_SYSTEM)); 
    } // function is_admin

(This function is part of Soda's controller.)