On March 12, 2012, at 14:47 , Clay McClure wrote:
> On Thursday, February 23, 2012 10:41:36 AM UTC-5, Tom Evans wrote:
> there is also the possible source of confusion stemming from the fact that
> in template language we write:
>
> {% if user.is_authenticated %}
>
> but in Python we writ
On March 15, 2012, at 11:24 , Daniel Sokolowski wrote:
> Tom makes a good point, but you can already store emails in the username,
> they are just limited to 30 characters or fewer. Lift this length restriction
> and I will be able to do everything I need without having to wait for
> contrib.
On March 15, 2012, at 12:23 , Daniel Sokolowski wrote:
> Carl, I sincerely appreciate your feedback, however again it seems no answers
> are given except more questions and considerations to consider. Why is it so
> unreasonable that we expect the end developer to be able to manually adjust
> t
Disclaimer: I was up really, really early this morning, so please bear with me
if I sound somewhat incoherent...
On March 16, 2012, at 12:29 , Tom Evans wrote:
> On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss wrote:
>> Hi folks --
>> […]
>
> I'm not in favour of pluggable user models, as f
> On Friday, March 16, 2012 at 2:08 PM, Luke Sneeringer wrote:
>> Disclaimer: I was up really, really early this morning, so please bear with
>> me if I sound somewhat incoherent...
>>
>> On March 16, 2012, at 12:29 , Tom Evans wrote:
>>
>>> On Fri, Mar 16,
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 usu
+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 https://code.djangoproject.com/wiki/ContribAuth
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
n April 4, 2012, at 15:28 , Daniel Sokolowski wrote:
> 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: au
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 mysel
ly doing this if folks on the list think it's a good
idea.
Best Regards,
Luke Sneeringer
On Feb 27, 2013, at 4:47 PM, Russell Keith-Magee
wrote:
>
>
> On Thu, Feb 28, 2013 at 4:24 AM, Alper Çuğun wrote:
>
> I looked into this today with 1.5 hitting and working on a proje
d what happens when someone defines one or the other in Django and
expects it to actually work…?
Best Regards,
Luke Sneeringer
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving ema
Ah. Thanks for the correction! :)
L
On Mar 21, 2013, at 9:13 PM, Karen Tracey wrote:
> On Thu, Mar 21, 2013 at 9:51 PM, Luke Sneeringer wrote:
> I would expect that the biggest problem with implementing something like this
> would be that MySQL is going to be a tough cookie t
In MyModelB, at least, the subclass' refresh method would win, since it's the
subclass.
I'm not sure about MyModelA, since I am not quite sure how the metaclass'
processing would intersect.
That said, if there's demand for the feature, it's probably worth this cost.
(Bias: I would use it if it
go for a euphemism, you're also (unintentionally) obfuscating, because
you're subtly communicating that it's somehow different than the standard
"won't fix".
Best Regards,
Luke Sneeringer
--
You received this message because you are subscribed to the Google Groups
an "in principle" no.
Would this be something we would be willing to change, to allow non-core Field
subclasses to be able to be validated during syncdb?
Best Regards,
Luke Sneeringer
--
You received this message because you are subscribed to the Google Groups
"Django deve
I've spent a
lot of time very recently in the code you are looking to enhance, and because
extensible APIs generally are a passion of mine. That said, take my comments
for what they are -- one of a large number of voices, where I am not a source
of substantial expertise. I hope I can help
It seems to me that "there should be one--and preferably only one--way to do
it." This would entail having two ways.
Sometimes that makes sense if they're distinct enough things conceptually, but
personally I don't see that case.
Best Regards,
Luke Sneeringer
Sent from m
across the entire framework.
Best Regards,
Luke Sneeringer
P. S. A place where I *would* love to see a better Django default would be in
the __repr__ method.
On Jul 10, 2013, at 9:46 PM, cmawebs...@gmail.com wrote:
> Hi All,
>
> Have you ever quickly set up a model, ran syncdb, an
Russell,
I would love to do the work for the email-login analogue you describe. I
actually proposed just such a thing a few months ago but was rebuffed. However,
I think this would be extremely useful. Also, I am, in fact, looking to get
involved with Django development, as I haven't quite navig
and done.
Thoughts?
Best Regards,
Luke Sneeringer
On September 18, 2013 at 7:17:53 AM, Timothy Anderegg
(timothy.ander...@gmail.com) wrote:
Hi all - I updated Russ's new wiki page to include the work I've done so far:
https://code.djangoproject.com/wiki/ContribEmailAuth Again, the
On Wednesday, September 18, 2013 6:39:13 PM UTC-6, Russell Keith-Magee
wrote:
>
>
> On Thu, Sep 19, 2013 at 3:39 AM, Luke Sneeringer
>
> > wrote:
>
>> I added the authtools approach to the wiki for completion, although I
>> believe it to be an inferior appro
On Wednesday, September 18, 2013 6:59:17 PM UTC-6, Russell Keith-Magee
wrote:
>
>
> On Thu, Sep 19, 2013 at 8:37 AM, Aaron Merriam
>
> > wrote:
>
>> Luke, I'm +1 on wanting a solution that allows "just set AUTH_USER_MODEL
>> to 'auth.EmailUser', and done".
>>
>> It'd be nice if 'swappable' co
ngo/django/blob/b2b763448f726ee952743596e9a34fcb154bdb12/django/contrib/auth/models.py#L406-L414
[2]:
https://github.com/django/django/blob/master/django/db/models/loading.py#L296
On Sep 18, 2013, at 10:03 PM, Luke Sneeringer wrote:
> On Wednesday, September 18, 2013 6:39:13 PM UTC-6, Russell
> On Sep 19, 2013, at 11:33 AM, Aaron Merriam wrote:
>
> I and my colleague (gavinw...@gmail.com) have made some edits to the wiki to
> clarify the purpose of authtools, and more accurately explain what the
> 'authtools' approach would look like. If you previously have examined
> 'option 2'
parate app which is not
> installed by default, then we solve this issue trivially without more magic.
>
>> On 19 Sep 2013 05:27, "Luke Sneeringer" wrote:
>> Bah, I should have planned my e-mailing better. Sorry for sending a third in
>> such rapid succession.
&g
> On Sep 19, 2013, at 8:06 PM, Russell Keith-Magee
> wrote:
>
> Note that EmailUser *doesn't* have a Meta: swappable definition. There is
> nothing on this model that says "I am swappable", or "I am an appropriate
> substitute for User".
>
But isn't that assuming your conclusion? The point
Sent from my iPad
> On Sep 19, 2013, at 9:24 PM, Russell Keith-Magee
> wrote:
>
>
>> On Fri, Sep 20, 2013 at 10:53 AM, wrote:
>> > Note that EmailUser *doesn't* have a Meta: swappable definition. There is
>> > nothing on this model that says "I am swappable", or "I am an appropriate
>> >
On Sep 19, 2013, at 11:15 PM, Russell Keith-Magee
wrote:
> Firstly, it leads to inconsistent usage of API. Under the current scheme, the
> default User model defines swappable. No other User model needs to. In your
> proposed usage, you've just made a special case of "Swappable models in the
On Sep 20, 2013, at 10:58 AM, gavinw...@gmail.com wrote:
> > No other User model needs to [set swappable]
>
> This would still be the case. Only models that want to conditionally load
> themselves would set swappable. User models in application code probably
> wouldn't set it, because the proj
I'm taking several different e-mail replies and attempting to conglomerate
them. Please forgive me if this is not considered socially acceptable here.
On Sep 20, 2013, at 8:42 PM, Russell Keith-Magee
wrote:
> We have two key questions here:
>
> 1) Where does the new model live? Is it going t
On Sat, Sep 21, 2013 at 5:49 PM, Timothy Anderegg <
timothy.ander...@gmail.com> wrote:
>
>>
>>- I believe that we should add an AbstractEmailUser as a subclass of
>>AbstractBaseUser, and make AbstractUser subclass it.
>> - So, right now we have AbstractBaseUser -> AbstractUser -> Use
Good evening, Russell, et. al.,
I had some time this afternoon. :-) Since there are already a couple of
reference implementations for how to do this with an e-mail app, I decided to
take a crack at an implementation that would include an EmailUser within the
base auth app. I understand we've far
Form (and similar) classes. That actually might be
the ultimate reason why this solution won't be tenable (regardless of
preferability), because any maintenance on the forms would have back-compat
implications for unknown custom User models.
L
> On 25 September 2013 01:04, Luke
On Sep 25, 2013, at 2:58 AM, Marc Tamlyn wrote:
> Other things which appear to be bugs to me:
> - You automatically register an admin class for any custom user model, which
> is likely to break validation.
> - If I set first_name and last_name as REQUIRED_FIELDS then your admin class
> will br
On Sep 26, 2013, at 2:17 AM, Rocky Meza wrote:
> This is a problem that we ran into with authtools, what we ended up doing was
> just running the tests 3 times[1]. I don't think this is a realistic
> approach within Django core though. One of the main problems with this is
> that you use ge
> On Feb 10, 2014, at 12:16 PM, Carl Meyer wrote:
>
> It's a problem that we are unable to do things
> that would otherwise be no-brainers (e.g. rendering form widgets using
> templates rather than by concatenating strings of HTML in Python code)
> because our default templating language is too s
Sent from my iPad
> On Feb 10, 2014, at 7:00 PM, Russell Keith-Magee
> wrote:
>
>
>> On Tue, Feb 11, 2014 at 9:31 AM, Luke Sneeringer wrote:
>>> On Feb 10, 2014, at 12:16 PM, Carl Meyer wrote:
>>>
>>> It's a problem that we are unable to
38 matches
Mail list logo
