Re: ticket 13125 is waiting for a design decision for 18 months

Could anyone provide a use case where I want a de-activated user to remain authenticated? Who is this option for? Why is it default? When I originally reported this ticket I did so because this is a plain security risk--non-technical users uncheck 'is active' when they want to lock someone out of

Re: Possible bug with DATABASE_ROUTERS?

I found I had another router that was being greedy. On Apr 8, 12:15 pm, "subs...@gmail.com" <subs...@gmail.com> wrote: > Hello everyone, > > I posted to the user's list but haven't heard anything. I am wondering > if this sounds like it could potentially be a bug:

Possible bug with DATABASE_ROUTERS?

Hello everyone, I posted to the user's list but haven't heard anything. I am wondering if this sounds like it could potentially be a bug: http://groups.google.com/group/django-users/browse_thread/thread/253b77110fb68a89 if this is due to my misunderstanding of routers, please forgive my posting

Re: Could the comments framework be more generic?

Heh, already put a few hours doing something like this. There's some django-discus attempts out there--have you looked at them? I haven't bothered to notice if any use the comments framework but it sure would be handy to make comments out of discus or backtype feeds or variants thereof. But

Did you know deleting an inline doesn't warn you about cascading deletes?

Neither did I until today. It is understandable that from a use-case perspective, inlines look less like 'Deletes' and more like 'Disassociates' (from the admin model). Janet thought so in the office when she nuked a few years worth of survey data, and I think its a rather blameless mistake.

Re: rethinking raw_id_fields

t (which, as I said, already > exists in the admin-ui branch), but do not want it to replace raw_id_fields; > their uses cases are completely disparate. > > On Mon, Oct 4, 2010 at 12:05 AM, subs...@gmail.com <subs...@gmail.com>wrote: > > > > > > > With the AJAX

Re: rethinking raw_id_fields

With the AJAX field implementation on the table you're free to represent the objects however you want. Yeah, there's a few things left out but did you really say 'no searching'? -Steve On Oct 3, 10:09 pm, Chuck Harmston wrote: > it's based on the assumption that the

Re: rethinking raw_id_fields

Does anyone besides me think that an AJAX field admin solution effectively deprecates raw_id_fields? I'm interested in seeing a ticket like #14370 go forward if only to close a slew of dusty old tickets about raw_id_fields. -Steve On Oct 3, 5:58 am, Marcob wrote: > Well,

Re: rethinking raw_id_fields

Edit. Edit. "I just don't think making an absolute answer to that discussion a contingency to this called-for feature /is a good idea/". There we go. On Oct 1, 11:19 am, "subs...@gmail.com" <subs...@gmail.com> wrote: > Please don't think I'm trying to hinder d

Re: rethinking raw_id_fields

And then it was so: http://code.djangoproject.com/ticket/14370 On Sep 30, 3:54 pm, "subs...@gmail.com" <subs...@gmail.com> wrote: > Yeah, I think your right. raw_id_fields is a neat idea if you really > are reluctant to use AJAX. If introducing AJAX into admin is fine,

Re: rethinking raw_id_fields

is the search_fields which kind of mirrors admin's current functionality. Or maybe I'm getting ahead of myself. -Steve On Sep 30, 2:21 pm, "burc...@gmail.com" <burc...@gmail.com> wrote: > On Thu, Sep 30, 2010 at 10:27 PM, subs...@gmail.com <subs...@gmail.com> wrote: > &g

Re: rethinking raw_id_fields

to-complete/ > > On Thu, Sep 30, 2010 at 12:34 PM, subs...@gmail.com <subs...@gmail.com> wrote: > > Hello all, > > > I was browsing the tickets and saw a few of them nagging about some > > restrictions to raw_id_fields. That they are limited to other objects >

rethinking raw_id_fields

Hello all, I was browsing the tickets and saw a few of them nagging about some restrictions to raw_id_fields. That they are limited to other objects registered in admin, that they are limited arbitrarily (relative to a regular FK) by the permissions of the user, etc. Personally, I find the little

