ApiMoodle

API hooks for Moodle

The following API hooks are supported for Moodle instances:

• Membership service (including group information)
  • Resource link level
  • Context level

The implementation is more equivalent to the unofficial Memberships service extension which includes support for passing group membership data as well as enrolments.

The hooks should be registered as follows:

use ceLTIc\LTI\ApiHook\ApiHook;
use ceLTIc\LTI\Context;
use ceLTIc\LTI\ResourceLink;

Context::registerApiHook(ApiHook::$MEMBERSHIPS_SERVICE_HOOK, 'moodle', 'ceLTIc\LTI\ApiHook\moodle\MoodleApiContext');
ResourceLink::registerApiHook(ApiHook::$MEMBERSHIPS_SERVICE_HOOK, 'moodle', 'ceLTIc\LTI\ApiHook\moodle\MoodleApiResourceLink');

Configuration options

The following configuration options are supported:

Name	Required?	Description	Example
moodle.url	Yes	The base URL for the Moodle server	https://myinst.edu/moodle
moodle.token	Yes	The web service access token authorising API requests	53963338ec4b160c1e774060a723c0f3
moodle.grouping_prefix	No	A prefix which a grouping name must match before it is considered to be included in the results	Group
moodle.per_page	No	Maximum number of records to be requested per message. The default is 50; use a value of 0 to remove the limit.	100

These configuration options should be saved in the settings area of the tool consumer record; for example:

$toolConsumer->setSetting('moodle.per_page', '75');

The options must be specified for each Moodle instance defined within the tool provider at least the base URL and access token will be different for each.

Prerequisites

The API hook uses the Moodle web services which are documented on the Moodle site and within Moodle on the page at Site administration / Plugins / Web services. The Moodle instance must be configured to authorise the access from the tool provider. This involves the following steps:

1. Enable web services (see Site administration / Advanced features)
2. Enable the REST protocol (see Site administration / Plugins / Web services / Manage protocols)
3. Create a user (e.g. named WebPA Service) (see Site administration | Users | Accounts)
4. Create a role (e.g. named WebPA and assign it to the user (see below) (see Site administration | Users | Permissions | Define roles)
5. Add an external service (e.g. named WebPA web service with a short name of webpa) (see Site administration | Plugins | Web services)

• add functions to the service (see below)
• add the WebPA user as an authorised user of the service

1. Create an access token for the WebPA user (an IP restriction can also be added here if desired) (see Site administration | Plugins | Web services | Manage tokens)

The role assigned to the WebPA user must have the following capabilities:

• moodle/course:enrolreview
• moodle/course:managegroups
• moodle/course:useremail
• moodle/course:view
• moodle/user:viewdetails
• moodle/user:viewhiddendetails
• webservice/rest:use
• moodle/site:accessallgroups
• moodle/site:viewfullnames

This will mean that the access token generated can access all courses in the Modle instance. If it is preferred to limit this, then do not assign the moodle/course:view capability to the WebPA user, but enrol them in each course for which you wish to give WebPA access.

The WebPA external service must have the Enabled and Authorised users only boxes checked and have the following functions added:

• core_enrol_get_enrolled_users
• core_group_get_course_groupings
• core_group_get_course_groups
• core_group_get_groupings

Limitations

The current implementation has the following limitations:

1. The roles returned for each user do not include any administrator roles which may apply to the user and would be included in an LTI message.
2. The value of the lis_result_sourcedid parameter is not included.