Re: AbstractUser to get more abstract

Hey Russ, On Monday, September 30, 2013 7:17:14 PM UTC-6, Russell Keith-Magee wrote: > > Hi Rocky, > > On Thu, Sep 26, 2013 at 4:17 PM, Rocky Meza > wrote: > >> >> Hi, >> >> I'm another one of the authtools devs. >> >> On Tuesday, September 24, 2013 6:04:17 PM UTC-6, Luke

Re: AbstractUser to get more abstract

Hi Rocky, On Thu, Sep 26, 2013 at 4:17 PM, Rocky Meza wrote: > > Hi, > > I'm another one of the authtools devs. > > On Tuesday, September 24, 2013 6:04:17 PM UTC-6, Luke Sneeringer wrote: >> >> Good evening, Russell, et. al., >> This is a problem that we ran into with

Re: AbstractUser to get more abstract

On Wed, Sep 25, 2013 at 8:04 AM, Luke Sneeringer wrote: > Good evening, Russell, et. al., > I had some time this afternoon. :-) Since there are already a couple of > reference implementations for how to do this with an e-mail app, I decided > to take a crack at an

Re: AbstractUser to get more abstract

On Sep 26, 2013, at 2:17 AM, Rocky Meza wrote: > This is a problem that we ran into with authtools, what we ended up doing was > just running the tests 3 times[1]. I don't think this is a realistic > approach within Django core though. One of the main problems with this

Re: AbstractUser to get more abstract

Good evening, Russell, et. al., I had some time this afternoon. :-) Since there are already a couple of reference implementations for how to do this with an e-mail app, I decided to take a crack at an implementation that would include an EmailUser within the base auth app. I understand we've

Re: AbstractUser to get more abstract

Hello all, this thread as gone so fast that I didn't manage to catch up and jump in time probably, but I did write a contrib app for Email-only user model: https://bitbucket.org/3h/django-accounts My experience: I had to copy-paste a LOT of code to be sure all works, definitely much more that

Re: AbstractUser to get more abstract

On Sat, Sep 21, 2013 at 5:49 PM, Timothy Anderegg < timothy.ander...@gmail.com> wrote: > >> >>- I believe that we should add an AbstractEmailUser as a subclass of >>AbstractBaseUser, and make AbstractUser subclass it. >> - So, right now we have AbstractBaseUser -> AbstractUser ->

Re: AbstractUser to get more abstract

> > > >- I believe that we should add an AbstractEmailUser as a subclass of >AbstractBaseUser, and make AbstractUser subclass it. > - So, right now we have AbstractBaseUser -> AbstractUser -> User. > - My desired hierarchy would be: > - AbstractBaseUser > -

Re: AbstractUser to get more abstract

I'm taking several different e-mail replies and attempting to conglomerate them. Please forgive me if this is not considered socially acceptable here. On Sep 20, 2013, at 8:42 PM, Russell Keith-Magee wrote: > We have two key questions here: > > 1) Where does the new

Re: AbstractUser to get more abstract

On Sat, Sep 21, 2013 at 3:49 AM, Timothy Anderegg < timothy.ander...@gmail.com> wrote: > Hi Luke - > > I just wanted to clarify the approach I'm using - The issue of whether or > not the EmailUser is in contrib.auth or in a new app contrib.auth_email is > a separate issue from code duplication. >

Re: AbstractUser to get more abstract

On Sat, Sep 21, 2013 at 2:43 AM, Luke Sneeringer wrote: > > P. S. I'm not the sharpest knife in the drawer when it comes to social > things, so I want to state explicitly: I am continuing to debate the > question because I perceive the debate to be moving in a useful way. If

Re: AbstractUser to get more abstract

Hi Gavin, On Sat, Sep 21, 2013 at 12:58 AM, wrote: > > The intention was to mark a particular model as a something that can be > replaced. > > It's hard to find the original rationale behind swappable, but my mental > model was always: > > A model with `swappable = 'x'`

Re: AbstractUser to get more abstract

Hi Luke - I just wanted to clarify the approach I'm using - The issue of whether or not the EmailUser is in contrib.auth or in a new app contrib.auth_email is a separate issue from code duplication. Either way, you'd have to create new versions of UserCreationForm, UserChangeForm, UserAdmin, and