Re: A few thoughts on Process 2 cents

;ja...@jacobian.org> wrote: > On Wed, Sep 29, 2010 at 3:21 PM, subs...@gmail.com <subs...@gmail.com> wrote: > > Speaking of which... who is interested in admin these days? Been > > trying to scare up some feedback @http://code.djangoproject.com/ticket/5833 > > for some

Re: A few thoughts on Process 2 cents

Speaking of which... who is interested in admin these days? Been trying to scare up some feedback @ http://code.djangoproject.com/ticket/5833 for some time now. On Sep 29, 2:39 pm, Jacob Kaplan-Moss wrote: > sense to have more area-specific committers. If someone's

Re: Class based models

omment" must be a "Comment" instance. > > You see the problem? Any help thinking about the solution is much > appreciated. > > Klaas > > On Sep 27, 7:57 pm, "subs...@gmail.com" <subs...@gmail.com> wrote: > > > > > I thought th

Re: Class based models

I may be dense but is this the functional equiv of cobtrib.comments get_model()? On Sep 26, 8:28 am, Klaas van Schelven wrote: > Hi all, > > I'm looking for a bit of input for making Django's apps a bit more > extendable, either by modifying Django or (preferably) by

Re: My problem with proposed Custom FilterSpec implementation

Maybe code talks? I added a patch to http://code.djangoproject.com/ticket/5833 which sums up the kind of change I am gunning for. If anyone has some feedback, awesome. -Steve On Sep 7, 3:22 pm, "subs...@gmail.com" <subs...@gmail.com> wrote: > Hello there, > > I'm watchi

My problem with proposed Custom FilterSpec implementation

Hello there, I'm watching #5833 and I have a bit of a problem with the implementation. A good example of their proposal is here: http://code.djangoproject.com/ticket/5833#comment:68 The API is remarkably similar to Gaynor's django-filters. My problem with this is that your filtering

Re: Template Tag Not Reinitialized in Loop

I recently ran into this problem too for the first time. Essentially this boils down to my not being able to use a templatetag in a loop in some cases. What is the simple workaround that I'm missing? -Steve On May 5, 2:12 pm, Apreche wrote: > I had a really strange bug in one

Re: logialogin_required does not check User.is_active

Could the burden of this work be successfully (and sensibly) shifted to the backend itself by calling something like... deactivate()? In this event, the default backend's logic could be 'set is_active = False and expire cookie' and custom backends could do (or not do) whatever they want. Forgive

Re: logialogin_required does not check User.is_active

Thanks for breaking it down. On Mar 17, 7:45 am, Russell Keith-Magee wrote: >  1) Don't touch the code. It's an annoying edge case, but it can be > caught by shortening session timeouts and making more use of > permissions. However, we should document the edge case with

Re: Security hole with authenticated sessions

Oh, and I apologize for the racy subject line =) On Apr 15, 10:51 am, "subs...@gmail.com" <subs...@gmail.com> wrote: > Please note I've already consulted secur...@djangoproject.com about > this and Jacob told me to post it here if I wanted to. > > One problem

Security hole with authenticated sessions

Please note I've already consulted secur...@djangoproject.com about this and Jacob told me to post it here if I wanted to. One problem with authenticated sessions is that, upon de-activation of a user's account, any sessions that user has remain live until they logout. I think it would be a good

Re: Validate a form's excluded fields if a value is present

Seems like a security hole, whereby people may supply additional fields if they can guess their counterparts on the model. Its 'exclude', not 'exclude_maybe'. ...Unless I'm missing something fundamental. -S On Mar 31, 9:11 pm, orokusaki wrote: > I'm working on an SAAS

Re: Potential bugs / need for extra documentation in 'Customizing the comments framework'

> I can't think of any reason that a production server should behave > differently to a development server on the sorts of issues you're > referring to. If there's a problem, I would be highly surprised if > it's caused by the fact you're running under wsgi, rather than the > devserver. There may

Re: GSoC: Data importation class

