Implement more graduated permissions

[czlee]

Currently there are pretty much three levels of access: no-login (public), login (monkey) and superuser. In general this works fine. But there are probably some superuser functions which should not actually grant access to all other functions too. For example:

• Ballot check-in should be its own type of thing.
• Displaying the draw (before public release) should be its own thing too, lest someone accidentally display confidential info to the projector screen in GA.
• Adjudication cores should probably have less permission than tab directors (other than staff access). For example, they probably shouldn't be able to edit ballots in the same way that tab directors can.

Groups are built into Django, but obviously we'd need to standardize them and have some sort of framework for them. This isn't really high priority, it's not as if it's created headaches in previous tournaments.

[tienne-B]

This could tie in well with #502, where the password used can determine what group to place them.

[tienne-B]

A Django package would have to be added to manage these permissions as it seems that Django's built-in permissions system is only database-level. What more, there shouldn't really be a "Can edit ballots" permission but a "Can edit ballots in this tournament" permission. They should be tied to a Tournament object because many tournaments can be supported on the same instance, but their staff may differ.

Permissions should be defined by application; groups combining various permissions from the applications (applicable to one or many tournaments). As an example, the "adj core" group could include permissions such as:

• Create/Edit/Delete motions
• View motion statistics
• Create/Edit/Delete adj feedback
• etc.

The permissions should be really granular to allow for precise groups and to not give too much power where not needed. A difficulty I'd see is that not all tournaments would want the same permission set for different groups, but having a general set, and it being customizable by super-users (of a tournament?) could be available to have full control.

[tienne-B]

There could be a renewed interest in this task with the API. Currently, authorization follows the simple rule of allowing only superusers credentials, with authentification done with username/password. For security, the full credentials with full access shouldn't be used, rather permissionned tokens (OAuth or bearer).

Another consideration, which is not new but not really explicit here and enhanced with the API, is the integration of Tabbycat within other officials' teams' workflows, such as with registration for participant import. In this case, a tab official may want to give an API token to integrate Tabbycat import with a registration system, but without giving full access to the registration officials.

However, this task touches on three distinct ideas:

• Model-level permissions
• Object-level permissions
• API tokens and authentification/authorization