Closed Bug 1342613 Opened 3 years ago Closed 10 months ago

Create the customized class for User object


(Webtools :: Pontoon, defect, P2)



(Not tracked)



(Reporter: jotes, Assigned: jotes)



Pontoon use default User model for users credentials/profiles. We gradually added new methods and properties by add_to_class() and that started making problems after our migration to latest django version (1.10.5).
The idea to resolve this situation is to migrate our current set of hacks/patches on User to a custom model.

More details can be found here:
Trying to setup a fresh pontoon, I get this traceback:

root@f68e433d8315:/srv/pontoon# python createsuperuser
Username (leave blank to use 'root'): da
Traceback (most recent call last):
  File "", line 20, in <module>
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/", line 367, in execute_from_command_line
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/", line 359, in execute
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/", line 294, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python2.7/dist-packages/django/contrib/auth/management/commands/", line 63, in execute
    return super(Command, self).execute(*args, **options)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/", line 345, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.7/dist-packages/django/contrib/auth/management/commands/", line 121, in handle
AttributeError: 'UserTranslationsManager' object has no attribute 'get_by_natural_key'
David, could you confirm if the changset linked in comment #2 fixes the problem for you?
Flags: needinfo?(david.ascher)
Priority: -- → P2
Flags: needinfo?(david.ascher)
Priority: P2 → P3
Duplicate of this bug: 1473419
After running `make run` and also during deployment, the following message appears:

Your models have changes that are not yet reflected in a migration, and so won't be applied.
Run ' makemigrations' to make new migrations, and then re-run ' migrate' to apply them.

This is confusing for new contributors, and prevents a developer from seeing the actual model changes that require a migration.
Priority: P3 → P2
Assignee: nobody → poke

I'm revisiting my notes and I decided to sync-up with you to gather some feedback:

1. I wonder if it's acceptable to create the custom model called e.g. PontoonUser and make the default User model (via settings and AUTH_USER_MODEL variable)?
This would give us many benefits like e.g. PontoonUser object would be automatically assigned to e.g. `request` object and so on.
I'll try to find a way which will introduce the minimal impact on the database schema.

2. What do you think about possible merge UserProfile model with the future PontoonUser model?

If you have any suggestions how to reduce the size of the future PR, how to split this into phases, see blocking obstacles or have a better idea - feel free to ask/suggest/request :-)
Flags: needinfo?(m)
Flags: needinfo?(adrian)
I'll pass this to Adrian. :)
Flags: needinfo?(m)
@jotes, my only advice would be: don't be too weird. I trust that you know a lot more than I do about those things, so I don't have any better advices. :P I've never dealt with custom User models before, but as long as it's simple to understand and use, I guess it will be fine.
Flags: needinfo?(adrian)
Update status:

I've clearly under-estimated amount of the effort required to fix this bug. I've tried a couple of different approaches.
In the theory, one of possible approaches is to create a custom model and later to update settings of the app.
However, it's not easy to do when you have an existing and running project.

According to this migration guide:

All migrations should be squashed.  The Custom User model should be defined on the very beginning of project.
It's because apps like `django-guardian` rely on User model and their migrations are applied to the current AUTH_USER_MODEL.

Additionally, all references to `django.contrib.auth.models.User` will have to be replaced with `get_user_model()` which makes size of the pull request even bigger.

If you have any ideas/pointers to better solutions - feel free to suggest them.
I decided to look at this problem again, from the fresh perspective. So, it looks like django.contrib.auth creates a migration because of this line

After the migration engine detects new manager, it generates a migration to add this new manager to User mode.

It's okay to close this bug, the solution will be provided in the follow-up bug (if it will be easy to implement).
Thank you for you looking into it, jotes!
Closed: 10 months ago
Resolution: --- → WONTFIX
See Also: → 1520050
You need to log in before you can comment on or make changes to this bug.