Re: GSoC 2012: Security Enhancements

Hi Rohan, Apologies for the lack of response. Anyone who has put effort into writing up a proposal certainly deserves a response of some kind, so we've dropped the ball here. In our defence, here's a couple of the reasons why your proposal probably hasn't got a wild response: * You've pick

Re: GSoC 2012: Security Enhancements

Hi again, I really couldn't understand the response this post has got. It deserved at least a little feedback, positive or negative. I guess I wont be submitting this over melange. Still, I have put some effort and research in the proposal. So if possible I would like to know if it had anything o

Re: auth.user refactor: the profile aproach

> > I don't know of a single framework out there besides Django that ships > with a fixed model for its users. > I totally understand this, but I also think the fact that Django *does* ship with this stuff creates a baseline security and quality for logging into most Django-powered web apps. I'

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 isn'

Re: [GSoC 2012] Schema Alteration API proposal

On Thursday, 5 April 2012 21:25:19 UTC+5:30, Andrew Godwin wrote: > > Just thought I'd chime in now I've had a chance to look over the current > proposal (I looked at the current one you have in the GSOC system): > > - When you describe feeding things in from local_fields, are you > referring t

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 w

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 expects

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 is

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 practica

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 inte

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 > simply allowing the admin and o

Re: Allow changing form field properties after form creation

On 6 April 2012 07:26, Beres Botond wrote: > Hi Chris, > > Isn't it this what you are trying to do? > > class DocumentForm(ModelForm): >        def __init__(self, *args, **kwargs): >                super(MyForm, self).__init__(*args, **kwargs) >                self.fields['title'].required = False

Re: Allow changing form field properties after form creation

Hi Chris, Isn't it this what you are trying to do? class DocumentForm(ModelForm): def __init__(self, *args, **kwargs): super(MyForm, self).__init__(*args, **kwargs) self.fields['title'].required = False Which works perfectly fine. You can tweak pretty much

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 c

Re: django.contrib.sites.managers.CurrentSiteManager spanning more than one model

The only hard part is modifying the _validate_field_name method. get_query_set uses the regular filtering mechanism, so it actually works out of the box with the __ field spanning. I will provided a patch (once I clean up the code), then you can see that it is quite a small fix and may be worth int

Re: django.contrib.sites.managers.CurrentSiteManager spanning more than one model

On Thu, Apr 5, 2012 at 11:46 AM, Rory Geoghegan wrote: > We currently have that code written. Is it worth turning that into a > patch for contrib.sites, with unit tests et al, and pushing upstream > into django? Should I fill out a bug? I don't think this added complexity/functionality is worth a

Re: Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django

Interesting, you are right. It's still a little strange to me to be accessing class attributes via the self object, but I suppose it is more flexible than accessing them as User.MALE etc. which would make renaming the class awkward. Best, Alex Ogier On Apr 5, 2012 2:16 PM, "Łukasz Rekucki" wrote:

Re: Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django

On 5 April 2012 19:45, Alex Ogier wrote: > >> >> class User(models.Model): >> >>     MALE = 0 >> >>     FEMALE = 1 >> >>     GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')] >> >>     gender = models.IntegerField(choices=GENDERS) >> >> >> >>     def greet(self): >> >>         return {MALE: 'Hi, boy'

Re: Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django

> >> class User(models.Model): > >> MALE = 0 > >> FEMALE = 1 > >> GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')] > >> gender = models.IntegerField(choices=GENDERS) > >> > >> def greet(self): > >> return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender] > >> > > I' sure

django.contrib.sites.managers.CurrentSiteManager spanning more than one model

Hi, The current implementation of CurrentSiteManager only 'spans' one model. For example, take the following code: class Foo(models.Model): [...] site = models.OneToOneField('sites.Site') on_site = CurrentSiteManager("site") class Bar(models.Model): [...]

Re: auth.user refactor: the profile aproach

Hi iPhoneから送信 On 2012/04/06, at 0:29, "Daniel Sokolowski" wrote: > The more I think about it the more it makes sense to me to have a base User > model just a stub with a user Identifier and password field. Sure one could > argue for less ore more fields, but I think the idea > is to pick some

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 on the current user model? e.g. username,

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, you'd need to tell the a

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 need > to add a convolute

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 st

Re: [GSoC 2012] Schema Alteration API proposal

Just thought I'd chime in now I've had a chance to look over the current proposal (I looked at the current one you have in the GSOC system): - When you describe feeding things in from local_fields, are you referring to that being the method by which you're planning to implement things like sy

Re: auth.user refactor: the profile aproach

