Re: Extending the user model and accessing fields in template context

[Bernd Wechner]

Why thank you Melvyn, nailed it one. I had assumed there was a profile 
connected but alas it was not set ... once I set it, the template access 
through the dot notation to the profile works fine. It is the silent 
exception being ignored that threw me  guess. Arguably appropriate 
response to a lacking profile of course, but I'd sort of prefer to be 
informed too. Still, if it wasn't already so late at night when it hit 
me, I might have thought to examine the link in the models and database 
to ensure that I've set the user field in the Dude model ;-).


Regards,

Bernd.

Melvyn Sopacua wrote:


On Thursday 08 June 2017 08:46:38 Bernd Wechner wrote:

> Have failed to find an easy answer to this so will lazily ask the

> broader community before I retire tonight ;-).

>

> I have a model that I use to extend the User model like yo:

>

> from django.contrib.auth.models import User

>

> class Dude(models.Model):

> nickname = models.CharField('Nickname',

> max_length=MAX_NAME_LENGTH) clans = models.ManyToManyField('League',

> blank=True, related_name='dudes_in_clan')

> user = models.OneToOneField(User, related_name='dude',

> blank=True, null=True, default=None)

>

> Now {{ user }} renders as the user name quite well in my templates so

> I can show the logged in user in a header. Nice.

>

> But I'd like to access fields in the extended model like {{

> user.dude.nickname }}.

>

> Alas, it's not that simple clearly. I'm missing something, as that

> renders blank.

If there is no profile, an exception is thrown. It throws a rather 
useless exception RelatedObjectDoesNotExist, cause to catch it, you'd 
have to reference the accessor, which will throw 
RelatedObjectDoesNotExist and to catch it ... etc.


You can however catch it as an AttributeError, then inspect it's type. 
See: django.db.models.fields.related_descriptors.ReverseOneToOneDescriptor


In templates exceptions are caught and silenced and the empty string 
is returned.


So to prevent a disconnect between a User model and a profile model, 
you basically have to make sure, that whenever a new User is created, 
you create a new profile. This is why typically, all fields in a 
profile model have null=True, so that you can listen to the post_save 
signal 
 
on the User model and create a profile, without requiring profile 
information.


It's either that, or you have to augment the things in your project 
that create users with the required profile data. By default that is 
the admin and the createsuperuser command.


--

Melvyn Sopacua

--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-users@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2020313.dh1SZzXWp7%40devstation 
.

For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/154190de-f191-f0e3-05e5-e9c4128d3f14%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending the user model and accessing fields in template context

[Melvyn Sopacua]

On Thursday 08 June 2017 08:46:38 Bernd Wechner wrote:
> Have failed to find an easy answer to this so will lazily ask the
> broader community before I retire tonight ;-).
> 
> I have a model that I use to extend the User model like yo:
> 
> from django.contrib.auth.models import User
> 
> class Dude(models.Model):
>  nickname = models.CharField('Nickname',
> max_length=MAX_NAME_LENGTH) clans = models.ManyToManyField('League',
> blank=True, related_name='dudes_in_clan')
>  user = models.OneToOneField(User, related_name='dude',
> blank=True, null=True, default=None)
> 
> Now  {{ user }} renders as the user name quite well in my templates so
> I can show the logged in user in a header. Nice.
> 
> But I'd like to access fields in the extended model like {{
> user.dude.nickname }}.
> 
> Alas, it's not that simple clearly. I'm missing something, as that
> renders blank.

If there is no profile, an exception is thrown. It throws a rather useless 
exception 
RelatedObjectDoesNotExist, cause to catch it, you'd have to reference the 
accessor, which will 
throw RelatedObjectDoesNotExist and to catch it ... etc.

You can however catch it as an AttributeError, then inspect it's type. See:  
django.db.models.fields.related_descriptors.ReverseOneToOneDescriptor

In templates exceptions are caught and silenced and the empty string is 
returned.

So to prevent a disconnect between a User model and a profile model, you 
basically have to 
make sure, that whenever a new User is created, you create a new profile. This 
is why typically, 
all fields in a profile model have null=True, so that you can listen to the 
post_save signal[1] on 
the User model and create a profile, without requiring profile information.

