The original post was in 2013 and today is 2016.
I had the same problem as yours and I managed to find a solution.
In case anyone is still wondering on how to tackle this problem, here is my
solution.
from django.apps import apps
User = apps.get_model(app_label=yourapplabel,
> The current User model is great for admin panel users but in frontend it
may become extra overhead for some cases. People try to create another user
attribute models and use extra joins to be able to keep extra attributes
(city, ip, locale etc.) for their users.
Use the user-profile
On Thu, Oct 10, 2013 at 9:06 AM, Burak Emre Kabakcı
wrote:
> Again, thanks for the other alternatives.
>
> Today, I have worked with auth.backends.ModelBackend and it seems it would
> be possible to separate user resources (like if the route namespace is
> "myapp", then go
Again, thanks for the other alternatives.
Today, I have worked with auth.backends.ModelBackend and it seems it would
be possible to separate user resources (like if the route namespace is
"myapp", then go with Customer table) if get_user(self, user_id) method is
called with request parameter.
On Thu, Oct 10, 2013 at 6:00 AM, Burak Emre Kabakcı
wrote:
> Thanks for the suggestions.
>
> @Andre Terra I figured out that my solution doesn't work actually. Custom
> managers is not useful in my case because underlying auth system is still
> same, it means it will also
Thanks for the suggestions.
@Andre Terra I figured out that my solution doesn't work actually. Custom
managers is not useful in my case because underlying auth system is still
same, it means it will also use same same session tables, cookies etc.
@Russell Keith-Magee Sorry, I couldn't
On Wed, Oct 9, 2013 at 6:16 AM, Burak Emre Kabakcı wrote:
> It would be nice if you allow using two different models for
> django.contrib.auth module. The current User model is great for admin panel
> users but in frontend it may become extra overhead for some cases. People
Hi, Burak,
I'm not sure if you're problem is one of too much cruft in
*frontend-related code* or in *user-facing content* but, in any case, it
seems to me that "there should be one-- and preferably only one --obvious
way to do it." [0]
Moreover, If you're having to deal with complex models for
It would be nice if you allow using two different models for
django.contrib.auth module. The current User model is great for admin panel
users but in frontend it may become extra overhead for some cases. People
try to create another user attribute models and use extra joins to be able
to keep