Re: subclassing UserCreationForm

[Jason]

> Well, first I can to "if X == Student: ...", and I know the fields will be
> there.
> Second, User will have no additional properties (as I understand), but once
> I do "Model --> User" relations ALL users will have that property. So each
> user might have the .course property, AND the .subject property (which might
> be for teachers), AND the .function property, which might be for
> administrative staff (I'm making things up here :). So all properties would
> be present, they may not be mandatory, cause a teacher is never part of a
> course, so I have to ensure data consistency in the application logic. That
> sucks.
>
> Subclassing relieves me from this just nicely, AND this is the mother of all
> prototype examples of OOP - base class, specialized subclasses. The only
> thing more cliché would be "Car" -> "Van" / "Compact" / ... .

I subclass a lot of stuff in Django. It's useful, I agree. I'm ALL
about OOP.

My gut tells me to leave that stuff out of Auth.User.  If you were
extending the authorization / authentication aspects of it, I would
agree. You're adding courses though which does not at all sound like a
good idea to me.

Course should be a model and it should have a manytomany field for
users or other intermediate table if you need more attributes on the
relationship itself.

"Well, first I can to "if X == Student: ...", and I know the fields
will be there."
You can do that as well with groups by adding the information as they
are added to the group. (signals, etc).

"...but once I do "Model --> User" relations ALL users will have that
property."
Well, all users will be able to query the attribute but it will just
be null.

some_dude = Users.objects.get(username='the_dude')
courses = some_dude.course_set.all()

Anyhow - the real deal breaker for me is overlapping user types. If
that's not a problem, you'll probably be fine in making it work.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Axel Bock]

2010/9/24 Jason 

>
> "Creating the relationship between User and UserInfo has some
> implications I'd like to avoid on a model-level"
>
> Specifically what are you referring to here? Because anytime you
> subclass in Django you are basically doing the exact thing in the
> database behind the scenes and as result accessing the data turns out
> to be pretty similar (just about as easy both ways).
>

Well, first I can to "if X == Student: ...", and I know the fields will be
there.
Second, User will have no additional properties (as I understand), but once
I do "Model --> User" relations ALL users will have that property. So each
user might have the .course property, AND the .subject property (which might
be for teachers), AND the .function property, which might be for
administrative staff (I'm making things up here :). So all properties would
be present, they may not be mandatory, cause a teacher is never part of a
course, so I have to ensure data consistency in the application logic. That
sucks.

Subclassing relieves me from this just nicely, AND this is the mother of all
prototype examples of OOP - base class, specialized subclasses. The only
thing more cliché would be "Car" -> "Van" / "Compact" / ... .

I might have a look into groups, but I need certain properties for the
users. Groups seem to manage the database permissions just fine, but I'm all
in for class / instance properties.

The best part is: In theory it is all VERY simple: The subclassing works
just fine. It even seems to run a feature of Django - subclassing of models,
since version IForgotWhich. Also the model behaves just as expected, the
database looks like it should. But then I run into trouble because I cannot
display ONE --CENSORED-- FIELD as of now in the admin "create" interface.
And so far no one was able to give me an answer, although I found examples
on the web - unfortunately they don't work here. And everything I try simply
does not work with the magic of that --censored-- UserAdmin manager. (Yes, I
am a bit frustrated here).

Right now I switch between two different Admin classes to create some test
users, which SUCKS.

I surely *cannot* be the only guy who does things like this, or who came up
with that idea. Can I? I mean, I posted the articles of other people,
who did just the same, right??

Although I still like Django, cause I really just started with it. But ...
well, my patience is getting a tiny little bit thin, if I don't get some
little successes out of it soon.



So --- am I right? Specifically about the "All users have that property
then" part?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Jason]

Don't get me wrong - I'm not saying my way is right and I'm not saying
anyone is doing anything necessarily wrong.
I'm still a Django noob in a lot of ways.

Just things to keep in mind - if you do have multiple types of users
subclassing might be a bad idea if there are possibilities of being
classified as more than one.

"A user can be created without attaching the UserInfo information (I
did
this already, and unless I did something wrong, I could do just that).
So I
have to add application logic to make sure that a Student actually has
a
UserInfo object attached. Also because of my different system users it
would
make no sense to actually attach that to EVERY user"