Re: AbstractUser to get more abstract

On Sep 19, 2013, at 11:15 PM, Russell Keith-Magee wrote: > Firstly, it leads to inconsistent usage of API. Under the current scheme, the > default User model defines swappable. No other User model needs to. In your > proposed usage, you've just made a special case of

Re: AbstractUser to get more abstract

> The intention was to mark a particular model as a something that can be replaced. It's hard to find the original rationale behind swappable, but my mental model was always: A model with `swappable = 'x'` means that the model should only be loading if settings.x is set to that same model

Re: AbstractUser to get more abstract

Hi Luke - I just wanted to let you know that I've already started a patch on this, you can see it here: https://github.com/tanderegg/django/compare/ticket_20824_master If you want to reduce duplicated effort, please take a look at what I have so far and let me know what you think! Russ,

Re: AbstractUser to get more abstract

On Fri, Sep 20, 2013 at 12:11 PM, Luke Sneeringer wrote: > > > Sent from my iPad > > On Sep 19, 2013, at 9:24 PM, Russell Keith-Magee > wrote: > > > On Fri, Sep 20, 2013 at 10:53 AM, wrote: > >> > Note that EmailUser *doesn't*

Re: AbstractUser to get more abstract

Sent from my iPad > On Sep 19, 2013, at 9:24 PM, Russell Keith-Magee > wrote: > > >> On Fri, Sep 20, 2013 at 10:53 AM, wrote: >> > Note that EmailUser *doesn't* have a Meta: swappable definition. There is >> > nothing on this model that says

Re: AbstractUser to get more abstract

> On Sep 19, 2013, at 8:06 PM, Russell Keith-Magee > wrote: > > Note that EmailUser *doesn't* have a Meta: swappable definition. There is > nothing on this model that says "I am swappable", or "I am an appropriate > substitute for User". > But isn't that assuming

Re: AbstractUser to get more abstract

On Fri, Sep 20, 2013 at 10:53 AM, wrote: > > Note that EmailUser *doesn't* have a Meta: swappable definition. There > is nothing on this model that says "I am swappable", or "I am an > appropriate substitute for User". > > Ah, this is were the misunderstanding was. authtools

Re: AbstractUser to get more abstract

> Note that EmailUser *doesn't* have a Meta: swappable definition. There is nothing on this model that says "I am swappable", or "I am an appropriate substitute for User". Ah, this is were the misunderstanding was. authtools does actually set swappable on its replacement user, too[1]. The two

Re: AbstractUser to get more abstract

On Fri, Sep 20, 2013 at 2:21 AM, Luke Sneeringer wrote: > But Django already has the mechanism to know not to install the model. > It's the "swappable" Meta option. That is what causes User not to be > installed if it is not used (contra my initial statement yesterday; I was

Re: AbstractUser to get more abstract

Hi Jorge, On Thu, Sep 19, 2013 at 11:45 PM, Jorge Cardoso Leitão wrote: > Hi all. > > I summarise the options with some of the issues raised, and I add my own > concern. > > > One option presented here is to have both models in d.c.auth. As pointed > out by Russell and others,

Re: AbstractUser to get more abstract

Hi Bruno, On Fri, Sep 20, 2013 at 1:26 AM, Bruno Ribeiro da Silva < cont...@brunoribeiro.org> wrote: > Hi, I develop applications in Django and I started to read the developer > mailing list and got interested by this topic about MailUser problem and I > want to add my 50 cents, sorry if I'm

Re: AbstractUser to get more abstract

Hi Aaron. On Fri, Sep 20, 2013 at 8:00 AM, Aaron Merriam wrote: > Russell, my reply there isn't meant to be confrontational and yet > re-reading it I can see it being easily interpreted as such. > No worries - I didn't read your response as confrontational, but I'll make

Re: AbstractUser to get more abstract

Russell, my reply there isn't meant to be confrontational and yet re-reading it I can see it being easily interpreted as such. My intention is to ask whether there is something about swappable that I am missing. It seems to work the way I stated above but your statement seems to imply that

Re: AbstractUser to get more abstract

> > However, if auth.User (or any other model for that matter) is set as > AUTH_USER_MODEL, nothing prevents EmailUser from being installed. > The current behavior of swappable is that if two models are swappable on the same settings value, only the one designated by the settings value will

