...

2.3 Roles and Authorization

The

 membership module maintains "groups" as hierarchical contexts for roles.  So, for example, a user foo@mit.edu may have the role of Instructor in the group "/course/5/sp15/5.678" which corresponds to a course.  There may be subgroups corresponding to sections, and the user foo@mit.edu would have the Instructor role in all these subgroups as well.  (Inheritance of role is dependent on role and group type.)   Each other module maintains its own mapping from role and group to permissions.  There are system-wide roles as well.   Generally the modules will grant sysadmin privileges to any user who has the membership System Administrator role in membership, but again this is module-dependent.

3 External Data Feeds

4 LMOD APIs

4.1 Membership API

4.1.1 Example

4.1.2 Intended Use Cases

...

4.3 Gradebook API

4.3.1 Example

4.3.2 Intended Use Cases

4.3.3 Pitfalls

• Membership group changes take approximately 15 minutes to propagate to gradebook.  Sometimes the first access to a gradebook in a long time will get "stale" permissions since unused gradebooks are not agressively synced to membership. This may mean that after a permission change the consuming application may need to retry a query before giving up.  The 15 minutes can be shortened if a sysadmin manually kicks off a membership sync for a group.
• Similarly, membership user changes take approximately 6 hours to propagate to gradebook.  This is largely unnoticeable since one can always query membership for up-to-date person metadata.  The only time this would be an issue in gradebook is if a user has a new system-wide privilege change.  In this case, a new sysadmin may need to wait 6 hours to be able to do sysadmin tasks in gradebook.  The 6 hours can be shortened if a sysadmin manually kicks off a membership sync for a user.

4.3.4 Full Documentation link

4.4 Calendar API

 The Calendar module exposes the Google Calendar API via our own API underneath the /service/google-apps-proxy/calendar endpoint.  We have our own Google Apps for Education domain corresponding to learning-modules.mit.edu, and we map LMOD accounts onto google user accounts via a name translation scheme.  For example, jcalz@mit.edu in LMOD becomes jcalz-at-mit-dot-edu@learning-modules.mit.edu in Google.  The detail of this are not really that important since the only service we are currently exposing is Calendar.  We also map LMOD group/role pairings onto groups in Google (this may change soon).  When we provision calendars for a group, we assign google groups so that staff roles have "writer" permissions on the calendar, and student/guest roles have "reader" permissions.  Additionally, the gradebook and materials modules add events to a group's calendar corresponding to relevant dates (assignment due / posting dates).  These events have extended properties on them (event.extendedProperties.shared.lmodSystemManaged=true) so that they can be handled programmatically by consumers

4.4.1 Example

https://mv-ezproxy-com.ezproxyberklee.flo.org/service/google-apps-proxy/calendar/v3/calendars/mitacademiccalendar@learning-modules.mit.edu/events?singleEvents=true&orderBy=startTime&maxResults=1000

4.4.2 Intended Use Cases

• Allow users to view and/or edit google calendars to which they have access
• See assignment due/posting/release dates on their calendars
• See the calendar UI code we provide for example usages: https://mv-ezproxy-com.ezproxyberklee.flo.org/calendar

4.4.3 Pitfalls

• Supports application certificate authentication but not impersonation.  This means that the application certificate account itself needs to have access to the calendar in order to read or write.
• Supports unauthenticated access by mapping unauthenticated users to guest@learning-modules.mit.edu.  This is a workaround since the Google calendar API itself does not support unauthenticated access.  The guest account has access to all public calendars.  It is considered a misuse of the API to do any writes as the guest account.
• The dev and test tiers have separate google apps domains, and the data is not copied from production to dev or test. 
• Users cannot authenticate directly to their google apps account via the google ui, since the password is a strong random value and we do not have touchstone enabled.  We currently only support authentication via the above proxy endpoint.
• Right now when course access settings are changed in membership (World / MIT-Wide / Class-Only / Staff-Only and Archived status) the calendar needs to be reprovisioned manually to pick up permission changes.  Group membership changes (e.g., person is added to or removed from the group) are picked up automatically, with no appreciable delay.

4.4.4 Full Documentation link

 https://developers.google.com/google-apps/calendar/v3/reference/

4.5 Materials API

4.5.1 Example

4.5.2 Intended Use Cases

...

4.6 Forum/Announcement API

...

We have an instance of phpBB in learning

4.6.1 Example

https://mv-ezproxy-com.ezproxyberklee.flo.org/service/forum/announcement/

4.6.2 Intended Use Cases

4.6.3 Pitfalls

• Does not (yet) support application certificates or impersonation.
• Does not (yet) support making posts in forums.
• The dev and test instances are not synchronized with the production data.

4.6.4 Full Documentation link

Find forum posts: https://mv-ezproxy-com.ezproxyberklee.flo.org/service/forum/findPosts/doc/

Announcement API: https://mv-ezproxy-com.ezproxyberklee.flo.org/service/forum/announcement/doc/