Are there plans to support custom user models in Django 1.5?

[meric]

Currently django 1.5 is in beta.

I've looked over the source. While for some models it is as simple as switching the foreign key to User to settings.AUTH_USER_MODEL, for other parts such as the BaseCheckoutForm where it relies on users having email addresses, it can get more complicated.

What can I do to help?

[matthiask]

Hi,

There aren't any concrete plans yet and I haven't played around with custom user models yet, although following their implementation in Django closely.

A useful first step would be to document Plata's current expectations regarding the user model, and then start the discussion where we could remove those dependencies.

Does that sound reasonable?

[meric]

That sounds reasonable.

[meric]

Here's what I got so far:

foreign key to User: plata/contact/models.py # Contact plata/shop/models.py # Order

reference to User.email: plata/contact/admin.py plata/contact/forms.py # CheckoutForm

reference to User.first_name: plata/contact/admin.py plata/contact/forms.py # CheckoutForm

reference to User.last_name: plata/contact/admin.py plata/contact/forms.py # CheckoutForm

method to User.is_authenticated: plata/shop/views.py # Shop.checkout, Shop.order_from_request, Shop.contact_from_user

[meric]

The User.first_name and User.last_name referenced by plata/contact/forms.py is used for storing the user's first and last names in the shop.BillingShippingAddress model's billing_first_name and billing_last_name attributes.

The django documentation specifies all custom user models must implement the method User.get_full_name() and User.get_short_name().

https://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.models.CustomUser

Can those be used instead of first_name and last_name?

The User.email referenced by plata/contact/forms.py is used as a initial value for the CheckoutForm.

One simple solution to removing this dependency could simply be removing the initial value for the form.

The User.is_authenticated looks to be a compulsory method on all user models as well, so that requires no change.

Perhaps foreign keys to User can simply be replaced by settings.AUTH_USER_MODEL.

[matthiask]

Wow, thanks!

I don't like the differentiation between first_name and last_name too much, it does not work for some asian countries for example.

Maybe we should modify the order models to only save a full name (billing_full_name and shipping_full_name) -- we don't really care about the distinction between given and family name anyway.

About the email address requirement: The email address is used in many places right now, I'm not sure how we might proceed there without rewriting much code or losing functionality.

[meric]

Yes, I've also found there are places where it uses the users' emails to send notifications to them.

Another idea: implement a system where the developer using plata will need to provide a backend for sending notifications to a user; It could be email, or even a tweet if the developer decided to use Twitter's authentication service. It would required a lot of changes though...

[meric]

Anyway, it looks like the first_name, last_name can be changed to use full_name even for Django 1.4. I might have a go at it soon.

[matthiask]

Regarding the backend for emails: Some type of notification backend already exists: The code in plata/shop/notifications.py is only an example, and almost all emails are triggered by sending signals.

The real problem (I see) is the checkout form code...

[matthiask]

Can this issue be considered closed?