Currently, the app assumes all users and all admins are using EST, but that won't always be true. This issue consists of a few steps:
Ensure that the datetimes displayed to the user match their timezone. If a playlist is due at 23:59 EST, it should (for most days of the year) display as being due at 4:59 AM the next day for someone in the UK
Add the ability for course owners to change their course's master timezone. This would involve adding a new model & form field, along with changing all the settings.TIME_ZONE calls to match the time zone of their respective course.
There's lots of methods/properties on each model that are either no longer used, inefficient, redundant, and almost all of them are poorly documented. To fix this, it'll be necessary to look through each model and carefully look through all the methods. This is an area where documentation would be key.
Remove migration code that depends on variable model methods (properties not in the database itself)
Combine and rename migrations to streamline things
The goal should be to have migrations that function even if we had to delete the database and start fully from scratch with the current code in the repo.
Currently, exercises that have already been performed in a transposition are not being marked as locked. This presumably has something to do with the changes to transposition in the models. Figure out why performing a transposed exercise doesn't lock the exercise, fix it, and write a migration to search through PerformanceData for exercises that are erroneously unlocked and lock them.
when an object has been deleted, when an exercise or playlist has been performed in preview, or when sometime attempts to add an exercise while not logged in, or similar situations.
Fix display of performances in instructor CourseActivityView, lots of erroneous readings
Figure out better enforcement/updating of performance_dict in cases such as playlist reordering, deletion, user data switching, subscribed group editing, etc... This will probably involve Django interceptors or similar query side effects
Likely involves coding new django Form that uses the same block text fields as before, with more complex cleaning functions to convert the results into the new M2M relationship.
Currently, some datetimes are handled by the builtin datetime module, others are handled by the external pytz module, and all of them kind of differ slightly, and there are a variety of methods and functions that deal with datetimes, many being legacy code. Ideally, there should be a method on the playlist/course model which is a single source of truth for all due dates and publish dates.
Currently, the bass is not being respelled, though hEnharmonicAlterations returns the correct note name. To observe this behavior, choose "No key" and build two M3 intervals, first below Eb (which is respelled to D#) and second above Gb (which is not respelled to Ab as it should be). The analysis matches the staff notation, so there are no visible errors, but the "no key" environment is designed to interpret intervals as well as chords as simple diatonic objects, with appropriate respelling of the constituent pitches.
Instead of hacking together the field with extensive and inflexible (and hacky) changes to the template, create a custom widget with custom javascript that would speed things up, improve flexibility, and allow for more intuitive behavior like drag and drop.