I think here you're going to have about the same amount of work no
matter what method you go with. You can use save signals (or maybe
just overload save itself) to look at groups and add related info. I
have to hand it to you though - it's not going to be trivial no matter
what way you pick. The admin seems like it wouldn't be that easy to
deal with creating multiple subclasses of User.


"Creating the relationship between User and UserInfo has some
implications I'd like to avoid on a model-level"

Specifically what are you referring to here? Because anytime you
subclass in Django you are basically doing the exact thing in the
database behind the scenes and as result accessing the data turns out
to be pretty similar (just about as easy both ways).


You can also create managers on User - so you can do:

students = User.students.filter(...)


I'm definitely not saying you're wrong here BTW. I'm just giving an
alternative.


On Sep 24, 9:47 am, Axel Bock  wrote:
> Thanks a lot for your answers.
>
> I thought subclassing users is a nice idea, cause a Student IS a user, with
> a few extended attributes. I decided to subclass users, because ...
>
> * when adding a UserInfo -> user relationship (class UserInfo(Model): user =
> ForeignKey('User')), ALL users having a userinfo. this is bad if I have
> different kind of users (I do.), so I do not really want that.
>
> * A user can be created without attaching the UserInfo information (I did
> this already, and unless I did something wrong, I could do just that). So I
> have to add application logic to make sure that a Student actually has a
> UserInfo object attached. Also because of my different system users it would
> make no sense to actually attach that to EVERY user
>
> * I have read this 
> one:http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-mod
> Subclassing models actually seems to be the "new" way of doing things, so
> why should be User an exception to this rule?
>
> * I also have read this 
> article:http://blog.picante.co.nz/post/Subclassing-User-to-add-extra-fields-i...
>
> * And this 
> article:http://www.kolios.dk/2010/01/22/how-to-extend-django-user-class-and-c...
> the main one why I wanted this)
>
> So, all in all, if it is possible AND a common way to go, I'd prefer it that
> way. Creating the relationship between User and UserInfo has some
> implications I'd like to avoid on a model-level.
>
> If they are all wrong, I REALLY think the API should not let people do this.
> If they are right, then I still lack an anwer for my problem - the single
> f*cked up field in the create student form, which I'd like to shoot on sight
> once it's there and then burn the ashes :) . (I have had not much sleep
> tonight ...)
>
> Thanks!
> Axel.
>
> 2010/9/24 Vasil Vangelovski 
>
>
>
> > Mainly, I just don't think you're subclassing User for the right
> >> reasons. In fact, I can't really think of anytime I would subclass
> >> it.  Usually adding a related table is a better way to go (lookup
> >> django user profiles for example).
>
> >  There are times when the builtin User model is not enough, that's why
> > there is a way to specify user profiles. There are times when you want to be
> > sure that every user in the system has a profile (some filed in the profile
> > is required for the system to work properly), even for the users added from
> > the admin. This can lead people to try all kinds of hacks, like subclassing
> > user, which there is a way to implement but will lead you in all kinds of
> > trouble. Then there is the case where you want all users to be staff no
> > matter what, which makes the field superficial, but leads to extra
> > uneccessary work on the developers part to make sure it works that way.
> > These are all real world scenarios I've encountered, and I'm guilty of
> > pushing a subclassed user model in the past.
>
> > If the api leads a lot of people to try all kinds of hacks around it to
> > achieve what they want, blame the API not the people. Providing concrete
> > models for users in contrib leads to more pain than the time or trouble it
> > saves.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to 

Re: subclassing UserCreationForm

[Axel Bock]

Thanks a lot for your answers.

I thought subclassing users is a nice idea, cause a Student IS a user, with
a few extended attributes. I decided to subclass users, because ...

* when adding a UserInfo -> user relationship (class UserInfo(Model): user =
ForeignKey('User')), ALL users having a userinfo. this is bad if I have
different kind of users (I do.), so I do not really want that.

* A user can be created without attaching the UserInfo information (I did
this already, and unless I did something wrong, I could do just that). So I
have to add application logic to make sure that a Student actually has a
UserInfo object attached. Also because of my different system users it would
make no sense to actually attach that to EVERY user

