add admin permission, move from is_staff to permission system

[tybug]

See inline comment for details:

        # planetterp admins are a level between staff users and normal users:
        # admins can view the admin panel and take all actions theiren, but
        # cannot view the django admin panel.
        # Essentially, this role is for site admins which should not have access
        # to the prod db, which the django admin panel grants to a moderate
        # degree.

I did try adding a User.is_planetterp_admin field first, but ran into issues with request.user.is_planetterp_admin erroring when type(user) is AnonymousUser. This wasn't an issue with request.user.is_staff because is_staff is a builtin field on AbstractUser, while we only set is_planetterp_admin on our own User : AbstractUser. Frankly, this seems like bad design by django.

Not happy about using the django permissions system - it has its own warts¹ - but it seemed the easiest and most flexible way to achieve this.

All current staff accounts are also superusers, which have every permission automatically, so there's no need to do anything on the migration side of things.

To assign this permission, use the django admin panel.

Footnotes

1. permissions are inherently tied to a model, so there's no way to declare a site-wide permission like "is an admin". The next best place for it to live is under the User model, which looks strange. Nothing breaks, but it's counterintuitive when adding permissions to users. ↩

[nsandler1]

To clarify, this PR creates one new permission that only excludes the ability to view the django admin panel. Is there a new role for admins who have full access or will that stay as a standard superuser?

[tybug]

I can't imagine a scenario in which we want a distinction between "can access everything including django admin" and "superuser", so I would think that stays as a superuser.

[nsandler1]

I can see the name being a source of confusion down the road so I think the name of the permission should change. Since this will be used by site moderators, "moderator" is more fitting. What do you think?

[tybug]

was thinking the same, I agree "moderator" is a better name here

[nsandler1]

Looks good on first pass. Will do a second pass to actually test everything

[nsandler1]

"moderator" is more fitting here

[tybug]

I've gone with mod, as moderator was quite long.

[nsandler1]

What would be involved in having this permission have the user's is_staff=True but is_superuser=False? This would allow us to continue to use the is_staff check everywhere except in places where we only want superusers, in which case we'd use is_superuser. This would also make it easier to search for users based on if they're staff or not.

EDIT: I realize that is_staff will grants access to the django admin panel, so unless there's a way around that, this idea is moot.

[tybug]

as you said, the issue here is the admin panel. is_staff is also a very stiff permission and would not allow us to split things into multiple permissions in the future if we wanted.

[nsandler1]

Thoughts on making an enum to store the string value? I assume the string won't change, but I think it's more pleasant to deal with an enum than with a string. Also, this would give us more flexibility in naming/updating it.

[tybug]

this doesn't work as well as you might hope because there's no easy way to use this enum value in templates. Currently django populates a global perms variable and does some magic for perms checking:

{% if perms.home.admin %}
...
{% endif %}

I don't even know how this would work with a custom enum. In addition, if we did want to reference Permissinon in templates, we would have to populate the template with our Permission enum, which requires a custom context processor.

I'm not sure the added complexity is worthwhile here.

[nsandler1]

Second pass is good! I didn't encounter any errors and everything appears to work. I'm good to merge once the above things have been addressed.

[tybug]

merge at your discretion, as I did not change the enum suggested above