Next year, the SSO module should change from core schema to system schema tables and start supporting a list of roles.

Hierarchical roles should be considered especially, since PostgreSQL seems to support similar hierarchical queries that Oracle's does.

Access checking member functions for hierarchical roles need to be created for the application.

When student submits a GitHub account in /register.html, possible previous submissions should be checked and the course GitHub account should leave from a possible redundant repository.

Covers both cases:

• Student submits a new account, the previous collaboration is not needed.
  solution: remove collaboration
• Student submits the same account again but cannot send new invite if the course account is already collaborating.
  solution: remove collaboration

A. Remove it (perhaps not recommended - UNLESS, we start allowing SAVE-and-continue-later type of thing)
B. Provide sensible error message to the assistant.

Integrate prerequisite testing into this system. Follow the existing manual implementation.

This is especially important, if the system is to support on-going and own-pace courses. But this is equally useful for things like lending out component kits, which can (and usually will) be returned after the course period has ended.

We currently work exclusively with GitHub, but should look into supporting GitLab, at least the university's own instance.

This however, is a low priority issue, since this system currently has no other users except the embedded courses.

System should support group forming (by students grouping themselves) and automated division into groups.

This feature should be open to data from prerequisite test results that gauge each students strengths and weaknesses, to form groups that would have at least one person to cover each area.

GitHub account are case insensitive, and GitReg should follow this.

"Handler" is not a very good way to classify assignments as some are handled by number of subprocesses, instead of just one ("HUBBOT", for example).

Type is not reserved word and can be used as a column name.

Table (core.handler) existed mostly for descriptive purposes, but may not actually be necessary - or at least, not until teacher UI is being created. Until such time, perhaps it is better to go with just a CONSTRAINT assignment_type_chk CHECK (type IN ('MANUAL', 'GIT_REGISTER', 'GIT_SUBMISSION', 'APLUS_QUIZZ', 'ASSET_LOAN'))
Column: type VARCHAR NOT NULL DEFAULT 'MANUAL'

Download failed: status code 500 Internal server error - see logs! Path '/srv/schooner/submissions/DTEK0002-3002/jasata/E04/accepted' either does not exist or is not a directory!

When the trigger is of type "file", archival should be handled differently. (Note: file-type is necessary to facilitate reports and other monolith submissions like installable distribution packages etc.)