Permissions system could be even better

[neilmb]

Ticket Description

While working on or discussing issue #544, the fix implemented there could have provided an even better developer experience. To resolve this further development work is required.

As developers, we want a safety net that will prevent developers from adding unprotected views. An added bonus would be a simple interface through which a developer could say "this page requires permission X, Y, and W for users A, B, and C" without messing with the internal workings of the permission system.

We use a lot of different View classes, so without a Ruby-ish way of doing injection into Django's own parent View class, we'll end up subclassing all of them (hence DomainInvitationPermission and DomainInvitationPermissionDeleteView).

Instead, can we set the required permissions as a static constant on each view class. For example, required_perms = ['view', 'delete']. We could then use a tiny custom bit of Django middleware to check for that constant on each request (SO post on how to get access to the class) and raise an error if it does not exist.

In a later iteration of the code, DomainPermission, etc, could become a generic Permission mixin which uses these constants in the same way that Django's own framework uses stuff like template_name.

Issue Type

development

Link dependent issues

No response

[Katherine-Osos]

This may not be quick, but labeled as "quick fix" so it's easy to find.