Re: Using django-profiles app twice in one project.

The AUTH_PROFILE_MODULE functionality is being deprecated in Django 1.5 in favour of being able to create your own custom User models. It sounds like that would be the way to go, especially as the 1.5 release is just around the corner and trunk is normally rock solid.

Cheers,

Ryan

On 27/12/2012, at 6:01 AM, Bill Freeman <ke1g.nh@gmail.com> wrote:

On Thu, Dec 27, 2012 at 12:51 AM, Mark Shervey <markshervey@gmail.com> wrote:

I'm trying to use three different instances of the django-profiles app in one project (developed here: https://bitbucket.org/ubernostrum/django-profiles).  I can make the whole thing work fine with one instance, but when I create the three different instances with different names, I get this error:  "Exception Value:   Unable to load the profile model, check AUTH_PROFILE_MODULE in your project settings."  Is there a way to create thee different AUTH_PROFILE_MODULE settings?

I know this is probably not the best practice, but it's something we need to hack for now

I'm able to get django-profiles (https://bitbucket.org/ubernostrum/django-profiles) working fine as one app (vendor), but when I try to run two apps (vendor and coordinator) I get this error: "Exception Value:   Unable to load the profile model, check AUTH_PROFILE_MODULE in your project settings.".  I know it's because I need this variable to point at the profile app, but is there a way that I can either 1) Point it two places, or 2) create a new variable for it to resolve to?

Perhaps if you explained why you need three different profile apps, we could offer another way to go.

The design of the profile stuff only offers one known connection between User and a profile model.

I'm going to guess that you are looking to have three categories of membership, with different sets of fields.  There are two ways that I see:

  1. A single profile model with all the fields, plus either a member_type choice field, of several booleans indicating whether this member has those features (lets a member live in more that one category if that's desirable).  Then all the views have to be careful to show (or allow editing of) only what the given member type should be able to see.  The downside is that the admin as it stands will not be suitable for the less technical manager, but even this can be fixed with a custom template for this admin (though I tend to like specific non-admin profile management views when things get this squirrelly - often already useful to let users manage certain fields of their own profiles).

  2. Write your own profile feature that can choose among several distinct profile models and monkey patch it in so that any needed additional app that finds profile from user in the standard way gets your chosen profile instance.

Bill

Note: use of the term "monkey patch" is intentionally pejorative.

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.