Re: auth.user refactor: the profile aproach

Sorry for reviving this thread. Are the auth mixins fork from ogier going to be commited to the django master branch anytime soon? I'd like to "officially" use it. Is there any documentation available? Thanks in advance. Am Dienstag, 3. April 2012 02:35:41 UTC+2 schrieb Jacob Kaplan-Moss: > >

Re: auth.user refactor: the profile aproach

On 3 April 2012 04:56, Alex Ogier wrote: > I get that Django's core is very accustomed to the relational database mode > of thinking: "If a User might own a Twitter handle, then let's create a > table of twitter handles in the twitter-auth app, and foreign key back to > the

Re: auth.user refactor: the profile aproach

On Tue, Apr 10, 2012 at 6:04 PM, Alex Ogier wrote: > Hi Tom, > > The best rounded description with pros and cons is Solution 2a on > https://code.djangoproject.com/wiki/ContribAuthImprovements > > You are correct that I am primarily thinking of pluggable authentication >

Re: auth.user refactor: the profile aproach

Tai, I think you are overestimating the importance of a "pluggable" user model. If 100 apps all try to add fields to the User model then of course bloat and performance issues and field name conflicts will be a problem. But I don't think that will happen. There are very good reasons for an app

Re: auth.user refactor: the profile aproach

On Tue, Apr 10, 2012 at 11:58 PM, Tom Evans wrote: > On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis wrote: > > Hi, > > > > I'm not getting why you *have* to add fields to the User model to store > data > > pertaining to the user. There is nothing in the

Re: auth.user refactor: the profile aproach

