Are there plans to support custom user models in Django 1.5? about plata HOT 9 CLOSED

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?

from plata.

That sounds reasonable.

from plata.

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

from plata.

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.

from plata.

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.

from plata.

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...

from plata.

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.

from plata.

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...

from plata.

Can this issue be considered closed?

from plata.