Re: AbstractUser to get more abstract

On Thu, Sep 19, 2013 at 9:41 PM, Marc Tamlyn wrote: > 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. This is where we have

Re: AbstractUser to get more abstract

> > I'm not sure it was the intention in the design of swappable. I don't know the intended use of swappable, but this seems like exactly the type of thing that a 'swappable' model should be able to do. > However, we still have the issue of different forms, urls, views etc all > based off

Re: AbstractUser to get more abstract

I think you'll find that at least the Authentication form is wrong as well - at least in the sense that it calls the field username and it doesn't validate as an email. Once we get better at html5 fields as well, it won't be the correct input type. Admin registration, the management commands, and

Re: AbstractUser to get more abstract

Whilst this works, I'm not sure it was the intention in the design of swappable. Clever though and it would allow the single-app approach. However, we still have the issue of different forms, urls, views etc all based off the changed model. Making these change automatically would be horrible. I

Re: AbstractUser to get more abstract

But Django already has the mechanism to know not to install the model. It's the "swappable" Meta option. That is what causes User not to be installed if it is not used (contra my initial statement yesterday; I was flat wrong). Right now, User has a meta option: swappable =

Re: AbstractUser to get more abstract

> On Sep 19, 2013, at 11:33 AM, Aaron Merriam wrote: > > 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

Re: AbstractUser to get more abstract

Hi, I develop applications in Django and I started to read the developer mailing list and got interested by this topic about MailUser problem and I want to add my 50 cents, sorry if I'm taking a completely wrong approach, since I never developed the internals of Django. But what if we just add a

Re: AbstractUser to get more abstract

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.

Re: AbstractUser to get more abstract

Hi all. I summarise the options with some of the issues raised, and I add my own concern. One option presented here is to have both models in d.c.auth. As pointed out by Russell and others, this causes the problem on how to define the models such that they are not installed if they are not

Re: AbstractUser to get more abstract

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. This is where we have to special case the new model somehow so it is only installed if we are using it.

Re: AbstractUser to get more abstract

Bah, I should have planned my e-mailing better. Sorry for sending a third in such rapid succession. I just did some checking into my assumptions (quoted below) on this. It turns out that Django core already does some of what I suggest: in particular, it doesn't install the User model if

Re: AbstractUser to get more abstract

On Wednesday, September 18, 2013 6:59:17 PM UTC-6, Russell Keith-Magee wrote: > > > On Thu, Sep 19, 2013 at 8:37 AM, Aaron Merriam > > wrote: > >> Luke, I'm +1 on wanting a solution that allows "just set AUTH_USER_MODEL >> to 'auth.EmailUser', and done". >> >> It'd be

Re: AbstractUser to get more abstract

On Wednesday, September 18, 2013 6:39:13 PM UTC-6, Russell Keith-Magee wrote: > > > On Thu, Sep 19, 2013 at 3:39 AM, Luke Sneeringer > > wrote: > >> I added the authtools approach to the wiki for completion, although I >> believe it to be an inferior approach. >> >>

Re: AbstractUser to get more abstract

On Thu, Sep 19, 2013 at 8:37 AM, Aaron Merriam wrote: > Luke, I'm +1 on wanting a solution that allows "just set AUTH_USER_MODEL > to 'auth.EmailUser', and done". > > It'd be nice if 'swappable' could accomplish this for us. Something along > the lines of for any set of

Re: AbstractUser to get more abstract

On Thu, Sep 19, 2013 at 3:39 AM, Luke Sneeringer wrote: > I added the authtools approach to the wiki for completion, although I > believe it to be an inferior approach. > > One thing I dislike is having a separate app (e.g. d.c.auth_email) that > has to be installed

Re: AbstractUser to get more abstract

Luke, I'm +1 on wanting a solution that allows "just set AUTH_USER_MODEL to 'auth.EmailUser', and done". It'd be nice if 'swappable' could accomplish this for us. Something along the lines of for any set of swappable models which are swappable for the same settings value, only load the one

Re: AbstractUser to get more abstract

I added the authtools approach to the wiki for completion, although I believe it to be an inferior approach. One thing I dislike is having a separate app (e.g. d.c.auth_email) that has to be installed separately. That feels pretty impure to me. I'm doing a thought exercise about potential

Re: AbstractUser to get more abstract