Sorry I was mentioning that in agreement with documenting this. I had even toyed with the idea of making the default template provide a project level user model by default (to cement the fact that it's project concern not a app concern) but that is most likely more trouble than it's worth.

Re: auth.user refactor: the profile aproach

Sure. But will how will users be guided to making that distinction when developing their pluggable apps? I haven't seen anything that would prevent developers from doing this, and if the admin itself does it, isn't that a green light for everyone to do it? Another problem with pluggable apps

Re: auth.user refactor: the profile aproach

I think swappable user models should be used as a replacement for get_profile() not per app profiles. It should be used for generic-esque data about a User. e.g. Email, phone number, name, etc. It should not be used for app specific data about a user, e.g. Default Gallery, Notification

Re: auth.user refactor: the profile aproach

Alex, I think the problem with this aspect of your proposal is that it signals a green light for other pluggable apps to follow Django's lead and provide mixing which must be added to their `User` model in order to use the pluggable app, instead of creating a profile model for their pluggable

Re: auth.user refactor: the profile aproach

Tom, I proposed mixins to solve the specific problem: there is an app that needs a specific contract from a model it wants to authenticate or otherwise interact with, how can we make it easy for developers to implement that contract? Most apps don't actually need that much though. There are a

Re: auth.user refactor: the profile aproach

Hi Tom, The best rounded description with pros and cons is Solution 2a on https://code.djangoproject.com/wiki/ContribAuthImprovements You are correct that I am primarily thinking of pluggable authentication when I think of this new user model. The reason is that there is nothing stopping you

Re: auth.user refactor: the profile aproach

Hello! The page you linked, Tom, concludes with this line: "Discussion on django-developers suggests that complete consensus is unlikely; Currently awaiting BDFL mandate." Since we have the BDFL mandate, shouldn't we update the page?

Re: auth.user refactor: the profile aproach

On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis wrote: > Hi, > > I'm not getting why you *have* to add fields to the User model to store data > pertaining to the user. There is nothing in the proposal for pluggable user > models that says you can never have a seperate model with a

Re: auth.user refactor: the profile aproach

Hi, I'm not getting why you *have* to add fields to the User model to store data pertaining to the user. There is nothing in the proposal for pluggable user models that says you can never have a seperate model with a foreign key to the user model. It just means that you can define your user model

Re: auth.user refactor: the profile aproach

Tom, Thanks for raising those issues. I would just like to add that I hope to see fields currently in `User` that are required by the admin (is_staff, etc.), moved to an admin profile model, and not simply made available through mixins that are still required by every `User` model that gets

Re: auth.user refactor: the profile aproach

On Fri, Apr 6, 2012 at 7:31 PM, Alex Ogier wrote: > Tai, read https://gist.github.com/2289395 for a summary of many reasons why > I think profiles are a bad idea, and unifying multiple profiles is an even > worse idea. > > Best, > Alex Ogier Hi Alex Is

Re: auth.user refactor: the profile aproach

On Apr 7, 2012, at 5:25 AM, Florian Apolloner wrote: > Hi Adrian, > > On Tuesday, April 3, 2012 10:34:18 PM UTC+2, Adrian Holovaty wrote: > I chatted about this with Jacob on IRC, and we reached consensus on > this approach. I'd like to get moving on this and would be happy to > take it on

Re: auth.user refactor: the profile aproach

Hi Adrian, On Tuesday, April 3, 2012 10:34:18 PM UTC+2, Adrian Holovaty wrote: > > I chatted about this with Jacob on IRC, and we reached consensus on > this approach. I'd like to get moving on this and would be happy to > take it on myself, starting next week. > I'd like to help out there, could

Re: auth.user refactor: the profile aproach

On Friday, April 6, 2012 at 2:29 PM, Daniel Sokolowski wrote: > How is the final approach chosen ? > > > > Adrian made the call earlier this week - we're going with Alex's approach. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: auth.user refactor: the profile aproach

How is the final approach chosen ? From: Alex Ogier Sent: Friday, April 06, 2012 2:31 PM To: django-developers@googlegroups.com Subject: Re: auth.user refactor: the profile aproach Tai, read https://gist.github.com/2289395 for a summary of many reasons why I think profiles are a bad idea

Re: auth.user refactor: the profile aproach

Tai, read https://gist.github.com/2289395 for a summary of many reasons why I think profiles are a bad idea, and unifying multiple profiles is an even worse idea. Best, Alex Ogier On Fri, Apr 6, 2012 at 6:15 AM, Tai Lee wrote: > Alex Ogier, > > Is it really better to

Re: auth.user refactor: the profile aproach

Alex Ogier, Is it really better to require users to create their own User model that behaves like an admin user, instead of just shipping with a self contained admin user (as a profile model) without the auth component? If the auth app was purely a stub to connect different profiles and

Re: auth.user refactor: the profile aproach

I think this proposal will make more sense if people stop thinking "If someone wants to use contrib.auth, then why do we need another crufty interface to swap out auth.User?" Instead think of someone who wants to use contrib.admin but not be stuck with contrib.auth. The point of this proposal

Re: auth.user refactor: the profile aproach

Nothing about this proposal prevents this. And in that case, no those 2 apps would not be able to be used together. But this is hardly the first time that 2 apps cannot be used together. because of choices made like that on the app owner. On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff

Re: auth.user refactor: the profile aproach

I very much share Tai's concerns about the swappable user model introducing incompatibilities. Imagine two apps, each of which requires an "age" attribute on the user model. But suppose one of those apps expects age to be the number of years since that user's birth and one of those apps

Re: auth.user refactor: the profile aproach

I think we need three different kinds of models, Identity, Profile and Authentication Info. * The Identity model should have all fields shared by many apps. * Each app can have its own Profile model. If a field is not shared with other apps, just put it in the Profile model. * Since password

Re: auth.user refactor: the profile aproach

Thanks Anssi, but I think the interface contract for a pluggable app *should* be on the pluggable app's profile, instead of relying on an assumption that developers will have created a user model that is duck typed to suit every pluggable app installed in the project (which might not be

Re: auth.user refactor: the profile aproach

On 06/04/2012, at 7:27 AM, Jacob Kaplan-Moss wrote: > On Thursday, April 5, 2012 at 12:04 PM, Alex Gaynor wrote: >> I haven't been following this thread nearly closely enough. But ISTM that >> any abstraction that doesn't let the admin work with any User (assuming it >> supplies the right

Re: auth.user refactor: the profile aproach

On Thursday, April 5, 2012 at 12:04 PM, Alex Gaynor wrote: > I haven't been following this thread nearly closely enough. But ISTM that > any abstraction that doesn't let the admin work with any User (assuming it > supplies the right interface) isn't very useful, and rather misses the point. >

Re: auth.user refactor: the profile aproach

On Apr 5, 11:29 pm, Tai Lee wrote: > But I still don't see how a swapped in `User` model which *has* to behave in > a specified way so that it can work with the Django admin and any other > pluggable apps that might have special requirements, is any better than >

Re: auth.user refactor: the profile aproach

On 06/04/2012, at 3:09 AM, Ian Lewis wrote: > The good part about swappable user models is that you don't need to > necessarily fix the model's DB fields in advance. Your identifier and > password's length and other properties can be user defined and can be > reflected in the DB. > > Django

Re: auth.user refactor: the profile aproach

l Keith-Magee > Sent: Wednesday, April 04, 2012 10:44 AM > To: django-developers@googlegroups.com > Subject: Re: auth.user refactor: the profile aproach > > > On 04/04/2012, at 8:44 PM, Tai Lee wrote: > >> I'm not so sure that it's necessary or even desirable to solve the &

Re: auth.user refactor: the profile aproach

On Thu, Apr 5, 2012 at 1:02 PM, Adrian Holovaty wrote: > 2012/4/5 Ian Lewis : > > I'm curious though how the admin fits into your ideas. If you wanted to > use the > > admin, would you have to use a User model that has and or supports all > the > > cruft

Re: auth.user refactor: the profile aproach

2012/4/5 Ian Lewis : > I'm curious though how the admin fits into your ideas. If you wanted to use > the > admin, would you have to use a User model that has and or supports all the > cruft on the current user model? e.g. username, password, email, permissions > etc. Yes,

Re: auth.user refactor: the profile aproach

Hi. iPhoneから送信 On 2012/04/04, at 5:34, Adrian Holovaty wrote: > First, some background: I haven't used the built-in User module in > several years. I always write my own User model from scratch -- it's > so nice and clean. Want a twitter_username field? Just add it. No

Re: auth.user refactor: the profile aproach

No I can not stomach a swappable User model or the LFK approach, so thank you for voicing your concerns. From: Tai Lee Sent: Wednesday, April 04, 2012 9:37 PM To: django-developers@googlegroups.com Subject: Re: auth.user refactor: the profile aproach Are we really sure that we can or should

Re: auth.user refactor: the profile aproach

Subject: Re: auth.user refactor: the profile aproach On 04/04/2012, at 8:44 PM, Tai Lee wrote: I'm not so sure that it's necessary or even desirable to solve the "general" problem of swappable models. If anyone can swap any model by changing a setting, that sounds like a recipe for confu

Re: auth.user refactor: the profile aproach

LazyForeignKey will not solve any problem that can't be solved now, and we have to introduce a new concept. It sounds like, when we encounted a hard problem, we give it a new name, instead of trying to solve it. Moreover, to support multiple user models, each app should be able to link to a

Re: auth.user refactor: the profile aproach

Are we really sure that we can or should stomach a swappable User model as a special case? It's highly likely that I am missing something (or a few things), but aren't the main benefits of swapping the User model just to avoid making a backwards incompatible change, and to avoid making

Re: auth.user refactor: the profile aproach

On 05/04/2012, at 12:20 AM, Adrian Holovaty wrote: > On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss wrote: >> On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: >> >> My point is that there is nothing about this problem that is unique to User. >> Django's

Re: auth.user refactor: the profile aproach

On 04/04/2012, at 10:57 PM, Jacob Kaplan-Moss wrote: > On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: >> My point is that there is nothing about this problem that is unique to User. >> Django's own codebase contains another example of exactly the same pattern >> --

Re: auth.user refactor: the profile aproach

I agree with Luke that more explicit is better then implicit when dealing with the user.data. From: Luke Sneeringer Sent: Tuesday, April 03, 2012 2:46 PM To: django-developers@googlegroups.com Subject: Re: auth.user refactor: the profile aproach So, after reading this, I think I really only

Re: auth.user refactor: the profile aproach

On Wed, Apr 4, 2012 at 11:22 AM, Donald Stufft wrote: > Not adding anything, just saying that Architecture Astronaut is the best > term ever for this. Here's the source of that term: http://www.joelonsoftware.com/articles/fog18.html

Re: auth.user refactor: the profile aproach

On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss wrote: > On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > > My point is that there is nothing about this problem that is unique to User. > Django's own codebase contains another example of exactly the same

Re: auth.user refactor: the profile aproach

On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > My point is that there is nothing about this problem that is unique to User. > Django's own codebase contains another example of exactly the same pattern -- > Comments. As the original author and designer of that pattern, I

Re: auth.user refactor: the profile aproach

On 04/04/2012, at 8:44 PM, Tai Lee wrote: > I'm not so sure that it's necessary or even desirable to solve the "general" > problem of swappable models. If anyone can swap any model by changing a > setting, that sounds like a recipe for confusion to me. Sure, but that's not what I've proposed.

Re: auth.user refactor: the profile aproach

Regarding swappable models: In general, good reusable applications allow developers to substitute in their own class or subclass for the module author's default by either a custom setting or an argument to a method. In general, there's no reason why that mechanism is insufficient, and should be

Re: auth.user refactor: the profile aproach

I'm not so sure that it's necessary or even desirable to solve the "general" problem of swappable models. If anyone can swap any model by changing a setting, that sounds like a recipe for confusion to me. Seems to me that the main benefit of the swappable models approach is just to avoid

Re: auth.user refactor: the profile aproach

On 04/04/2012, at 4:34 AM, Adrian Holovaty wrote: > On Tue, Apr 3, 2012 at 9:28 AM, Alex Ogier wrote: >> I have written up a little bit about the alternate proposal that I made a >> while ago, Solution 2a >> from https://code.djangoproject.com/wiki/ContribAuthImprovements

Re: auth.user refactor: the profile aproach

On 04/04/2012, at 4:42 AM, Carl Meyer wrote: > On 04/03/2012 02:34 PM, Daniel Sokolowski wrote: >> Correct me if I’m wrong but both LFK or a swappable user model approach >> like your fail to address issue of extensibility. If today my project is >> authorizing with username and password and

Re: auth.user refactor: the profile aproach

On 04/04/2012, at 4:31 AM, Carl Meyer wrote: > > By the way, I took the liberty of removing from the wiki page the > references to models/settings circular dependencies, because AFAIK the > statements made about it on the wiki page were simply incorrect. > Importing settings does _not_

Re: auth.user refactor: the profile aproach

+1. Also, I'd like to help. :) L On April 3, 2012, at 15:34 , Adrian Holovaty wrote: > On Tue, Apr 3, 2012 at 9:28 AM, Alex Ogier wrote: >> I have written up a little bit about the alternate proposal that I made a >> while ago, Solution 2a >> from

Re: auth.user refactor: the profile aproach

On 04/03/2012 02:34 PM, Daniel Sokolowski wrote: > Correct me if I’m wrong but both LFK or a swappable user model approach > like your fail to address issue of extensibility. If today my project is > authorizing with username and password and tomorrow I wish to add > OpenAuth then my User model is

Re: auth.user refactor: the profile aproach

lex.og...@gmail.com) > Sent: Tuesday, April 03, 2012 10:28 AM > To: django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com) > Subject: Re: auth.user refactor: the profile aproach > > > > > Hi developers, > > I ha

