3 // Capability definitions for the scorm module.
5 // The capabilities are loaded into the database table when the module is
6 // installed or updated. Whenever the capability definitions are updated,
7 // the module version number should be bumped up.
9 // The system has four possible values for a capability:
10 // CAP_ALLOW, CAP_PREVENT, CAP_PROHIBIT, and inherit (not set).
13 // CAPABILITY NAMING CONVENTION
15 // It is important that capability names are unique. The naming convention
16 // for capabilities that are specific to modules and blocks is as follows:
17 // [mod/block]/<component_name>:<capabilityname>
19 // component_name should be the same as the directory name of the mod or block.
21 // Core moodle capabilities are defined thus:
22 // moodle/<capabilityclass>:<capabilityname>
24 // Examples: mod/forum:viewpost
25 // block/recent_activity:view
26 // moodle/site:deleteuser
28 // The variable name for the capability definitions array follows the format
29 // $<componenttype>_<component_name>_capabilities
31 // For the core capabilities, the variable is $moodle_capabilities.
34 $mod_scorm_capabilities = array(
36 'mod/scorm:viewreport' => array(
39 'contextlevel' => CONTEXT_MODULE
,
41 'teacher' => CAP_ALLOW
,
42 'editingteacher' => CAP_ALLOW
,
47 'mod/scorm:skipview' => array(
50 'contextlevel' => CONTEXT_MODULE
,
52 'student' => CAP_ALLOW
56 'mod/scorm:savetrack' => array(
59 'contextlevel' => CONTEXT_MODULE
,
61 'student' => CAP_ALLOW
,
62 'teacher' => CAP_ALLOW
,
63 'editingteacher' => CAP_ALLOW
,
68 'mod/scorm:viewscores' => array(
71 'contextlevel' => CONTEXT_MODULE
,
73 'student' => CAP_ALLOW
,
74 'teacher' => CAP_ALLOW
,
75 'editingteacher' => CAP_ALLOW
,