Can someone give me an example please where a swappable model would benefit me as opposed to one-to-one model inheritance, FKs, or even proxy models? Django does this very well and allows for seamless up/down traversal. It seems that swappable models are nothing but a different way of doing wha

Re: GSOC2012 Proposal for 'Finishing off the App Refactor'

Enhanced proposal: *Proposal For “Finishing off the App Refactor”* * * * * *Abstract* --- Django currently assumes that an application will only ever be loaded once, and that the name of that application will be determined solely by the package name holding the models.py. A gread

Re: Allow changing form field properties after form creation

Hi Brian, On Thu, 5 Apr 2012, Brian Neal wrote: On Thursday, April 5, 2012 6:49:20 AM UTC-5, Chris Wilson wrote: class DocumentForm(ModelForm):      title = models.Document._meta.get_field('title').formfield(required=False) You can already replace and tweak the fields in a w

Re: Allow changing form field properties after form creation

On Thursday, April 5, 2012 6:49:20 AM UTC-5, Chris Wilson wrote: > > Hi all, > > I've added this as a ticket but I wanted to make sure that the core > and forms developers have a chance to see and interact with it, so I'm > posting it here too. You can find the ticket at: >

Re: Allow changing form field properties after form creation

Hi Nate, On Thu, 5 Apr 2012, Nate Bragg wrote: They don't "have" to be replaced in a subclass in the way you showed. Perhaps it isn't perfectly DRY, but whats so bad about naming the field explicitly? The fact that we're building reusable components and we want people to be able to subclass

Re: Allow changing form field properties after form creation

They don't "have" to be replaced in a subclass in the way you showed. Perhaps it isn't perfectly DRY, but whats so bad about naming the field explicitly? Anyhow, when it comes specifically to widgets, the Meta class already has a 'widgets' attribute already that lets you specify that. I would soo

Allow changing form field properties after form creation

Hi all, I've added this as a ticket but I wanted to make sure that the core and forms developers have a chance to see and interact with it, so I'm posting it here too. You can find the ticket at: Currently, if I want to tweak the properties of so

Re: Proposal: upgrading the choices machinery for Django

2012/4/4 Łukasz Langa : > Wiadomość napisana przez Tom Evans w dniu 4 kwi 2012, o godz. 18:40: > >> The class definition grates. When we say things like: >> >>  class Gender(Choices): >>    male = Choice("male") >> >> That says to me that Gender.male is mutable. Ick. > > Thanks for your feedback. D

Re: Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django

Am 05.04.2012 10:03, schrieb Łukasz Rekucki: On 5 April 2012 09:45, Thomas Guettler wrote: Hi, I created a ticket, incl. patch https://code.djangoproject.com/ticket/18062 While the example itself is useful, I don't really think Django's documentation should state obvious facts about Pyt

[GSOC Announce] One day remaining for applications

Hi everyone, Just a quick reminder that there's only one day left for GSOC applications - the deadline that they must be filed on the GSOC website by is April 6th, 19:00 UTC (roughly 30 hours from now). Andrew -- You received this message because you are subscribed to the Google Groups "Djan

Re: Proposal: upgrading the choices machinery for Django

Wiadomość napisana przez Stephen Burrows w dniu 5 kwi 2012, o godz. 07:41: > I generally like this idea, except for the implicit integer ids based > on declaration order. Thanks for your input. I will add the ability to explicitly set .id values for each Choice in the next release. > As people

Re: Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django

Wiadomość napisana przez Łukasz Rekucki w dniu 5 kwi 2012, o godz. 10:03: > I' sure you meant: > > def greet(self): >return {self.MALE: 'Hi, boy', self.FEMALE: 'Hi, girl.'}[self.gender] > > Unless you defined MALE/FEMALE as globals too :) Otherwise you'll get > a NameError. Also, a minor d

Re: Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django

On 5 April 2012 09:45, Thomas Guettler wrote: > Hi, > > I created a ticket, incl. patch > > https://code.djangoproject.com/ticket/18062 > > While the example itself is useful, I don't really think Django's documentation should state obvious facts about Python, especially false ones. > > Am 04.04

Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django

Hi, I created a ticket, incl. patch https://code.djangoproject.com/ticket/18062 Am 04.04.2012 18:41, schrieb Adrian Holovaty: 2012/4/3 Łukasz Langa: Explicit choice values:: GENDER_MALE = 0 GENDER_FEMALE = 1 GENDER_NOT_SPECIFIED = 2 GENDER_CHOICES = ( (GENDER_MALE, _('male')