* I have read this one:
http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/.
Subclassing models actually seems to be the "new" way of doing things, so
why should be User an exception to this rule?

* I also have read this article:
http://blog.picante.co.nz/post/Subclassing-User-to-add-extra-fields-in-the-Django-Admin-Site/

* And this article:
http://www.kolios.dk/2010/01/22/how-to-extend-django-user-class-and-change-authentication-middleware/(actually
the main one why I wanted this)

So, all in all, if it is possible AND a common way to go, I'd prefer it that
way. Creating the relationship between User and UserInfo has some
implications I'd like to avoid on a model-level.

If they are all wrong, I REALLY think the API should not let people do this.
If they are right, then I still lack an anwer for my problem - the single
f*cked up field in the create student form, which I'd like to shoot on sight
once it's there and then burn the ashes :) . (I have had not much sleep
tonight ...)


Thanks!
Axel.

2010/9/24 Vasil Vangelovski 

>
> Mainly, I just don't think you're subclassing User for the right
>> reasons. In fact, I can't really think of anytime I would subclass
>> it.  Usually adding a related table is a better way to go (lookup
>> django user profiles for example).
>>
>
>  There are times when the builtin User model is not enough, that's why
> there is a way to specify user profiles. There are times when you want to be
> sure that every user in the system has a profile (some filed in the profile
> is required for the system to work properly), even for the users added from
> the admin. This can lead people to try all kinds of hacks, like subclassing
> user, which there is a way to implement but will lead you in all kinds of
> trouble. Then there is the case where you want all users to be staff no
> matter what, which makes the field superficial, but leads to extra
> uneccessary work on the developers part to make sure it works that way.
> These are all real world scenarios I've encountered, and I'm guilty of
> pushing a subclassed user model in the past.
>
> If the api leads a lot of people to try all kinds of hacks around it to
> achieve what they want, blame the API not the people. Providing concrete
> models for users in contrib leads to more pain than the time or trouble it
> saves.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Vasil Vangelovski]

> Mainly, I just don't think you're subclassing User for the right
> reasons. In fact, I can't really think of anytime I would subclass
> it.  Usually adding a related table is a better way to go (lookup
> django user profiles for example).
>

 There are times when the builtin User model is not enough, that's why there
is a way to specify user profiles. There are times when you want to be sure
that every user in the system has a profile (some filed in the profile is
required for the system to work properly), even for the users added from the
admin. This can lead people to try all kinds of hacks, like subclassing
user, which there is a way to implement but will lead you in all kinds of
trouble. Then there is the case where you want all users to be staff no
matter what, which makes the field superficial, but leads to extra
uneccessary work on the developers part to make sure it works that way.
These are all real world scenarios I've encountered, and I'm guilty of
pushing a subclassed user model in the past.

If the api leads a lot of people to try all kinds of hacks around it to
achieve what they want, blame the API not the people. Providing concrete
models for users in contrib leads to more pain than the time or trouble it
saves.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Jason]

I'm not sure how to solve your exact problem but I would recommend NOT
extending the user class here.

You'll probably want to create a manytomany field on your Course model
that contains users.

And if you're going to have many different types of users you'll want
to create groups. Put students in the 'students' group.


Mainly, I just don't think you're subclassing User for the right
reasons. In fact, I can't really think of anytime I would subclass
it.  Usually adding a related table is a better way to go (lookup
django user profiles for example).

