I and my colleague (gavinw...@gmail.com) have made some edits to the wiki to clarify the purpose of authtools, and more accurately explain what the 'authtools' approach would look like. If you previously have examined 'option 2', I would ask that you go and reread that section in the wiki.
https://code.djangoproject.com/wiki/ContribEmailAuth The problem you've got here is how it knows to *not* install EmailUser. If > it's a model defined in d.c.auth.models, it will get installed, > irrespective of whether it is AUTH_USER_MODEL or not. I wanted to verify this so I ran some basic tests and turns out that swappable already does the correct thing. If two models have the same swappable value, only the one referenced in settings will be used/installed. This makes it practical to include a second user model in d.c.auth.models without any changes to model loading or the swappable mechanism. Refactoring d.c.auth is a low impact way to facilitate custom user models including and beyond email as username. We would much rather see d.c.auth become more generic and more abstract, than see a new contrib app built specifically for email as username. Russell stated that this issue was more than just about the user model, that it included forms, views, urls, etc. If there is a solution which allows for views, forms, urls, etc to be shared, I would prefer that approach over adding a new app. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
