Why does account.models.Account still exist?

[irothschild]

It would make sense for Pinax to easily allow new fields to be added to the Account model (see #60 ) so that account settings can be stored together and edited and saved from a single form/view. Since the recommended way is to instead put fields in a custom User model, why have an Account model anymore? Why not just move the timezone and language into a Custom User model that we can inherit from?

Has the django community really not addressed the need to be able to subclass models, forms, and views and just have them work?

[jtauber]

This is worthy of further discussion. Some thoughts to include in such a discussion...

There is a school of thought that says that the user model should just be used for authentication and any other information should be in a different model (@brosner is that the heart of what you were saying the other day?)

I think it's useful to distinguish:

• fields necessary for authentication
• (private) account settings
• (public or semi-public) profile information

so the question is one model, two models or three?

[irothschild]

I tend to agree with keeping the auth User model just for auth so would favour a 2 or 3 model solution. However, it would be wonderful if there was an easy way for any app to be able to add new fields to the settings/profile model and form. Yes, there could be conflicts but I see that as an opportunity to share the same settings across apps. Pinax-compliant apps could have a registry of known settings fields with their defined valid contents.

[jtauber]

Yeah, I definitely want to keep this conversation going. Lots of good stuff could come of it.

[the-chris-mitchell]

Was any progress made on this? I realise we can subclass 'Account', but that would involve a bit of work (having to subclass all forms and views that refer to it). It would be really awesome if we could have something similar to the 'AUTH_USER_MODEL' option but for the 'Account' model.

[jtauber]

@eldonuts what is the nature of stuff you're wanting to add?

[the-chris-mitchell]

@jtauber specifically I was wanting to add additional region fields, such as Country and City.

[PoDuck]

I'm assuming that actual custom user models, as in using django's built in support for them, are not implemented. I see mention of "custom user model" in several places, but nothing seems to be actually done in regard to the django custom user model. Has this idea died?

It seems to me that it would be best to implement that, and allow people to do whichever they want, in terms of either storing information in another model or not. It would certainly make it easier to deal with the duplication of fields, as in storing a username and email address for those using email logins. As it is now, we don't have a choice, since attempting to use a custom user seems to break things.

[jtauber]

@PoDuck If there are bugs in custom user models (i.e. AUTH_USER_MODEL), that's a separate issue than what is being talked about here.

[PoDuck]

Is my assumption that AbstractBaseUser is neither implemented nor supported wrong, or is my implementation wrong? If it is the former, I gave my reason for not only supporting custom user models, but going completely to a custom user model. If it is the latter, I appologize.

In other words, I was discussing what the original post was talking about. Or at least I thought I was.

[jtauber]

The original post is asking why we need Account given the ability to have custom user models.

I had proposed that user models be restricted to auth purposes only (so custom user models are still relevant) and that Account be maintained for private account settings. @irothschild agreed with this division but asked for ways we would make it easier to extend Account.

If you're having problems using a custom user model, we should fix them, but it would be better to file issues for them separately and keep this issue for discussion about how to better extend Account for custom private account settings.

[PoDuck]

My question is, why should it be so limited? A custom user model as a base could be left as authentication only if desired, but could also be extended easily if desired. I'm not grasping why it should be so opinionated. Is there something that I'm missing that it would cause problems with?

[jtauber]

I am confused by what your actual issue is @PoDuck. At first you seemed to be saying you were unable to use a customer user model at all. Let's fix that (by filing a separate issue).

I'm not sure what that has to do with the justification I've given here for keeping auth, account settings and profiles separate (which is what we've done on Pinax sites for 9 years, btw) and the call for how to make things like account settings and profiles more extensible if separate models.

If you don't like that best practice, that's fine, you can just avoid this discussion; but please report actual bugs you're experiencing with custom user models separate from this issue.