Dynamic Course Configurable EC calculation

[robwaz]

Note: This PR is coupled with the corresponding sensai changes which use the added API endpoints.

API changes

• Add new API endpoint for bot to use to submit liked meme events
• Add new API endpoint for bot to use to submit thanks events
• Add new API endpoint for bot to get individual thanks count
• Add new API endpoint for bot go get individual memes count
• Add new API endpoint for obtaining thanks leaderboard

DB changes

• Adds DiscordUserActivity, a generic table tracks actions users can apply to each other such as liking memes or thanking each other
• Adds several methods to DiscordUser to query DiscorduserActivity
• Adds start_date to Dojo object, which currently returns first earliest visible module as a proxy for course start

Course Grades page Changes

• Adds assignment type helpfulness and memes
  • Both of these have an optional, but necessary max_credit property
    • sets individual max limits if course requires
    • Default is 1.00 max (100% of course)
  • helpfulness has a functionally required method property identifying the calculation method to use
    • Current valid values:
      • 1337log2 uses 1.337 ** log2(thanks) / 100 with a hard cap of max_credit if set
      • log50 uses log50 approaching the max_credit value
• Adds course.yml course level property ec_limit
  • Serves as a dynamic global cap on the total earnable extra credit (across thanks, memes, and extra)
  • Extra credit values on the grades page will be dynamically reduced to ensure total cannot exceed this threshold
• Adds dynamic progress indicators for helpfulness (total count) and memes (week ranges)
• Meme and helpfulness grade time frames are calculated as dojo.start_date (described above) to start_date + 16 weeks

I believe this setup is sufficient to represent all currently live ASU EC scenarios based on course syllabus.

[robwaz]

Oh yeah.. and I also made DiscordUser IDs numbers.. because they are.

[robwaz]

Couple things I realized this morning I need to address before merging.

• DiscordAction Timestamp is "time of action", but we also want "time of target message" (ex: when meme was posted)
• Similarly, the meme grade calculation should use "time of message", not "time of action"
• Do we want thanks calculation to be "time of message" as well? Less important, but that'd be consistent
• Update memes and thanks queries to be unique on message_id or (channel_id, message_id). I do think it's worth storing duplicate actions in the DB for accurate data, but de-duping for grades.

[sjzhu]

I have no authority to approve this, but LGTM other than that one apparent typo for the thanks leaderboard calc!

Couple things I realized this morning I need to address before merging.

• DiscordAction Timestamp is "time of action", but we also want "time of target message" (ex: when meme was posted)
• Similarly, the meme grade calculation should use "time of message", not "time of action"
• Do we want thanks calculation to be "time of message" as well? Less important, but that'd be consistent
• Update memes and thanks queries to be unique on message_id or (channel_id, message_id). I do think it's worth storing duplicate actions in the DB for accurate data, but de-duping for grades.

Agree with the first 3 of these. Although I'm not sure what purpose the last point has? AFAICT, all discord message ids are unique, even between channels, so being unique on just message_id should be sufficient?

[robwaz]

Agree with the first 3 of these. Although I'm not sure what purpose the last point has? AFAICT, all discord message ids are unique, even between channels, so being unique on just message_id should be sufficient?

From the Discord API docs

These IDs are guaranteed to be unique across all of Discord, except in some unique scenarios in which child objects share their parent's ID.

You're probably correct that just being distinct on message _id is sufficient. I was not aware the discord guaranteed uniqueness across all of discord (mostly).

[robwaz]

@ConnorNelson any thoughts? I'd like merge this in late tonight.

[ConnorNelson]

Am I confused? Why is this a list?

[robwaz]

This is some insane python thing with the decorator instance holding the limiting value across functions. If it is not a list the value isn't captured in the decorator.

[ConnorNelson]

This is how scoping works inside python, what you're looking for is the nonlocal keyword.

I believe this is what you are trying to express:

def clamp_ec(limit):
    def decorator(func):
        def wrapper(*args, **kwargs):
            nonlocal limit
            result = func(*args, **kwargs)
            clamped_result = min(result, limit)
            limit -= clamped_result
            return clamped_result
        return wrapper
    return decorator

[robwaz]

YOLO