it's trace instance.
On Wednesday, April 18, 2012 at 7:39 PM, Łukasz Rekucki wrote:
> On 19 April 2012 00:55, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote:
> > Github Issues are not flexible enough for Django.
>
>
> That's rather a vague statem
Github Issues are not flexible enough for Django.
On Wednesday, April 18, 2012 at 6:53 PM, Alex Ogier wrote:
> On Wed, Apr 18, 2012 at 6:46 PM, Dalton Barreto (mailto:daltonma...@gmail.com)> wrote:
> > Em 18 de abril de 2012 18:44, philipn > (mailto:phil...@gmail.com)> escreveu:
> > > Hey fol
*every* user has access to the admin. Those users
> shouldn't need to have values (even default values, e.g. is_staff=False) for
> admin-specific fields, and admin-specific fields shouldn't be selected every
> time any user is retrieved from the database.
>
> Cheers.
> Tai.
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 Settin
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 w
On Wednesday, April 4, 2012 at 12:20 PM, Adrian Holovaty wrote:
> On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss (mailto:ja...@jacobian.org)> 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 uniqu
Like Carl I was +1 on Profiles and I'm now leaning towards the Swappable User
Models.
It's explicit (it only changes when you change the USER_MODEL setting).
It's Duck Typing which is Idiomatic in Python. ("This app depends on a user
model that defines ``email`").
If you wish to add OpenID y
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
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
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 http://gmail.com)>
> wrote:
> > If i recall on IRC the decide
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 (http:
On Tuesday, March 20, 2012 at 2:00 PM, Tom Evans wrote:
> On Tue, Mar 20, 2012 at 5:41 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote:
> > What Alex said. If it was _just_ the username then you'd have a good
> > argument for
> > a setting like that. Ho
On Tuesday, March 20, 2012 at 1:07 PM, Nan wrote:
>
> > However not all databases have this same behavior when trying to insert a
> > string that is longer than
> > the field allows. This means that for a certain subset of Django developers
> > if they didn't read the
> > releases note, or just
On Tuesday, March 20, 2012 at 11:25 AM, Alex Ogier wrote:
> There have been various proposals about replacing the User class with
> an abstract base class. Ian Lewis has a semi-workable version at
> http://ianlewis.bitbucket.org/django-newauth/index.html but its
> proposal met with resistance in pa
On Tuesday, March 20, 2012 at 10:08 AM, Tom Evans wrote:
> On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee
> mailto:russ...@keith-magee.com)> wrote:
> >
> > On 20/03/2012, at 8:38 PM, Tom Evans wrote:
> > >
> > > > * It's completely backwards compatible.
> > > >
> > > > If you've got an
On Saturday, March 17, 2012 at 1:59 AM, Russell Keith-Magee wrote:
>
> On 17/03/2012, at 12:53 AM, Jacob Kaplan-Moss wrote:
>
> > Hi folks --
> >
> > This discussion of user authentication by email is getting pretty nasty;
> > can we start over? I know there's a lot of quite legitimate frustrat
On Friday, March 16, 2012 at 11:51 PM, Henrique Bastos wrote:
> Hello,
>
> I would like to share some early stage thoughts on this matter.
>
> On Fri, Mar 16, 2012 at 5:01 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote:
> > On Friday, March 16, 2012 at 3:5
On Friday, March 16, 2012 at 3:59 PM, David Danier wrote:
> Hi,
>
> sorry, if this was said before, I haven't read the latest user discussions.
>
> I'm in favor of enhancing the auth app step by step, as everything else
> seems unlikely (haven't happend for a long time, why should it now).
> What
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, 2012 at 4:53 PM, Jacob Kaplan-Moss > (mail
On Friday, March 16, 2012 at 1:29 PM, Tom Evans wrote:
> On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss (mailto:ja...@jacobian.org)> wrote:
> > Hi folks --
> > […]
> >
>
>
> I'm not in favour of pluggable user models, as for me, they solve the
> wrong problem. A pluggable user model has
A big +1 to this. I'm willing to help where I can as well if you can find some
use for me :)
I think one of the big problems is the lack of being able to modify the user
model in any appreciable way.
Regardless of incremental improvements or not I think one possibly decent
method is that whic
I'm working up a documentation patch to make this spelled out more explicitly
but I wonder if there isn't more that should be done.
Currently ``Model.full_clean`` is not called automatically when saving a model.
This is not a big deal when manually constructing your models as you can
just do:
The major issue is that there is no way to do schema migrations in core
(currently). So there's no way to handle increasing the length of the username
field.
More comprehensive solutions require more thought to figure out the pluggable
User models.
On Friday, March 9, 2012 at 12:54 AM, Cl
On Sunday, February 26, 2012 at 4:54 AM, Łukasz Rekucki wrote:
> On 26 February 2012 06:12, Yo-Yo Ma (mailto:baxterstock...@gmail.com)> wrote:
> > After Ned's message, I'm -0, because while I'm not fond of multi-line
> > tags, I cannot offer a good alternative when it comes to multi-line
> > "with
On Sunday, February 26, 2012 at 4:38 AM, Łukasz Rekucki wrote:
> On 26 February 2012 05:55, Joe & Anne Tennies (mailto:tenn...@gmail.com)> wrote:
> > While this would be a valid argument if Django templates only rendered HTML,
> > that is not the only thing it can be used to render.
> >
>
>
On Monday, February 20, 2012 at 4:24 PM, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/20/2012 01:59 PM, Aymeric Augustin wrote:
> > The main reason for enabling time zone support by default in new
> > projects (through the settings.py template) was to store UTC in
On Monday, February 20, 2012 at 3:59 PM, Aymeric Augustin wrote:
> (subject changed because I'm forking the discussion)
>
> On 20 févr. 2012, at 21:29, Anssi Kääriäinen wrote:
>
> > Another question I have meant to ask is if 1.4 is too early to have
> > USE_TZ = True as default setting? I am af
It's not just the django.contrib apps you lose, it's any app that uses a
ForeignKey
to users. Which can be a lot of them.
On Friday, February 17, 2012 at 5:13 AM, Jonathan Slenders wrote:
>
> On 16 fév, 13:05, Tom Evans (http://googlemail.com)> wrote:
> > 75 isn't large enough these days f
On Thursday, February 16, 2012 at 6:06 PM, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Reinout,
>
> On 02/16/2012 03:35 PM, Reinout van Rees wrote:
> > Partially related question: several tickets have a pull request on
> > github instead of an svn patch. Is that eno
On Wednesday, February 15, 2012 at 5:49 PM, James Bennett wrote:
> On Wed, Feb 15, 2012 at 4:37 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote:
> > I know this has been discussed before, but I wanted to bring it up again in
> > light of the oncoming Djnago 1.4 bet
I know this has been discussed before, but I wanted to bring it up again in
light of the oncoming Djnago 1.4 beta.
Can we increase the length of the username field in auth.User? It is a common
pattern for emails to be used instead of usernames for a site, and 30 characters
makes it difficult to f
On Thursday, February 2, 2012 at 3:07 PM, Idan Gazit wrote:
> The next major revision of the admin will definitely use either less or sass,
> because it is uncivilized to work without such lovely tools nowadays.
>
> I'm less certain about bootstrap. It has some pros and cons:
>
> Pros:
> * wi
I don't think this is really appropriate in core. Django itself is completely
agnostic as to what you output, it doesn't pay attention to html, xml, csv,
css, or anything.
However if this is just an app you are making then sure. For what it's worth
Pinax (a sort of collection of apps/conventio
I'm very much -1 on this change.
To "fix" this change would require throwing an error anytime an incomplete
dictionary was passed as the data arg to a form. This would break any existing
code that relies on this (in particular it's common practice to accept a subset
of the fields via json). So
I replied to the ticket, but I'll mention it here as well. django-model-utils
has an implementation of something
that achieves the same result. It was originally from
http://paulm.us/post/3717466639/passthroughmanager-for-django
and has since been added to https://github.com/carljm/django-model
Can we provide a setting that lets you switch between the two? Then you can let
developers choose their poison?
On Friday, November 11, 2011 at 6:25 PM, hcarvalhoalves wrote:
> On 10 nov, 18:05, Paul McMillan wrote:
> > > There's no reason to not use JSON by default since it's adequate for
> >
This is a harder problem then just that. While doing that would allow a
solution to the name problem, there are more problems django.contrib.auth's
User model and it would be best to come up with a generic solution that fixes
all of these problems, instead of applying bandaid fixes.
On Thursday
ing, the tests are passing and a
functional test in a browser they all appear to be working.
https://github.com/dstufft/django/compare/master...mixin-decorators
Thoughts? Good Idea? Bad Idea?
On Thursday, September 22, 2011 at 2:49 AM, ptone wrote:
>
>
> On Sep 21, 8:44 am, D
+1
mkdir project
cd project
git init
django-admin.py startproject project
Is basically what I already do, and either way it's not terrible hard to
switch, but I think it makes a lot of sense to use CWD as the top level
directory.
On Wednesday, October 12, 2011 at 10:59 AM, Luke Plant wrot
17, 2011, at 4:32 AM, Alex Gaynor wrote:
> > On Fri, Sep 16, 2011 at 10:27 PM, Donald Stufft > (mailto:donald.stu...@gmail.com)> wrote:
> > > unittest.skip isn't a Mixin, it turns the class into an exception and
> > > raises it.
> > >
> >
>
s to do it camp, but it'd all be done with 1 code base,
and would satisfy both camps I believe?
On Friday, September 16, 2011 at 10:32 PM, Alex Gaynor wrote:
>
>
> On Fri, Sep 16, 2011 at 10:27 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote:
> > unittes
unittest.skip isn't a Mixin, it turns the class into an exception and raises it.
django.test.utils.override_settings is a mixin and it's terrible, it
dynamically creates a new subclass, and overrides 2 methods. It's magic and
more complex then need be.
On Friday, September 16, 2011 at 9:50 PM
riday, September 16, 2011 at 1:45 PM, Roald de Vries wrote:
> On Sep 16, 2011, at 6:19 PM, Donald Stufft wrote:
>
> > Documentation is being worked on, and is orthogonal to the current
> > discussion of how
> > to handle things like requiring logins with the new CBVs.
Documentation is being worked on, and is orthogonal to the current discussion
of how
to handle things like requiring logins with the new CBVs.
On Friday, September 16, 2011 at 12:08 PM, Javier Guerra Giraldez wrote:
> On Fri, Sep 16, 2011 at 8:34 AM, Reinout van Rees (mailto:rein...@vanrees.o
Gonna add this in here as well as ticket #14512
I think using decorators to modify the way a CBV behaves is the wrong way to go
about it, my reasoning is:
1) Decorators on functions make sense, since the only way to modify a function
is to wrap it, so decorators provide a shortcut to do so.
2)
I'll +1 the restriction of template tags to being arg/kwarg like. I see no
reason, other then porting already written tags, to worry about the ability to
do ``{% mytag foo as bar %}``. Personally I would think it would be desirable
to make this match python as much as possible. Python programmer
101 - 146 of 146 matches
Mail list logo