It's either that, or you have to augment the things in your project that create 
users with the 
required profile data. By default that is the admin and the createsuperuser 
command.
-- 
Melvyn Sopacua


[1] 
https://docs.djangoproject.com/en/1.11/ref/signals/#django.db.models.signals.post_save

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2020313.dh1SZzXWp7%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: Extending, inheriting User Model or custom User Model?

[Carl Meyer]

Hi Tobias,

On 11/18/2014 11:44 AM, Tobias Dacoir wrote:
> Dear Daniel and Carl,
> 
> thanks for your advice. However I'm a bit confused now. So in general
> you recommend that I follow the guide for substituting my own custom
> model but at the same time Carl is warning me that overwriting
> AUTH_USER_MODEL is quite painful for an existing application (right now
> I haven't really done much except basic Models and some Views and
> Forms), but as I read the guide that is exactly what I have to do when
> using my own custom Model.

I thought you were at the beginning of a new project.

If you are still in development, and don't have data in your database
that you care about yet, adding AUTH_USER_MODEL is simple: drop your
database, delete all your migrations, re-create all your initial
migrations, and run them on a brand new database.

> I will still try to get it to work somehow. Are all the tutorials found
> on the internet for Django 1.5 still valid with 1.7?

That would be an ambitious claim to make :-) Since migrations are new in
1.7, anything from an earlier version relating to database creation or
modification (syncdb, migrate, etc) is no longer accurate.

Carl



signature.asc
Description: OpenPGP digital signature

Re: Extending, inheriting User Model or custom User Model?

[Tobias Dacoir]

Dear Daniel and Carl,

thanks for your advice. However I'm a bit confused now. So in general you 
recommend that I follow the guide for substituting my own custom model but 
at the same time Carl is warning me that overwriting AUTH_USER_MODEL is 
quite painful for an existing application (right now I haven't really done 
much except basic Models and some Views and Forms), but as I read the guide 
that is exactly what I have to do when using my own custom Model. 

I will still try to get it to work somehow. Are all the tutorials found on 
the internet for Django 1.5 still valid with 1.7?


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b07fd60f-ae16-4f51-8cb7-dcabd53d12f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending, inheriting User Model or custom User Model?

[Carl Meyer]

Hi Tobias & Daniel,

On 11/18/2014 09:10 AM, Daniel Roseman wrote:
> On Tuesday, 18 November 2014 15:04:19 UTC, Tobias Dacoir wrote:
> 
> I'm trying to figure out how to create my Custom User Model.
> 
> In the official docs I basically found two different strategies:
> Extending User Model or Custom User Model:
> 
> https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#extending-the-existing-user-model
> 
> 
> 
> Extending means I have a OnetoOne Relationship to the User Table in
> my own UserProfile Model, whereas the other method inherits from
> AbstractBaseUser and looks quite complicated with a lot of warnings
> that I can't not change this easily after I created my database.
> 
> I want to design a web app where users can log in and once log in
> take some kind of surveys. For this I want to make use of Django's
> Authentication methods, so only registered and logged in Users can
> take part in the survey. However I want to save additional data for
> each User in the database, like Age, Country, Score and so on. In
> the Admin interface it would be great if I could just select a User
> Entry and see all fields, the default from the User Model plus my
> added fields.
> 
> It might be a good idea to use OAuth later on as well, to be able to
> have users authenticate through Facebook and so on, however that is
> not required right now (I did create quick test project for the
> social auth plugin and it worked). Still I don't really understand
> the differences between those two methods and google didn't help me
> because most tutorials show either route but never say why one is
> better than the other.
> 
> So which should I use in my case?
> 
> 
> In the case you describe, there's not really a lot to choose between the
> two approaches. Either you extend the user model with a related profile,
> in which case you configure the admin to show the profile as an inline
> underneath the main fields, or you substitute your own model (which
> probably inherits from AbstractUser), in which case the admin shows all
> the fields in one section. Personally I prefer the tidiness of custom
> models, especially as you save a db query every time.

I agree with this advice. Especially because you can't (without great
pain) change the value of AUTH_USER_MODEL after you start the project --
but if you have a custom user model, you can easily generate migrations
to change it (add fields, remove fields, alter fields, etc). So if you
start with the built-in User model, you're stuck with it as-is forever
(unless you use ugly monkeypatch hacks), but if you start out with a
custom User model (even if initially it's no different from the default)
you have more flexibility going forward.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/546B7185.5010200%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Extending, inheriting User Model or custom User Model?

[Daniel Roseman]

On Tuesday, 18 November 2014 15:04:19 UTC, Tobias Dacoir wrote:
>
> I'm trying to figure out how to create my Custom User Model.
>
> In the official docs I basically found two different strategies: Extending 
> User Model or Custom User Model: 
> https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#extending-the-existing-user-model
>
> Extending means I have a OnetoOne Relationship to the User Table in my own 
> UserProfile Model, whereas the other method inherits from AbstractBaseUser 
> and looks quite complicated with a lot of warnings that I can't not change 
> this easily after I created my database.
>
> I want to design a web app where users can log in and once log in take 
> some kind of surveys. For this I want to make use of Django's 
> Authentication methods, so only registered and logged in Users can take 
> part in the survey. However I want to save additional data for each User in 
> the database, like Age, Country, Score and so on. In the Admin interface it 
> would be great if I could just select a User Entry and see all fields, the 
> default from the User Model plus my added fields.
>
> It might be a good idea to use OAuth later on as well, to be able to have 
> users authenticate through Facebook and so on, however that is not required 
> right now (I did create quick test project for the social auth plugin and 
> it worked). Still I don't really understand the differences between those 
> two methods and google didn't help me because most tutorials show either 
> route but never say why one is better than the other. 
>
> So which should I use in my case?
>


In the case you describe, there's not really a lot to choose between the 
two approaches. Either you extend the user model with a related profile, in 
which case you configure the admin to show the profile as an inline 
underneath the main fields, or you substitute your own model (which 
probably inherits from AbstractUser), in which case the admin shows all the 
fields in one section. Personally I prefer the tidiness of custom models, 
especially as you save a db query every time.
--
DR.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6086f880-2bf1-4de7-a59e-a123334ce32c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending Django User model using add_to_class()

[James Bennett]

On Mon, Jun 22, 2009 at 5:30 PM, pr wrote:
> Yes, I know what you mean, but It's small project with one programmer.
> I want to know about speed and stability in production mode above
> rules of 'programming-tao' :-)

Well, there's also the fact that:

1. Using a profile means relying on documented, guaranteed-stable
behavior in Django.
2. Using the add_to_class trick means relying on undocumented
internals which have no stability guarantee whatsoever, and which are
subject to change without warning.

Seriously: there's a documented and supported method for storing
additional information related to users. Please take advantage of it.

(and, really I speak from experience regarding other ways to do this;
I have hacked up Django in just about every way possible, and I
remember back when you could do things like outright replace models
with your own definitions, and all of it was a freaking nightmare for
maintainability)


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending Django User model using add_to_class()

[pr]

On 22 Cze, 23:14, James Bennett  wrote:
> No, it's a very bad method. Consider what happens if two people want
> to add fields of the same name; trying to stick them in the User model
> will obviously fail and break at least one person's code.
Yes, I know what you mean, but It's small project with one programmer.
I want to know about speed and stability in production mode above
rules of 'programming-tao' :-)

regards.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending Django User model using add_to_class()

[James Bennett]

On Mon, Jun 22, 2009 at 4:01 PM, pr wrote:
> Is it a good way to extend Django User model using add_to_class()?
> I have to add only two extra fields to the User model and I think that
> using Profile Model to do this is unnecessary.

No, it's a very bad method. Consider what happens if two people want
to add fields of the same name; trying to stick them in the User model
will obviously fail and break at least one person's code. Using the
standard method of a related profile model keeps them neatly
namespaced.

As a general rule, consider code in other people's applications
(including applications in django.contrib) to be read-only.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending the User model

[Malcolm Tredinnick]

On Sun, 2009-02-08 at 12:16 -0800, Patricio Palma wrote:
> Greetings
> 
> I've a model
> class MyUser(auth.User):
> location = meta.CharField(maxlength=100, blank=True)
> 
> class META:
> replaces_module = 'auth.users'
> admin = meta.Admin(
> list_display = ('username', 'email',
> 'first_name','last_name', 'lacation')
> )

Django hasn't used that syntax since the 0.91 release. Since then, admin
has been through two major revisions.

What version of Django are you using (keeping in mind that if you are
using 0.91, you're going to be pretty much on your own with solving most
problems, since it's from so long and so many changes ago)?

If you're using, say, Django 1.0, the documentation is your friend as to
the right syntax for the admin interface.

Regards,
Malcolm



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending the User model

[Patricio Palma]

Thanks, I owe you a chocolate bar

I fix it

class MyUser(User):
chilean_rut  = CLRutField(_('RUT'),unique=True)
some_field = models.CharField(max_length=50)

voalá
I don't really need a PK, my mistake
Thanks again.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending the User model

[Karen Tracey]

On Sun, Feb 8, 2009 at 7:51 PM, Patricio Palma wrote:

> [snip]
> ---
> models.py
> from django.contrib.auth.models import User
> class MyUser(User):
>chilean_rut  = CLRutField(_('RUT'),primary_key=True)
> some_field = models.CharField(max_length=50)
> 
> admin.py
> class MyUserAdmin(admin.ModelAdmin):
>list_display = ('chilean_rut', 'email','some_field')
> admin.site.register(MyUser,MyUserAdmin)
>
> -
>
> And my list_display is EMPTY ( on the
> http://127.0.0.1:8000/admin/myapp/myuser/)
>

The problem here seems to be caused by setting primary_key=True on one of
the fields in the model that inherits from another.  You can see it using
just these simple models:

class BaseM(models.Model):
  base_name = models.CharField(max_length=100)
  def __unicode__(self):
return self.base_name

class DerivedM(BaseM):
  customPK = models.IntegerField(primary_key=True)
  derived_name = models.CharField(max_length=100)
  def __unicode__(self):
return "PK = %d, base_name = %s, derived_name = %s" % \
(self.customPK, self.base_name, self.derived_name)

and manage.py shell (output reformatted for readability):

Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from ttt.models import DerivedM
>>> from django.db import connection
>>> DerivedM.objects.create(customPK=44, base_name="b1", derived_name="d1")

>>> DerivedM.objects.all()
[]
>>> connection.queries[-1]
{'time': '0.006',
'sql': u'SELECT
  `ttt_basem`.`id`,
  `ttt_basem`.`base_name`,
  `ttt_derivedm`.`basem_ptr_id`,
  `ttt_derivedm`.`customPK`,
  `ttt_derivedm`.`derived_name`
   FROM `ttt_derivedm` INNER JOIN `ttt_basem`
   ON (`ttt_derivedm`.`customPK` = `ttt_basem`.`id`) LIMIT 21'}
>>>

The ORM is joining the two tables and attempting to match the
manually-specified custom PK from the child table to the auto-generated id
in the parent table, which results in finding nothing.  I do not know if
specifying primary_key=True on a field in a child table is just not allowed
(in which case it should probably be flagged as an error during validation)
or if the ORM should be handling this properly.  I do not see any ticket
open that describes this case; you might want to open one since it seems
something ought to be changed here to either report an invalid model
definition or handle this case properly.

Karen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending the User model

[Patricio Palma]

Yeah you're right
I can't believe that
I mix the admin settings in the class, for a short explanation.

my code:
---
models.py
from django.contrib.auth.models import User
class MyUser(User):
chilean_rut  = CLRutField(_('RUT'),primary_key=True)
some_field = models.CharField(max_length=50)

admin.py
class MyUserAdmin(admin.ModelAdmin):

list_display = ('chilean_rut', 'email','some_field')

admin.site.register(MyUser,MyUserAdmin)

-

And my list_display is EMPTY ( on the  http://127.0.0.1:8000/admin/myapp/myuser/
)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending the User model

[Karen Tracey]

On Sun, Feb 8, 2009 at 5:33 PM, Patricio Palma wrote:

>
> At revision 9820.
>
> ???
>

??? indeed.  What doc are you reading that suggests having  something like
"admin = meta.Admin(..." under class Meta of your model definition?  I've
never seen anything like it but I've only been around since 0.96 or so and
others seem to recognize it as very old syntax from earlier releases.  If
you were running r9820 I'd expect you to get a NameError on that line since
there's nothing named meta to support that call.

The current way to set list_display, if you are running 1.0 or more recent,
is documented here:

http://docs.djangoproject.com/en/dev/ref/contrib/admin/#modeladmin-options

The admin defs are all now included in ModelAdmin classes, there is no more
admin definition tied into the model class definition itself.  But if you
were running a relatively recent Django, I'd expect you'd be seeing errors
with the code you are showing us, so I am rather confused by your report of
no errors, just not the results you were expecting.

Karen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending the User model

[Patricio Palma]

At revision 9820.

???

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending the User model

[Daniel Roseman]

On Feb 8, 9:06 pm, Patricio Palma  wrote:
> > This code looks exceptionally old, admin = meta.Admin() has been gone for
> > several years, what version of django are you workign with?
>
> 1.1 pre-alpha
> I 've in admin.py file, the main idea was show the list_display field
> setted

That's impossible. This code is from version 0.90, maybe even older.
It just wouldn't work on 1.1.
--
DR.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending the User model

[Patricio Palma]

> This code looks exceptionally old, admin = meta.Admin() has been gone for
> several years, what version of django are you workign with?
>

1.1 pre-alpha
I 've in admin.py file, the main idea was show the list_display field
setted
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending the User model

[Alex Gaynor]

On Sun, Feb 8, 2009 at 3:06 PM, Patricio Palma wrote:

>
> Greetings
>
> I have a model
>
> from django.contrib.auth.models import User
> class MyUser(User):
>
>chilean_rut  = CLRutField(_('RUT'),primary_key=True)
>
>class Meta:
>
>   admin = meta.Admin(
>fields = (
>(_('Personal info'), {'fields': ('first_name', 'last_name',
> 'chilean_rut','email')}),
>(_('Extended info'), {'fields': ('gamename', 'url',
> 'description')}),
>(_('Permissions'), {'fields': ('is_staff', 'is_active',
> 'is_superuser', 'user_permissions')}),
>(_('Important dates'), {'fields': ('last_login',
> 'date_joined')}),
>(_('Groups'), {'fields': ('groups',)}),
>),
>list_display = ('username', 'gamename', 'first_name',
> 'last_name', 'is_staff'),
>
> looks fine, but in my users list after added, I see only the total of
> added users
>
> just like list_display was empty
>
>
> Thanks
>
> >
>
This code looks exceptionally old, admin = meta.Admin() has been gone for
several years, what version of django are you workign with?

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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: Extending the User Model with Inheritance | How to save extended data

[johan.uhIe]

So I have just had a try with a new written UserManager and it works.

My model looks the following way now:

from django.db import models
from django.contrib.auth.models import User, UserManager
import datetime

class NewUserManager(models.Manager):
def create_user(self, username, email, password, extradata):
"""Creates and saves a User with the given username, 
e-mail and
password.
The extradata dictionary set as attributes to the 
model"""
now = datetime.datetime.now()
user = self.model(None, username, '', '', 
email.strip().lower(),
'placeholder', False, True, False, now, now)
user.set_password(password)
# username email and password do not have to be saved 
again
del extradata['username']
del extradata['email']
del extradata['password']
for key in extradata:
setattr(user, key, extradata[key])
user.save()
return user

class CustomUserData(User):
# New Extra Data being saved with every User
city = models.CharField(max_length = 255)
[...]
# Use UserManager to get the create_user method, etc.
objects = NewUserManager()


and the save() changed to

def save(self):
CustomUserData.objects.create_user(
username=self.cleaned_data['username'],

email=self.cleaned_data['email'],

password=self.cleaned_data['password'],

extradata=self.cleaned_data)


So this looks pretty nice to me. Anyone having another suggestion?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: Extending the User model

[krylatij]

Take a look at http://code.google.com/p/django-profile/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: Extending the User model

[Ulises]

> AFAICT, there's some work going on to allow to replace the default
> User model with a custom one. But so far, the recommended solution is
> indeed to use a UserProfile. Else, there's the hackish (IOW : *not*
> recommended) solution - monkeypatching the User model
> http://www.amitu.com/blog/2007/july/django-extending-user-model/

If you want yet another hack you could use a custom authentication
backend with your own user model as described here:
http://monogroncho.com/2008/10/django-gotchas-part-2/ (shameless self
promotion here :)

U

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: Extending the User model

[bruno desthuilliers]

On 17 oct, 05:30, jeffself <[EMAIL PROTECTED]> wrote:
> I'm working on an application that will need data entry from many
> users.  The users belong to various departments in the organization
> and the information that gets entered by each user should contain the
> department information.  The reason for this is that the users should
> be able to view and edit only records in their department.  They
> should not be able to view any records from any other department.
>
> I'm not sure how to go about doing this.  I definitely want to use the
> User model in Django and I'm thinking that all I want to do is extend
> it with a department field which is a foreign key of the Department
> model that I have created.  On the other hand, I've looked at Profiles
> as well and even created a UserProfile class which contains the user
> and the department.  Which is the correct approach?

AFAICT, there's some work going on to allow to replace the default
User model with a custom one. But so far, the recommended solution is
indeed to use a UserProfile. Else, there's the hackish (IOW : *not*
recommended) solution - monkeypatching the User model
http://www.amitu.com/blog/2007/july/django-extending-user-model/


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: extending the User Model error

[*San*]

It works, yay

Thanks heaps

On May 5, 5:12 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 5/4/07, *San* <[EMAIL PROTECTED]> wrote:
>
> > but, when I tried to view it, I got an error:
> >  Cannot resolve keyword 'user' into field
>
> The field on your profile model **must** be named "user".
>
> So, for example, this will work:
>
> class MyProfile(models.Model):
> mailing_address = models.TextField()
> user = models.ForeignKey(User, unique=True)
>
> But this will not, because the relation back to the User model is not
> a field named "user":
>
> class MyProfile(models.Model):
> mailing_address = models.TextField()
> django_user_account = models.ForeignKey(User, unique=True)
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: extending the User Model error

[James Bennett]

On 5/4/07, *San* <[EMAIL PROTECTED]> wrote:
> but, when I tried to view it, I got an error:
>  Cannot resolve keyword 'user' into field

The field on your profile model **must** be named "user".

So, for example, this will work:

class MyProfile(models.Model):
mailing_address = models.TextField()
user = models.ForeignKey(User, unique=True)

But this will not, because the relation back to the User model is not
a field named "user":

class MyProfile(models.Model):
mailing_address = models.TextField()
django_user_account = models.ForeignKey(User, unique=True)



-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: Extending the User model

[Oliver Charles]

I suppose the best bet, in an ideal world, world be model inheritance.
As you're probably aware, this is incomplete at the moment, so you
can't really do that. A better solution may be to have a wrapper
model, and have your Buyer/Seller classes create one to one
relationship this extension class. To top things off, one-to-one is
also going to be changing syntax soon.. but I think this is your best
bet for now...

class UserExtension(models.Model):
pass

class Buyer(models.Model):
# Buyer specific profile data here
pass

Then, you could set AUTH_PROFILE_MODULE. To keep your code pretty dry,
you'll probably want to have a "get_data" method in UserExtension:

def get_data(self):
if self.buyer:
return self.buyer
if self.seller:
return self.seller
return None # No profile data


I'm also looking for a nice solution to this, as I'Hope this helps


On Apr 19, 9:05 am, checco <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I already posted this question 
> herehttp://groups.google.com/group/django-users/browse_thread/thread/2dfb...
> but I then realized I had not been very clear and decided to rewrite
> it.
>
> In this entry from the James Bennet 
> bloghttp://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-mo...
> are clear instructions on how to extend the User model to fit the
> particular needs of an application.
>
> In the application I'm developing there two different kind of users,
> for example a Buyer and a Seller, which have different fields. This
> means that I have to extend the User model twice. The problem I'm
> facing is: which value should I specify for the parameter
> AUTH_PROFILE_MODULE in settings.py? 'myapp.Buyer', 'myapp.Seller',
> both of them?
>
> Any help will be appreciated
> Francesco


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: Extending the user model

[Pitmairen]

I have extended the user model like this, but when i edit something in
the admin, the userprofile associated with that user gets deleted.
Anyone know how i can  prevent this?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users
-~--~~~~--~~--~--~---

Re: Extending the user model

[Stefán Freyr Stefánsson]

Sorry to "fork" this thread. And thank you to Dirk for pointing out the article and verifying that it is the "right thing to do"(tm).I have to do this as well (that is, enhance the User object a bit) but not quite in the same way as this is intended I believe. The thing is that I'm using mod_auth_mysql for Apache authentication and I want to use that against the Django auth system. For reasons I won't go into here I cannot use the recommended way of authenticating a user directly against the django auth database (having mostly to do with outdated mod_python packages in my distro etc.).
So I'd like to ask if there's any mechanism of "intersecting" when a user is updated through the admin interface. What I will need to store in my UserProfile table is the "pure" SHA-1 hash of the user to enable mod_auth_mysql to use that field (it won't understand the alg$seed$hash syntax used in the django user table.
So I would of course like to do this transparently, by intersepting both create user and update user queries where I get the password in plaintext and put the pure hash in my database. Other than that I want the exact same behavior of what the auth system in django does right now.
Can anybody think of a way of accomplishing this? Am I destined to have to duplicate and modify my own version of the django user administration interface/handler layer? What is in your oppinion the least painful (as in duplication of code) way of accomplishing this?
Kind regards, Stefan Freyr.On 10/13/06, Dirk Eschler <[EMAIL PROTECTED]> wrote:
Am Freitag, 13. Oktober 2006 13:58 schrieb Malcolm Tredinnick:> On Fri, 2006-10-13 at 13:20 +0200, Dirk Eschler wrote:> > Hello,> >> > is the method described at the below link still the recommended one?
> > http://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-model>> Yes. Is there something you are trying to do that isn't accomplished by
> that method?Thanks for the quick response. And sorry for not being more precise. I haven'ttried it yet. Just wanted to be sure, that the article doesn't refer to anobsolete version of Django. It mentioned that things might change in future
releases, model subclassing in particular.Best Regards,Dirk Eschler--Dirk Eschler 
http://www.krusader.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django users" group.  To post to this group, send email to django-users@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-users  -~--~~~~--~~--~--~---

Re: Extending the user model

[Dirk Eschler]

Am Freitag, 13. Oktober 2006 13:58 schrieb Malcolm Tredinnick:
> Yes. Is there something you are trying to do that isn't accomplished by
> that method?

Ok now that i have tried, there is indeed something i can't accomplish. :) 
Here's a simplified version of my model:

class UserProfile(models.Model):
  academic_title = models.CharField(maxlength=255)
  user = models.ForeignKey(User, unique=True,
 edit_inline=models.STACKED,
 num_in_admin=1, min_num_in_admin=1,
 max_num_in_admin=1, num_extra_on_change=0)

Using the above code, i get a "User profile #1" fieldset at the bottom of the 
admin interface. Great so far, however, is it still possible to reorder the 
fields? As far as i understand i can't just use a inner Admin class in this 
case, can i?

I'm trying to achieve a field ordering like that:

Personal info
==
Academic title: []
First name: []
Last name:  []
E-mail address: []

Or in case this is impossible, i would like to put the "User profile" fieldset 
below the "Personal info" fieldset.

-- 
Dirk Eschler 
http://www.krusader.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users
-~--~~~~--~~--~--~---

Re: Extending the user model

[Dirk Eschler]

Am Freitag, 13. Oktober 2006 13:58 schrieb Malcolm Tredinnick:
> On Fri, 2006-10-13 at 13:20 +0200, Dirk Eschler wrote:
> > Hello,
> >
> > is the method described at the below link still the recommended one?
> > http://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-model
>
> Yes. Is there something you are trying to do that isn't accomplished by
> that method?

Thanks for the quick response. And sorry for not being more precise. I haven't 
tried it yet. Just wanted to be sure, that the article doesn't refer to an 
obsolete version of Django. It mentioned that things might change in future 
releases, model subclassing in particular.

Best Regards,
Dirk Eschler

-- 
Dirk Eschler 
http://www.krusader.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users
-~--~~~~--~~--~--~---

Re: Extending the user model

[Malcolm Tredinnick]

On Fri, 2006-10-13 at 13:20 +0200, Dirk Eschler wrote:
> Hello,
> 
> is the method described at the below link still the recommended one?
> http://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-model

Yes. Is there something you are trying to do that isn't accomplished by
that method?

Regards,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users
-~--~~~~--~~--~--~---

Re: Extending the user model raises error: ImproperlyConfigured

[un]

Sorry, I found the error myself:
I was mistaken concerning the value
for my_apps in AUTH_PROFILE_MODULE

uli


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users
-~--~~~~--~~--~--~---