Hi all - I updated Russ's new wiki page to include the work I've done so far: https://code.djangoproject.com/wiki/ContribEmailAuth Again, the patch I've been working on is here: https://github.com/tanderegg/django/tree/ticket_20824_master Please let me know if you have any feedback. The only

Re: AbstractUser to get more abstract

On Wed, Sep 18, 2013 at 1:27 PM, Luke Sneeringer wrote: > Russell, > I would *love* to do the work for the email-login analogue you describe. > I actually proposed just such a thing a few months ago but was rebuffed. > I'm sorry to hear this. Out of interest, did a member of

Re: AbstractUser to get more abstract

Russell, I would love to do the work for the email-login analogue you describe. I actually proposed just such a thing a few months ago but was rebuffed. However, I think this would be extremely useful. Also, I am, in fact, looking to get involved with Django development, as I haven't quite

Re: AbstractUser to get more abstract

Hi all It's great to see this discussion is happening -- however, given that we're debating the merits of different architectural approaches, with the aim of presenting a single approach for final inclusion in Django master, it would be worthwhile formalising the discussion. This is something

Re: AbstractUser to get more abstract

Hi Aaron, The motivation? Simple practicality. contrib.auth ships with a known manifest of models. If you add extra User models to contrib.auth, *every* Django project in existence will gain extra User models -- unless we develop a whole lot of extra infrastructure to *not* install certain

Re: AbstractUser to get more abstract

Russel, I'm curious if you could expand/explain your motivation on having this implemented as a separate contrib application rather than including it with django.contrib.auth On Thursday, September 12, 2013 5:41:29 PM UTC-6, Russell Keith-Magee wrote: > > > On Fri, Sep 13, 2013 at 4:44 AM,

Re: AbstractUser to get more abstract

Hi Jorge - Thanks for the response. Rookie mistake: I had cloned from 1.6.x stable instead of master, the branch is now fixed to be branched from django/master from 10 minutes ago, that should resolve your conflicts. In terms of API, the API I went with is basically identical to the API used

Re: AbstractUser to get more abstract

Up front, I'm one of the developers of django-authtools I'm feel strongly that a new contrib application is the wrong way to accomplish this. Based on my memory of auth and django-authtools, most of `auth` will just work with the AbstractEmailUser class provided by django-authtools. Why not

Re: AbstractUser to get more abstract

Quick addendum: I forgot that django-libtech-emailuser does not use an AbstractUser intermediary step, it simply has one model. My approach has an abstract model, just like auth.User, with a concrete model that inherits from it and is swappable. -Tim On Tuesday, September 17, 2013 10:46:32

Re: AbstractUser to get more abstract

Hi Tim. Thanks for posting this here. I was not aware of this ticket. Thank you also for taking the initiative and starting moving on this front. First of all, like you, I'm also recent in Django dev. This means that most likely, we will both make mistakes in the approach. The important is that

Re: AbstractUser to get more abstract

Why not just override the username class attribute in your subclass ? by None or even something which returns instance.email. In reality I have no idea, some of my users are using their email address as usernames and it's not a problem for django, so anything project-specific would sound a little

Re: AbstractUser to get more abstract

Hey folks - I took a crack at implementing this, please check out my comment here (which contains a link to the branch in my fork): https://code.djangoproject.com/ticket/20824#comment:4 Let me know if I missed anything! Tim On Friday, September 13, 2013 1:03:23 AM UTC-4, Aaron Merriam wrote:

Re: AbstractUser to get more abstract

Check out django-authtools https://django-authtools.readthedocs.org/en/latest/ Provides a few abstract base classes that make this very easy to accomplish. I'm sure there are other 3rd party apps doing the same. On Thursday, September 12, 2013 2:44:53 PM UTC-6, Abdulaziz Alfoudari wrote: > >

Re: AbstractUser to get more abstract

On Fri, Sep 13, 2013 at 4:44 AM, Abdulaziz Alfoudari < aziz.alfoud...@gmail.com> wrote: > This is a continuation of my post on > stackoverflow > . > > With the introduction of Django 1.5, it was possible to

AbstractUser to get more abstract

This is a continuation of my post on stackoverflow . With the introduction of Django 1.5, it was possible to create a custom User model which is flexible enough to have any user profile the developer wants