Re: auth.user refactor: the profile aproach

On Tue, Apr 3, 2012 at 9:28 AM, Alex Ogier wrote: > I have written up a little bit about the alternate proposal that I made a > while ago, Solution 2a > from https://code.djangoproject.com/wiki/ContribAuthImprovements I just now got around to reading Jacob's solution and

Re: auth.user refactor: the profile aproach

On 04/03/2012 08:28 AM, Alex Ogier wrote: > I have written up a little bit about the alternate proposal that I made > a while ago, Solution 2a > from https://code.djangoproject.com/wiki/ContribAuthImprovements > > In addition to other arguments, there is a point-by-point breakdown of > what I

Re: auth.user refactor: the profile aproach

So, after reading this, I think I really only have a couple questions/concerns: 1. What, if anything, is the primary key on the base User model? Is it the identifier? If so, can it be specified as the primary key, rather than unique=True, db_index=True? If it's not the primary key, is it the

Re: auth.user refactor: the profile aproach

DISCLAIMER: I'm just a hobbyist posting to an experienced developers' list. I for one really like Jacob's approach. I may be missing something, but my only concern right now is being able to infer which profiles are attached to the User model at any given point. Moreover, I'd like to be able to

Re: auth.user refactor: the profile aproach

Hi developers, I have written up a little bit about the alternate proposal that I made a while ago, Solution 2a from https://code.djangoproject.com/wiki/ContribAuthImprovements In addition to other arguments, there is a point-by-point breakdown of what I feel are the weaknesses in Jacob's

