Pending feature requests and ideas [draft]

These are some keywords ideas that were written down over time and needs to be developed, sorted and discussed, and then placed into the roadmap if selected.

• High availability backend: no more single node queue
• Integrated file versioning: serving git repositories instead of (or alongside with) webdav
• Abstract course and refactor existing features in : Course, Exam, LTI, ... with a set of supported features per type (Groups, audiences, ... are not relevant for all types)
• Migrate the YAML files to database to improve I/O and allow usage of a database-object model (mongoengine ?). Beware of the translation files that also have to be put in DB to avoid intempestive disk I/O.
• Refactor code to allow easy unit testing. That means isolating logic and rendering to the max and concentrate on logic testing first.
• Better handling of server protocol in init script (integrated, FCGI, WSGI, ...)
• Allow for rich feedback: returning files to the student in a proper and clean way, instead of base64 links, adding additional JS for animated feedback...
• Allow course administrators to see what audiences/groups the users belongs to from the main user page (#253).
• Automatic student assignements to groups, group assignment improvement (linked to #88)
• Studio : duplicate tasks (#179)
• Studio : grouped actions on several course tasks
• Transforming staff to students with additional permissions. This would make some code cleaner and more robust, such as the submission download form (#204).
• Improved user management: allow to manage the users from the interface from a superadmin point of view (#165) This would include user fields, but also user submissions that are sometimes asked by course administrators who cannot delete student submissions. We should also be able to delete bindings easily in case of issues.
• Convert most options from configuration.yaml to dynamic DB-stored options, to avoid restarting the app when not required/wanted (adding superadmins, maintenance mode, ...) (#111)
• Allow tutors (or users with additional permissions) to access the course files in a read-only mode. (#282)
• Readable tasks for students before the submission opens, a.k.a. "you can submit from XX/XX/XXXX".
• Improved API: use API key to log in to the API. Or even better: OAuth with access tokens, but adds complexity to the client. (#185)
• Allow for custom flags set by the course admin and passed to an exercise/course. For instance, a debug flag, or a flag to run only a part of the tests, instead of letting the task to the course admin in each of their run files. (linked to #103). This could be built, at the course scope, upon the student course settings features, and add a student (local) or staff (global) field so that the latter are not modifiable by the students.
• Job notifications : opt-in to send email or push notifications to the user when the job is done. This is pretty useful on very long evaluations.
• Judges : allow the course administrator to specify containers layers on top of the environment, with common files or complete "grading" solution. Run files can be launched from the common folder now, this feature actually corresponds to a set of files. This is probably a way to deprecate and migrate the current $common folder automatically.
• Allow access to social bindings additional fields. This to allow univeristy course administrator to fetch an official student identifier instead of the INGInious username or email. (The solution must comply with privacy protection)
• "Time t" state : allow using the current submission state as input when a replay is performed. This could be useful in case the of the information is accessed from the internet during the grading process, to cache it in case it wouldn't be available anymore, or in case it was modified.