...
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
| Note |
|---|
TODO Qing: LDAP, DW, ESAPIS etc |
The membership service talks to warehouse, ESAPIS, and LDAP. Currently we get Academic terms info, new MIT krb account, course catalog info from the warehouse. The data is updated once a day via a nightly cronjob. It talks to LDAP once a day for person info updates such as names, email addresses, phone number, etc.It updates both MIT persons as well as CAMS account. It talks to ESAPIS for roster data (both reg and pre reg), section data, and section assignment data. The update is on-demand and wecache the data for 30 minutes. We are currently working on getting the student advisor info from the ESAPIS.
4 LMOD APIs
4.1 Membership API
...