Auth user

[anastasia]

• APIUser is now CapUser
• AUTH_USER_MODEL is now CapUser
• DRF's Token model insists on using AUTH_USER_MODEL as its user field, so this means we can drop our implementation of it (APIToken is gone)
• CapUserManager now has a create_superuser method
• is_superuser and is_staff have access to admin. is_staff can see capapi models (currently just capuser). is_staff can authenticate capusers.

This pull request requires a long and arduous merging process, since Django is not friendly to changing one's mind about AUTH_USER_MODEL mid-project (https://docs.djangoproject.com/en/2.0/topics/auth/customizing/#changing-to-a-custom-user-model-mid-project).

This patch requires that we cleanly drop all users and have people re-register which is something we can get away with since we are early in the process with cap api (assuming we have ~3 users, all internal). This is a major change but if we don't start from a clean slate, making these seemingly mundane alterations to users will become an uphill battle. The below steps will outline this recommendations.

Here are the steps, as best as I can ascertain, since there were several false starts with this (see this for further information: https://code.djangoproject.com/ticket/25313):

• pg_dump everything, everything, everything
  truncate django_migrations;
drop table "capapi_apiuser" cascade;
drop table "capapi_apitoken";
drop table "django_admin_log";***
  drop table "authtoken_token";

*** locally, the only admin changes I had were of authenticating users. This step will not be right if the django_admin_log table is used for anything important.

make sure ./manage.py showmigrations shows that nothing is migrated

• with the new migration included in this PR:
  ./manage.py migrate capapi
./manage.py migrate admin —fake-initial
./manage.py migrate

[jcushman]

Nice work! Agreed it's a hassle, but I think it's a good plan.

One tweak -- the init_db function in fabfile.py is using Django's User model and needs to change to CapUser.objects.create_superuser('admin@example.com', 'admin').

For the merging process, I think we can just do this before deploying:

./manage.py migrate capapi zero
./manage.py migrate auth zero

And then deploy normally (check out new code, migrate). I tested this locally and it seems to work. It does essentially what you listed above -- drop the tables related to the capapi and auth app, and delete their migrations from django_migrations.

[bensteinberg]

The deployment process looks pretty hectic. Thanks, @jcushman, for the simplification.

(Approved pending the change to fabfile.py)

[bensteinberg]

A further comment: before merging this, I will do the zero migrations on dev. That is, please let me merge this one.

[anastasia]

That's excellent, @jcushman, I didn't know about migrate zero. Such an improvement over my painful process