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 <[email protected]> wrote: > > > On Thu, Dec 27, 2012 at 12:51 AM, Mark Shervey <[email protected]> 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 [email protected]. > 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. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. 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.
