enrollment type definition and permission in config

[lsloan]

Problem

When the team discussed adding support for librarian and assistant enrollment types, which resulted in opening #333, I realized we have support and redundancy problems for all types. It should also be customizable for other environments.

1. Support – Whenever enrollment types are added (or removed) from Canvas, it will require updating various parts of the code. Multiple enumerated types will need to be changed.
2. Redundancy – The enrollment types appear in the code for the UI and the API. The code in the two places are very, very similar.
3. Customizable – When this application is put to use on other organizations' environments, the enrollment types used by them and the permissions they want to grant them may be very different than those in use at UMich.

Solution

Add enrollment types to the application configuration. It may be in the main configuration file or it may be a new file. The enrollment type configuration should contain enough information to define the possible types available and enough hierarchy to define what types may be assigned by a user of a given type.

This enrollment type configuration should be available to code running in the UI and the API. If there are difficulties to getting the configuration to the UI, a new API entry could be added that provides the configuration to the UI.

The code used to handle enrollment types should be available for use in the UI and the API to reduce redundancy and ease maintenance.

[ssciolla]

I agree this is a problem (the similar but different code across the front and backend), but it may not be solve-able for the initial release. I am not sure about full configuration, but certainly sending role data to the frontend makes sense to me. I will start thinking about it as time allows. I believe we can make it functional with the current approach.

[lsloan]

I agree, it may not be important enough to address this before the first release.

Also, since I wrote it, I thought of another reason this should be addressed eventually: Allow for customization when used by other organizations.