backend: Store configurable values inside a course_settings table

[frozenfrank]

Description

Some kinds of parameters we want to be configure dynamically. This can we well accomplished with a course_settings table that has a column for each of the settings we want to configure. Then, the app will read out the appropriate settings and behave differently just by updating the values but without rebuilding the app.

In the code, we'll want to access these through a CourseSettingsService (or similarly named) by the name of the property. This would allow us to potentially configure different sets of values that we could switch between. For example, one row of settings could contain the PRODUCTION settings, and another row could contain DEV settings which have have slightly different end points or behaviors for some properties. We could also build in a file of defaults so that we aren't required to define all of them in the database if we want.

Properties

• Canvas API Key
  • Canvas Test Student ID
• Assignment ID's for the different phases
  • Rubric item IDs for various rubric items
• Late penalty configuration
  • Late penalty percent per day
  • Late penalty max days
  • List of Holidays
• Course Slack API details for sending messages (future)
• etc...

Please comment any other properties that would be good to include in the course_settings table.

[19mdavenport]

The Canvas Test Student ID resets every time someone hits "reset student." I think the way Paul added that gets it new every time we need it is probably sufficient.

Canvas API Key is currently passed in as a environmental variable, do we need one per course?

[pawlh]

Canvas API Key is currently passed in as a environmental variable, do we need one per course?

I don't know about per course, but iff #164 happens then I think it would be super useful to have this in the database instead

[pawlh]

Another class of properties that should be included:

• weights of rubric items. e.g. _PHASE_3_UNIT_TESTS=.3, PHASE_3_PASSOFF_TESTS=.7_, etc.

[pawlh]

I added this with #323, but I'm not going to close this ticket because it can probably improved on