Or let's circumvent the whole problem by stopping this garbage at the gates! On Mar 25, 11:34 pm, Richard Laager wrote: > This might be a bit off-topic for this thread, but legacy data is why I > wish frameworks supported some concept of warnings in their validation > code. >

Re: GSoC: Data importation class

> On 25/03/10 17:47, subs...@gmail.com wrote: > > >> The last bit sounds a bit nebulous. You could optimise it by not > >> including any empty files, or be a bit more specific about what the > >> empty files are meant to represent. :) > > > startapp, s

Re: GSoC: Data importation class

> > Adding system administration functionality to Django, which is what this > > monitoring is, feels like the wrong approach. I see here you probably meant its appropriate elsewhere but not in django. Gotcha. Thought I'd try anyhow. -- You received this message because you are subscribed to

Re: GSoC: Data importation class

to get data into a shape where it _will_ work, rather than resorting to scripting the entirety. > On Thu, 2010-03-25 at 09:07 -0700, subs...@gmail.com wrote: > > mix). With talk of model-level validation, the first approach is > > becoming increasingly invalid, > > That's not

GSoC: Data importation class

If we could visualize the entirety of data within django-projects, we would probably see that this 'data economy' is growing exponentially year-over-year. However, I know of no guided way to actually get this data into a project that's been converted to Django. There are two methods I generally

Potential bugs / need for extra documentation in 'Customizing the comments framework'

I got myself into a situation with a project and some comments models. Perhaps with some discussion we can uncover genuine code-bugs, but my knowledge about this is limited and so I'm just calling for a documentation update. A major reason I'm asking for some notice of these things to appear

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

I guess at some point its just feature-clut. Its a use case we _could_ encompass, but would you really even find yourself using it? I don't see the technical difference here--pre-syncdb, you either have to 'wade' to the database or you have to 'wade' to this item in settings.py. Its not as though

Adding takes_context argument to filters

Hello there, I'm interested in allowing a particular filter I have to check the context. Trolling for reasons for and against, and if it makes no difference I'll file a ticket and provide some patches. Its useful for me in cases where the thing I am processing has already been processed before.

Re: Potential bug in select_related() as of Beta

Sorry to be pushy, but I would like to bump this or find the next tree to bark up. -S On Feb 17, 9:42 pm, "subs...@gmail.com" <subs...@gmail.com> wrote: > bmodels.Contact.objects.select_related('IR_contact','consumer_contact','pro­gram','consumer').filter(consumer__file=file)

Re: Potential bug in select_related() as of Beta

le are en route to PyCon, so responses may be a bit slow. > > On Wed, Feb 17, 2010 at 3:30 PM, subs...@gmail.com <subs...@gmail.com> wrote: > >http://dpaste.com/160722/ > > > class Contact(models.Model): > >    program = models.ForeignKey('agency.Program') > >

Re: Potential bug in select_related() as of Beta

Field(Information,verbose_name='Information Requested') On Feb 17, 4:15 pm, Jeremy Dunck <jdu...@gmail.com> wrote: > We'll need your model definitions in order to help much. > > On Wed, Feb 17, 2010 at 2:54 PM, Steve <subs...@gmail.com> wrote: > > Hello all, > &g

Re: Multiple database support: Request for feedback and testing

Oh, I see from a later message by Alex that Meta.using was removed. -1! -S On Dec 5, 3:12 pm, "subs...@gmail.com" <subs...@gmail.com> wrote: > Isn't 'database' going to be an option in a model's Meta? In this > situation, is admin going to attempt to do something differen

Re: Multiple database support: Request for feedback and testing

Isn't 'database' going to be an option in a model's Meta? In this situation, is admin going to attempt to do something different? -S On Dec 4, 9:18 am, Nan wrote: > > 1) Ignore the problem. Admin works on the default database, but > > nowhere else. This is certainly less

Re: App Engine port

Basic demand side problem. When an app stands up and solves the real issues (which, as the DjangoCon presentation proved, there were many) involving App Engine and Django, then I (and the demographic of developers I statistically represent) will become excited. -S On Feb 6, 9:51 am, David