There are a standard set of roles in ELMSLN that are automatically created in every system. These can be built upon though it is recommended to make sure that these new roles - don't change names after creation (unique IDs are built automatically off of these names as a hash) - Are loaded up in CIS viahook_cis_service_instance_options_alterso that all other systems produced have consistent roles (unless this role is a one-off)
The standard roles are (in order of escalation, generally speaking): - anonymous user - authenticated user - guest - past student - student - teaching assistant - instructor - staff - SERVICE ACCOUNT - administrator
Role scope is per authority / service instance. For example, I might have the administrator role in themedia.elmslnaddress, be an instructor in courses.elmsln/sing100 but a staff member in studio.elmsln/sing100. This is because all 3 of these systems are different drupal sites, allowing for maximal role delegation.
This also ensures that permissions are containerized. In this way, theaccess contentorcreate page contentpermissions could be different from one site to the next. This could be useful if you wanted to modify whatinstructorrole can do in Sing100 while keeping it at the baseline in Progress 101.
It is recommended that you capture any permission changes you make viafeaturesor some other configuration management mechanism when you change the connotation of what someone can do. For example, if students can create group content in a Art 100 because you added a wiki content type and they need edit rights on it, then make sure to capture this new innovation in order to share it with others, but also so you don't lose configuration during upgrades.