-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Usage with built-in user model #5
Comments
Same here... You might be able to kludge around it by adding a migration mapping to
But this will likely confuse regular auth upgrades later on and doesn't work out of the box for me:
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 |
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 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. |
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:-
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?
The text was updated successfully, but these errors were encountered: