On Tue, 2009-05-05 at 06:48 -0700, eric.frederich wrote:
> So the solution you recommend, "Have the foreign key point to the
> auth.User model and then use person.get_profile() if you need to
> access the profile object"... is that a "best practice" for dealing
> with users and profiles? Never li
So the solution you recommend, "Have the foreign key point to the
auth.User model and then use person.get_profile() if you need to
access the profile object"... is that a "best practice" for dealing
with users and profiles? Never link directly to the profile and
always to the user?
On May 4, 4:3
On Mon, 2009-05-04 at 12:51 -0700, eric.frederich wrote:
> Thanks for the reply.
>
> You're right that auth.User is not a replacement for a profile.
> Maybe I will make the training app require only that a profile model
> exists and has a particular set of fields like cost-center, manager's
> e-m
Thanks for the reply.
You're right that auth.User is not a replacement for a profile.
Maybe I will make the training app require only that a profile model
exists and has a particular set of fields like cost-center, manager's
e-mail, etc.
This way at least it wouldn't be tied to a particular imple
On Mon, 2009-05-04 at 11:35 -0700, eric.frederich wrote:
> I wrote an app that consist of an authentication backend and a single
> model "Profile" (extension of auth.User). It also has a function
> which queries ldap to get user information like their manager. We'll
> call this app my_custom_bac
5 matches
Mail list logo
