Hi Jorge, On Thu, Sep 19, 2013 at 11:45 PM, Jorge Cardoso Leitão <jo...@sapo.pt>wrote:
> Hi all. > > I summarise the options with some of the issues raised, and I add my own > concern. > > > One option presented here is to have both models in d.c.auth. As pointed > out by Russell and others, this causes the problem on how to define the > models such that they are not installed if they are not being > the AUTH_USER_MODEL. Assuming that this problem could be solved, the > user's procedure would be: > > To use User (+ Permissions): > install django.contrib.auth > > To use MailUser (+ Permissions): > install django.contrib.auth > set AUTH_USER_MODEL to MailUser > > The second option presented here is to add a separate app (e.g. > d.c.mailuser), which would require some imports from django.contrib.auth > (forms, views). The user's procedure would be: > > To use User (+ Permissions): > install django.contrib.auth > > To use MailUser (+ Permissions): > install django.contrib.auth > install django.contrib.mailauth > set AUTH_USER_MODEL to MailUser > > Is this correct or I'm missing something important here? > > You've correctly described the two options under discussion. There is an open question on exactly how to implement option 1, but from a public API perspective, you're correct. > If correct, I think the second option is cleaner, even though there is the > issue to minimise the repetition of code for forms, views, which was > pointed out to be easier to solve than the problem of model installation. > > > What I want to emphasise here is that django.contrib.auth has to be > installed in the case the custom model (email or other) is subclassed > from PermissionsMixin. > > This is something that I'm bringing because it seems odd that d.c.auth has > to be installed even if we want to use mailuser (or any user). Wouldn't be > possible to detach permissions to a new app, say django.contrib.perms, and > remove the step of installing d.c.auth? I mean, we are in authentication; > permissions are not related with authentication. > This has been discussed in the past -- largely because there's a difference between authentication and authorisation. If we had our time over, we'd probably make this distinction better, and put permissions into a separate app. However, we're stuck with 8 years of legacy now, and it's hard to break this. Unless you can propose a backwards-compatible approach to this problem - i.e., making sure that every existing project that *doesn't* have contrib.permissions in INSTALLED_APPS continues to work -- splitting permissions into a separate app isn't really a viable option. Also - I'm not sure I completely agree with the argument that if you're using contrib.emailauth, you shouldn't have to put contrib.auth in INSTALLED_APPS. This comes down to the idea of "what is an app" -- is it just models, or is it views, URLS, templates, and more? If it's just models I might agree with you, but an app is much more than that. If you're using contrib.emailauth, you're still using auth views, middlewares, and so on. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
