Hey guys, I can only imagine how busy everyone has been with Django 1.7 and getting that wrapped up with all the great new features it includes. I know I have been spending a good bit of time updating my work.
I know Russell said here that we were thinking it could be put out in 1.7 but I totally understand from all that has been going on that it didn't get released just yet. I looked through and from what I reviewed I didn't see it just yet which is totally fine. I thought it was fairly simple but I can see I certainly don't know enough as I see there are a lot of details that arose in this thread. I'm by no means trying to come off as impatient, just if anyone could give me an update on where things are that would be great as I'm just really curious about this little app and what changes I would then make. If it's not too much to ask and it is even doable based on how things are built I was hoping to put in my 2 cents below: When Russell said "Both auth.User and emailauth.User have relations with Group, and the names clash, so the test suite won't start." I have a comment. My best case scenario preference for the name of the app would be "django.contrib.auth.EmailUser". Would that then solve the issue of the names clashing as then it would be "auth.User" and "auth.EmailUser"? I also think it is cleaner to not put "emailauth" and put the home for both "User" and "EmailUser" in "auth". If anyone has any input on whether this can be done that would be great! Keep up the great work as always, I have been thoroughly enjoying migrations! JJ On Wednesday, February 26, 2014 2:33:24 AM UTC-5, Russell Keith-Magee wrote: > > 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/6b9d75cf-35ad-4b2f-b34f-3e87406e7bf4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
