Hi all, tl;dr; I've been working on a last little feature for 1.7 - an email-based User model for contrib, but I need some help/guidance on the last step - getting the tests working.
The idea here is that we just ship a normal auth.User, but with email identification rather than username. This is essentially the 80% case for requests for custom User models anyway, and it provides an example of "how to do it" for anyone that wants to follow the lead. I've also taken the opportunity to do a bit of refactoring of auth forms and the AbstractUser to make re-use of common parts a bit easier. Code is available here. Other than bikeshed stuff (name of module, name of classes etc) it shouldn't be too controversial: https://github.com/freakboy3742/django/tree/emailauth There are two things still pending on this patch: 1) Documentation. There isn't much to document, but obviously this is required. 2) Tests that work. It's the second point where I need some assistance (or at the very least, some suggestions of directions I can go with this). There isn't that much that requires testing -- after all, it's a fairly vanilla User model. A bit of light testing of forms, some checks to make sure that the models can be created, and that they play well with ModelBackend, and so on. However, there's a problem with including these tests as part of Django's own testing infrastructure, due to clashes with Django's default User model. In a production app, you either want a normal Django User model, in which case you don't include contrib.emailauth in your app; or you include contrib.emailauth, and you set AUTH_USER_MODEL must be set (I haven't added a formal check for this, but I could). As a result, there's no confusion over which User model is active. I've done some manual testing, and the user model all works as expected. While running Django's test suite, however, the suite installs both contrib.auth and contrib.emailauth, but *doesn't* set AUTH_USER_MODEL to emailauth -- it can't, because we need to test default User behaviours. Both auth.User and emailauth.User have relations with Group, and the names clash, so the test suite won't start. If you deliberately silence the model integrity system checks, you get other errors, caused by the fact that there's confusion over which AUTH_USER_MODEL is active at any given time. So - I'm looking for suggestions for how this can be handled in Django's test suite. I've thought about explicitly excluding contrib.emailauth from the test suite's INSTALLED_APPS, but then the tests in emailauth don't get discovered and executed. Even if you reorganise the tests to make them part of the "django" tests, rather than tests that are part of the contrib app, you get problems because you end up with two models with the same relation name to Group. So - anyone got any ideas how to handle this? Is there some feature of the new app loading code that I can exploit here? Yours, Russ Magee %-) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_9X%2BjyAu01c1%3DPTj17Co520VH2vo16fqOOv9s_c0tweg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