On Sep 24, 12:29 am, Axel  wrote:
> All right, I found some 
> sources.http://stackoverflow.com/questions/1061279/for-the-django-admin-how-d...http://blog.picante.co.nz/post/Subclassing-User-to-add-extra-fields-i...
>
> By strictly holding to these, and by experimenting, I now get this:
>
> _'StudentAdmin.fieldsets[0][1]['fields']' refers to field 'course'
> that is missing from the form._
>
> Adding a class StudentCreateForm(UserCreationForm) does not help,
> either:
>
> class StudentCreateForm(UserCreationForm):
>     course = forms.CharField()
> class StudentAdmin(UserAdmin):
>     # ...
>     add_form = StudentCreateForm
>
> Please, I am going crazy. There's probably a super-simple solution,
> but I don't seem to find it. And I feel horribly stupid right now. And
> it's several hours now, cause I can't let go - and I'm horribly tired.
>
> Thanks,
> Axel.
>
> On Sep 23, 11:29 pm, Axel Bock  wrote:
>
> > Hello all,
>
> > I must admit - I am going crazy. With something I thought should be
> > incredibly simple, but maybe I am just too f**king stupid.
>
> > All right, here comes my problem. I have subclassed "User" as "Student" and
> > added some required fields, one of them being "Course":
>
> > # models.py
> > class Student(User):
> >     course = models.ForeignKey('Course')
>
> > So far, so good. Now I couldn't create a Student with an initial password -
> > the password field was plaintext, and the "change password" form wouldn't
> > work. I dug through the code and some postings, and discovered that if I
> > used a custom admin class it would just work fine, with the advantage that I
> > could exclude some fields I don't need in the admin view of the Students.
> > That basically looks like this:
>
> > # admin.py
> > class StudentAdmin(UserAdmin):
> >     fieldsets = ( #...
> >     )
> > admin.site.register(Student, StudentAdmin)
> > *
> > Then* I got another annoyance. If I tried to create a Student now, I was
> > confronted with the "usual" User creation screen. (Huh? ... ok, dig a bit in
> > Django internals, one can only learn ...). Basically I wouldnt mind, but the
> > Student creation does not work any more - the simple add user screen will of
> > course set no "course" value in the Student model, So I dug further. I
> > discovered that the user creation was handled by a form called
> > UserCreationForm, and this form explicitly excluded alot of stuff.
>
> > But now the magic went crazy. If I look at the UserCreationForm class, I
> > see:
>
> >     class Meta:
> >         model = User
> >         fields = ("username",)
>
> > WTF? The only field which *should* be seen is "username", according to the
> > docs (according 
> > tohttp://docs.djangoproject.com/en/1.2/topics/forms/modelforms/). But there 
> > is
> > password AND username. Aha. I am pretty confused now. But not without
> > optimism. I tried subclassing the form now, which looked something like
> > this:
>
> > *class StudentCreationForm(UserCreationForm):
> >     class Meta():
> >         model = Student
> >         fields = ('course')
> > *
> > class StudentAdmin(UserAdmin):
> >     #fields = ('first_name', 'family_name', 'password', 'course', 'base')
> >     fieldsets = ( # ... cut out
> >     *add_form = StudentCreationForm*
>
> > And the result? No luck. WhatEVER I do (replacing UserCreationForm with
> > subclass of ModelForm, overriding get_form(), and some other things), the
> > form will only and inevitably show "username" and "password".
>
> > And it's about two hours now.
>
> > Help.
>
> > Please.
>
> > Thanks!
> > Axel.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Axel]

All right, I found some sources.
http://stackoverflow.com/questions/1061279/for-the-django-admin-how-do-i-add-a-field-to-the-user-model-and-have-it-editable
http://blog.picante.co.nz/post/Subclassing-User-to-add-extra-fields-in-the-Django-Admin-Site/

By strictly holding to these, and by experimenting, I now get this:

_'StudentAdmin.fieldsets[0][1]['fields']' refers to field 'course'
that is missing from the form._

Adding a class StudentCreateForm(UserCreationForm) does not help,
either:

class StudentCreateForm(UserCreationForm):
course = forms.CharField()
class StudentAdmin(UserAdmin):
# ...
add_form = StudentCreateForm

Please, I am going crazy. There's probably a super-simple solution,
but I don't seem to find it. And I feel horribly stupid right now. And
it's several hours now, cause I can't let go - and I'm horribly tired.


Thanks,
Axel.

On Sep 23, 11:29 pm, Axel Bock  wrote:
> Hello all,
>
> I must admit - I am going crazy. With something I thought should be
> incredibly simple, but maybe I am just too f**king stupid.
>
> All right, here comes my problem. I have subclassed "User" as "Student" and
> added some required fields, one of them being "Course":
>
> # models.py
> class Student(User):
>     course = models.ForeignKey('Course')
>
> So far, so good. Now I couldn't create a Student with an initial password -
> the password field was plaintext, and the "change password" form wouldn't
> work. I dug through the code and some postings, and discovered that if I
> used a custom admin class it would just work fine, with the advantage that I
> could exclude some fields I don't need in the admin view of the Students.
> That basically looks like this:
>
> # admin.py
> class StudentAdmin(UserAdmin):
>     fieldsets = ( #...
>     )
> admin.site.register(Student, StudentAdmin)
> *
> Then* I got another annoyance. If I tried to create a Student now, I was
> confronted with the "usual" User creation screen. (Huh? ... ok, dig a bit in
> Django internals, one can only learn ...). Basically I wouldnt mind, but the
> Student creation does not work any more - the simple add user screen will of
> course set no "course" value in the Student model, So I dug further. I
> discovered that the user creation was handled by a form called
> UserCreationForm, and this form explicitly excluded alot of stuff.
>
> But now the magic went crazy. If I look at the UserCreationForm class, I
> see:
>
>     class Meta:
>         model = User
>         fields = ("username",)
>
> WTF? The only field which *should* be seen is "username", according to the
> docs (according 
> tohttp://docs.djangoproject.com/en/1.2/topics/forms/modelforms/). But there is
> password AND username. Aha. I am pretty confused now. But not without
> optimism. I tried subclassing the form now, which looked something like
> this:
>
> *class StudentCreationForm(UserCreationForm):
>     class Meta():
>         model = Student
>         fields = ('course')
> *
> class StudentAdmin(UserAdmin):
>     #fields = ('first_name', 'family_name', 'password', 'course', 'base')
>     fieldsets = ( # ... cut out
>     *add_form = StudentCreationForm*
>
> And the result? No luck. WhatEVER I do (replacing UserCreationForm with
> subclass of ModelForm, overriding get_form(), and some other things), the
> form will only and inevitably show "username" and "password".
>
> And it's about two hours now.
>
> Help.
>
> Please.
>
> Thanks!
> Axel.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

subclassing UserCreationForm

[Axel Bock]

Hello all,

I must admit - I am going crazy. With something I thought should be
incredibly simple, but maybe I am just too f**king stupid.

All right, here comes my problem. I have subclassed "User" as "Student" and
added some required fields, one of them being "Course":

# models.py
class Student(User):
course = models.ForeignKey('Course')

So far, so good. Now I couldn't create a Student with an initial password -
the password field was plaintext, and the "change password" form wouldn't
work. I dug through the code and some postings, and discovered that if I
used a custom admin class it would just work fine, with the advantage that I
could exclude some fields I don't need in the admin view of the Students.
That basically looks like this:

# admin.py
class StudentAdmin(UserAdmin):
fieldsets = ( #...
)
admin.site.register(Student, StudentAdmin)
*
Then* I got another annoyance. If I tried to create a Student now, I was
confronted with the "usual" User creation screen. (Huh? ... ok, dig a bit in
Django internals, one can only learn ...). Basically I wouldnt mind, but the
Student creation does not work any more - the simple add user screen will of
course set no "course" value in the Student model, So I dug further. I
discovered that the user creation was handled by a form called
UserCreationForm, and this form explicitly excluded alot of stuff.

But now the magic went crazy. If I look at the UserCreationForm class, I
see:

class Meta:
model = User
fields = ("username",)

WTF? The only field which *should* be seen is "username", according to the
docs (according to
http://docs.djangoproject.com/en/1.2/topics/forms/modelforms/). But there is
password AND username. Aha. I am pretty confused now. But not without
optimism. I tried subclassing the form now, which looked something like
this:

*class StudentCreationForm(UserCreationForm):
class Meta():
model = Student
fields = ('course')
*
class StudentAdmin(UserAdmin):
#fields = ('first_name', 'family_name', 'password', 'course', 'base')
fieldsets = ( # ... cut out
*add_form = StudentCreationForm*

And the result? No luck. WhatEVER I do (replacing UserCreationForm with
subclass of ModelForm, overriding get_form(), and some other things), the
form will only and inevitably show "username" and "password".

And it's about two hours now.

Help.

Please.


Thanks!
Axel.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.