wildfish/django-gdpr-assist

Usage with built-in user model

bodgerbarnett opened this issue · 4 comments

I have an old codebase which still uses the built-in Django User model as a base.

If I add the following code to (actually, where should this code go?!) a models.py somewhere:-

class UserPrivacyMeta:
    fields = ['first_name', 'last_name', 'email']

gdpr_assist.register(User, UserPrivacyMeta)

then makemigrations makes a new migration in the django section of my virtualenv, which of course isn't part of the git repo so isn't committed, which in turn means that it has no effect on the code when I run it on the live system (unless I run makemigrations on there).

This all seems a bit wrong somehow to me. Am I doing something wrong? Is there another way to do this?

squio commented

Same here...

You might be able to kludge around it by adding a migration mapping to settings.py:

MIGRATION_MODULES = {
    'auth': 'my_app.migrations',
}

But this will likely confuse regular auth upgrades later on and doesn't work out of the box for me:

python manage.py makemigrations auth
CommandError: Conflicting migrations detected; multiple leaf nodes in the migration graph: (0006_auto_20190502_1358, 0007_auto_20190503_0927, 0008_auto_20190506_1149, 0002_auto_20190415_1014, 0010_profile_pin_failures, 0009_auto_20190508_1443, 0003_lap_session, 0013_site_name_20190705_1126, 0004_auto_20190429_1400, 0011_auto_20190618_1108, 0005_auto_20190430_1039, 0012_auto_20190620_1326, 0001_initial in auth).
To fix them run 'python manage.py makemigrations --merge'

Which I find way too scary.

A better solution anyone?

maybe it's somehow related to #6, just published a new related issue

However, I've not been able to replicate your issue for case when using custom User inheriting from AbstractUser

As far as I understand there's no way to cleanly achieve this without defining a custom User model in your project because gdpr_assist will need to add an anonymised column to each anonymisable table in your DB, and interact with it via the ORM.

It's not ideal, but it is considered best practice in newer versions of django to start projects with a custom user model anyways so it could be worth it to migrate. I have a pretty large old codebase and was able to migrate to a custom user model relatively painlessly.