Re: auth.user refactor: the profile aproach

Hi Jacob, Thanks for taking the time to tackle this issue! On Tue, Apr 3, 2012 at 2:35 AM, Jacob Kaplan-Moss wrote: > Hi folks -- > > I've written up a proposal for how *I* would like to address refactoring > auth.user: https://gist.github.com/2245327. > > In essence, this

Re: auth.user refactor: the profile aproach

On Tuesday, April 3, 2012 at 3:37 AM, Tai Lee wrote: > I like this proposal because I am a big fan of a stripped down `User` model > which is basically just an ID, whic provides a common hook into > groups/permissions and other django and 3rd party profiles. > > What I don't like is the magical

Re: auth.user refactor: the profile aproach

I like this proposal because I am a big fan of a stripped down `User` model which is basically just an ID, whic provides a common hook into groups/permissions and other django and 3rd party profiles. What I don't like is the magical `data` bag (accessing `User.data` and filter lookups), the

Re: auth.user refactor: the profile aproach

On Mon, Apr 2, 2012 at 11:04 PM, Donald Stufft wrote: > Identity doesn't have anything to do with automatically dispatching > users. All it is is a unique identifier. That's all this proposal honestly > enforces that your users have. Some single piece of identifiable

Re: auth.user refactor: the profile aproach

