Django 1.5 custom user models + South migrations

[Stephen McDonald]

Just a heads up for everyone with regard to an issue that I feel will probably get a bit of exposure coming up:

https://github.com/stephenmcd/mezzanine/issues/592

First up I don't know what the solution to this will be. Basically the problem is:

- Mezzanine contains historical south migrations referencing auth.User

- Someone creates a Django 1.5 Mezzanine project, and wants to use a custom user model

These two things conflict in (seemingly in my mind at least) inconsolable ways.

On top of this, the *fantastic* Profile model feature of Django is now deprecated to make way for custom user models - which Mezzanine's accounts app has always been heavily integrated with.

So the questions are:

- How can we maintain database migrations that reference the built-in auth.User model, and allow people to use custom user models?

- Is the answer to this simply some special workflow needed with South? eg fake these migrations, generate your own separately, etc. (I've no idea yet)

- Do we try and upgrade mezzanine.accounts to be based of custom user models? We can't do this and still support Django 1.4, which we need to do given our general policy of supporting both the current and previous Django versions.

- Profiles are deprecated now. Do we shirk custom user models altogether, and just set up our own way of doing Profile like models? I think this would be trivial and (relatively) painless, but would be costly for Mezzanine perception-wise. Brace yourself for: "Mezzanine sucks, it doesn't support custom user models!!1!".

--
Stephen McDonald
http://jupo.org

[Stephen McDonald]

Can you describe what you're trying to achieve a bit more (the what, not the how) ... there might be a better approach.

On Fri, May 3, 2013 at 5:43 AM, lajarre <alexandr...@gmail.com> wrote:

Hi

Just my 2 cents as a user of Mezzanine:

I started using your CMS just some weeks ago. Pretty awesome.

When I wanted to start creating a user-facing auth system, I opened up mezzanine.accounts and thought "ok, not for me, django now has custom user models, I'll just do that, because (pay attention, VERY good reason to that!) I don't want users to have a username".

I did nearly all, going into the source code and reassured by the fact that you're making a very careful use of django.contib.auth.get_user_model. But then found this thread and the problem with the core 0004 migration. I dropped it all to stop wasting my time.

I must say that it's sad. And I'm probably not the only one who's going to be disappointed.

Isn't it possible to add a migration that just "backwardises" all the previous ones until 0004, then does them again correctly? (I don't master south yet, not sure about what I say).

Thx anyway for the work!

[lajarre]

Yep: I just want to make it so that there is no "username" involved for the user. Signup, login and so on with reference only to the user's email.

[Stephen McDonald]

Cool, I think this is really common. Currently Mezzanine supports login by email - it just so happens it supports either email or username at the moment, and so the labels on the login form indicate that.

There's also a ACCOUNTS_PROFILE_FORM_EXCLUDE_FIELDS setting for removing fields from the signup/update forms - now if you were to add username to that setting, I'm not sure if it would work as desired at the moment, but if it doesn't we should certainly get that working.

Ultimately I think you should be able to do what you're trying to do without a custom user model - most of the work is already done for you.

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Stephen McDonald]

I can confirm just adding username to ACCOUNTS_PROFILE_FORM_EXCLUDE_FIELDS doesn't work quite right - so that's a bug I'll take a look at.

[Stephen McDonald]

I've had a first go at this, any feedback welcome:

https://github.com/stephenmcd/mezzanine/commit/8721d269483438edbdc8cb2d29a1d6e40a0774a0

Just a few tweaks needed to get it working with "username" added to "ACCOUNTS_PROFILE_FORM_EXCLUDE_FIELDS". 

Now the user model still requires a unique username, and with profile views enabled, we also need a username to use as the profile view slug. So I've added code that generates a unique username (first and last name slugified). 

Also if the username field isn't exposed, the user's first and last name are shown on the public profile view (if enabled) instead of their username, and their email address is used in any profile panels (eg you're logged in as X) instead of their username.

I had this working to begin with all stemming from adding "username" to "ACCOUNTS_PROFILE_FORM_EXCLUDE_FIELDS", but since there are a few other bits that vary in this scenario, I opted to add a new setting called "ACCOUNTS_NO_USERNAME" (defaults to False) to control it all.

[lajarre]

There is an error at signup:

=> https://github.com/stephenmcd/mezzanine/issues/664

Maybe something to do with commit=False in ProfileForm.save?

=> https://github.com/stephenmcd/mezzanine/commit/8721d269483438edbdc8cb2d29a1d6e40a0774a0#commitcomment-3180863

[Stephen McDonald]

Thanks - fixed here: https://github.com/stephenmcd/mezzanine/commit/c77f3693478b0de2ea0682ae4f299933384e9c55

[Alexandre Hajjar]

Awesome, thanks a lot. Seems to work perfectly for me now