Hi Jorge, On Thu, Sep 19, 2013 at 11:45 PM, Jorge Cardoso Leitão <[email protected]>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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
