Alexander Solovyov wrote:
> But lets' listen what core developers think about making this the
> official way. :)
Personally, I like the idea of being able to switch out User models, as long
as a base interface can be worked out. It seems that there might be a few
people using a version of a patch attached to ticket #3011 (Allow for
extendable auth_user module) [1].
I've got a few projects where I'm currently using either a custom user model
in place of contrib.auth.User (meaning I had to roll my own pieces of django
that have contrib.auth.User model hardcoded, like the auth backend) or using a
custom user model with a OneToOne to contrib.auth.User (allowing me to use
django's auth and sessions without modificaton). I would love to be able to
do away with these solutions in favor of something that allows me to use a
user model in place of contrib.auth.User as long as it implements some base
interface so that the other code expecting a contrib.auth.User instance will
still be happy.
Also, this has come up a few times in the past, so you might want to search
the archives. I know I have brought up some things before like extracting the
user permission checking methods into an ObjectWithPermissions class that
could be used as a mixin. Or possibly even using composition with something
like:
class User(models.Model):
permissions = DatabasePermissions()
Gary
[1] http://code.djangoproject.com/ticket/3011
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