On Monday, April 2, 2012 at 10:56 PM, Alex Ogier wrote: > I realize that arguing with a BDFL might get me nowhere, but I don't think > that multi-profile + select_related + proxy attributes on the user model is > the proper approach for users going forward. The proposal makes some basic > sense

Re: auth.user refactor: the profile aproach

On 03/04/2012, at 8:35 AM, Jacob Kaplan-Moss wrote: > Hi folks -- > > I've written up a proposal for how *I* would like to address refactoring > auth.user: https://gist.github.com/2245327. > > In essence, this does two things: > > * Vastly "prunes" the required fields on auth.user. The only

Re: auth.user refactor: the profile aproach

On 04/02/2012 06:35 PM, Jacob Kaplan-Moss wrote: > I've written up a proposal for how *I* would like to address refactoring > auth.user: https://gist.github.com/2245327. +1 from me. One minorish nit: I think that "in the face of ambiguity, refuse the temptation to guess" should apply equally to

Re: auth.user refactor: the profile aproach

I realize that arguing with a BDFL might get me nowhere, but I don't think that multi-profile + select_related + proxy attributes on the user model is the proper approach for users going forward. The proposal makes some basic sense as an incremental improvement on the current status quo of a

Re: auth.user refactor: the profile aproach

If we use __unicode__ (which i'm fine with) then it needs to follow the same resolution path as user.data[] does. On Monday, April 2, 2012 at 9:25 PM, Anssi Kääriäinen wrote: > On Apr 3, 4:20 am, Donald Stufft > wrote: > > If i recall on IRC the

Re: auth.user refactor: the profile aproach

On Apr 3, 4:20 am, Donald Stufft wrote: > If i recall on IRC the decider was to just create a display field (e.g. > user.data["display"]) that the default profiles can provide (and can be > overridden by other profiles of course). My problem with this is that for

Re: auth.user refactor: the profile aproach

If i recall on IRC the decider was to just create a display field (e.g. user.data["display"]) that the default profiles can provide (and can be overridden by other profiles of course). On Monday, April 2, 2012 at 9:17 PM, Anssi Kääriäinen wrote: > On Apr 3, 3:35 am, Jacob Kaplan-Moss

auth.user refactor: the profile aproach

Hi folks -- I've written up a proposal for how *I* would like to address refactoring auth.user: https://gist.github.com/2245327. In essence, this does two things: * Vastly "prunes" the required fields on auth.user. The only things left are an "identifier" (which could be username, email,