ospreyelm / analyticpiano Goto Github PK

• 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.

• 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

Improve error handling and stop returning general 500 errors for such situations as:

Course.DoesNotExist /ajax/exercise-performance/Z
Group.DoesNotExist /dashboard/courses/{course_id}/Z
Playlist.DoesNotExist /playlists/{course_id}/{playlist_id}/Z
User.DoesNotExist /exercises/add/Z

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.

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.

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.

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.

Search for unnecessary for loops or database requests, particularly in the handle_m2m code

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.

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.

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.

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.

Mainly for the sake of style and cleanliness