Re: Delete cascade up for Inherited models

[Rahul]

Thanks carl for updating me about this fix.
I was using 1.3-beta-1 version of django. When i run it with latest
trunk version it works fine.


Thanks,
Rahul Priyadarshi

On Feb 24, 9:16 am, Carl Meyer  wrote:
> Hi Rahul,
>
> On Feb 21, 12:56 am, Rahul  wrote:
>
> > When i ran the test cases ( "modeltests/delete/
> > test_inheritance_cascade_up" ) which were doing cascade up for
> > inherited models, it failed for DB2 cause of the fact that DB2 doesn't
> > support initial deferred constraint checks like behavior, hence it is
> > must to execute delete statement from child to parent, however when I
> > traced the sql execution for "modeltests/delete/
> > test_inheritance_cascade_up" test case, what I find is Django tried to
> > execute delete sql from parent to child. I already had the flag
> > "can_defer_constraint_checks" set to false inside DatabaseFeatures.
>
> What version of Django are you developing against? This sounds very
> much like #15118 [1], which is present in the 1.3 beta but was fixed
> in trunk over a month ago by r15246 [2].
>
> Carl
>
>   [1]http://code.djangoproject.com/ticket/15118
>   [2]http://code.djangoproject.com/changeset/15246

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Delete cascade up for Inherited models

[Carl Meyer]

Hi Rahul,

On Feb 21, 12:56 am, Rahul  wrote:
> When i ran the test cases ( "modeltests/delete/
> test_inheritance_cascade_up" ) which were doing cascade up for
> inherited models, it failed for DB2 cause of the fact that DB2 doesn't
> support initial deferred constraint checks like behavior, hence it is
> must to execute delete statement from child to parent, however when I
> traced the sql execution for "modeltests/delete/
> test_inheritance_cascade_up" test case, what I find is Django tried to
> execute delete sql from parent to child. I already had the flag
> "can_defer_constraint_checks" set to false inside DatabaseFeatures.

What version of Django are you developing against? This sounds very
much like #15118 [1], which is present in the 1.3 beta but was fixed
in trunk over a month ago by r15246 [2].

Carl

  [1] http://code.djangoproject.com/ticket/15118
  [2] http://code.djangoproject.com/changeset/15246

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple email connections

[Paul McMillan]

I agree that this makes a lot of sense for 1.4.

Probably the most common use case is going to be separating classes of
emails (mass-mails (mailchimp or constant contact), transactional
(amazon ses or your provider's mailserver), backend admin
notifications (server sendmail or local mail spool), etc). These are
going to be fairly easy to use by simply identifying them in the code,
and don't need automated routing.

If we were going to include some amount of automation, I would like to
see configurable failovers (though this might add too much complexity
to the settings). Additionally, the ability to distribute outgoing
mail to a given backend over several servers would be quite nice and
relatively trivial to implement. Weighted distribution over those
servers would be similarly trivial, but might be outside the
featureset Django wants to support. Actual quotas are clearly beyond
the scope.

-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: CSRF_Token and Ajax

[Russell Keith-Magee]

On Thu, Feb 24, 2011 at 8:44 AM, Paul  wrote:
> Dear all,
>
> allow me to quickly introduce myself, my name is Paul, I'm a PhD
> student from Germany and am playing around with django for mere joy
> (procrastination).
>
> I have a quick question on why ticket #15352 ( 
> http://code.djangoproject.com/ticket/15352
> ) was closed?
>
> It just took me a fair amount of time to figure out why my ajax post
> requests weren't working and for me the javascript-snippet posted
> here:
> http://www.djangoproject.com/weblog/2011/feb/08/security/
> doesn't work exactly because the id is missing on the csrf_token
> (ubuntu 10.10, firefox 3.6.4, jQuery 1.5). I guess an alternative
> would be to modify the javascript above so that the selector is
> $("[name=csrfmiddlewaretoken]")
> instead of
> $("#csrfmiddlewaretoken")
>
> Sorry if I have missed something, I couldn't find anything on this on
> the mailing list.

Luke gave you the reason when he closed the ticket. The reason it was
closed is because you *can't* have an ID on a CSRF token. HTML
requires that there is only one element with any given ID on a page.
However, CSRF tokens don't meet that requirement.

You can have multiple forms on a page, and each form needs to be
submitted with the CSRF token. That means there are multiple CSRF
token elements on the page, and as a result, you can't associate a
simple ID with them.

We *could* go to great lengths to provide some automated scheme for
allocating IDs when there are multiple CSRF tokens... or we could just
use the name of the token. We've chosen to do the latter.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

CSRF_Token and Ajax

[Paul]

Dear all,

allow me to quickly introduce myself, my name is Paul, I'm a PhD
student from Germany and am playing around with django for mere joy
(procrastination).

I have a quick question on why ticket #15352 ( 
http://code.djangoproject.com/ticket/15352
) was closed?

It just took me a fair amount of time to figure out why my ajax post
requests weren't working and for me the javascript-snippet posted
here:
http://www.djangoproject.com/weblog/2011/feb/08/security/
doesn't work exactly because the id is missing on the csrf_token
(ubuntu 10.10, firefox 3.6.4, jQuery 1.5). I guess an alternative
would be to modify the javascript above so that the selector is
$("[name=csrfmiddlewaretoken]")
instead of
$("#csrfmiddlewaretoken")

Sorry if I have missed something, I couldn't find anything on this on
the mailing list.

cheers
Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple email connections

[Russell Keith-Magee]

On Thu, Feb 24, 2011 at 1:44 AM, Luke Plant  wrote:
> On Tue, 2011-02-22 at 19:02 -0600, Niran Babalola wrote:
>> Multiple databases and caches can currently be configured in one's
>> settings file. It'd be nice if the same could be done with email
>> connections. For example, Amazon's SES starts out new users with a low
>> quota that they gradually increase, so splitting emails between SES
>> and other connections to start out with is a useful approach.
>>
>> Has any work been done on this? A quick Google turns up nothing. I've
>> written code that does most of this, but I wanted to make sure it has
>> general appeal before getting it in shape for a proper patch.
>
> Is it not possible to do this already, by writing your own backend that
> splits up e-mails as you see fit?
>
> If we add support for multiple backends, the only improvement I see is
> if we also add some method for deciding which backend to use - like the
> ConnectionRouter for databases. Is it possible to have something similar
> for e-mail, or will it end up being very specific to one set of needs?
> Before adding, I would like to know that the way of splitting up e-mails
> that is covered is a very common pattern that is needed by lots of
> people.

To be clear -- I'm not talking about adding an automated router to
discover the right email backend. I'm just talking about turning the
EMAIL_BACKEND string into an EMAIL_BACKENDS dictionary, so that users
can define multiple email backend settings and easily reference them
using a string alias.

This is analogous to what has been added for caches in 1.3; we've
added the ability to predefine multiple cache backends, but not a
magical scheme for discovering the right cache backend to use. This is
just a way to minimize duplication of settings -- you can provide one
place in your settings file where you define your 'customer' email
settings, rather than scattering them around the code, or having an
ad-hoc collection of custom settings.

The email API is already well positioned for these changes -- all the
API calls accept a 'connection' argument, so they can already handle
multiple backends. All that is missing is the ability to define
multiple email settings.

I completely agree that automated routing isn't a problem we should
tackle. I'm not convinced it's a common use case; and if people really
do want it, it's not that hard to add that layer on top of the API
that we've already provided.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A word about CSRF Protection and AJAX

[Jonas Obrist]

Well writing a middleware in my app or decorating all views seems a little 
hacky/unclean to me too. 

In our specific use case,  the django CMS the graceful degrading is done 
through the admin, our so called frontend editing is heavily javascript and 
AJAX base, without HTML forms. therefore we have a lot of problems now Django 
(correctly) checks for the CSRF header in AJAX request. to make this backwards 
incompatibility easier for developers to adopt, always sending the cookie would 
be the right thing to do, in my opinion.

Jonas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A word about CSRF Protection and AJAX

[Luke Plant]

On Wed, 2011-02-23 at 05:07 -0800, Jonas Obrist wrote:
> I beg to differ luke.
> 
> 
> Most of our AJAX POSTs we do are actually not a 'form'. Because we
> usually submit forms with 'normal' POST requests.

I was suggesting that normally you would encounter at least one normal
form before doing AJAX, in which the cookie would be set. And if you
apply the principles of graceful degradation, then you will have a
normal HTML form which includes the token, as well as having the AJAX
stuff. Obviously that depends on the app, and it is becoming less and
less true, with more and more apps that depend entirely on javascript.

> What would be so terrible in just setting the cookie always?

Hmm, good question. I guess just the fact of sending stuff that you may
not need seems like bad practice.

If we changed it to always send the cookie, we would need to ensure that
we only send the 'Vary: Cookie' header if the token was actually used in
the page.  Implementing this is actually a fairly trivial patch - just
re-ordering a few lines.

If there was objection to always sending the cookie, we might need a
setting to control that. But I'm loathe to do that and add further
complications to the docs.

Luke

-- 
As Ralph Waldo Emerson once said, "I hate quotations." 

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple email connections

[Niran Babalola]

On Wed, Feb 23, 2011 at 11:44 AM, Luke Plant  wrote:
> Is it not possible to do this already, by writing your own backend that
> splits up e-mails as you see fit?

Yes, but it'd be nice if the get_connection arguments for each
connection type could be easily referenced by name. Distributing
emails between connections for the SES case I described isn't
something I think needs to make it into Django.

> If we add support for multiple backends, the only improvement I see is
> if we also add some method for deciding which backend to use - like the
> ConnectionRouter for databases. Is it possible to have something similar
> for e-mail, or will it end up being very specific to one set of needs?

I think the ConnectionRouter style could be very useful for emails
depending on how people end up splitting emails, but I agree that
without more use cases, it's hard to see what the best generalized
implementation would look like.

> Before adding, I would like to know that the way of splitting up e-mails
> that is covered is a very common pattern that is needed by lots of
> people.

Here's what my email settings look like:
. Some things will change when I put
together a real patch to make things more consistent with DATABASES
and CACHES.

Being able to refer to email configurations by name made implementing
and configuring the DistributedBackend much simpler and clearer, and
didn't add much complexity to get_connection in order to do so.
Changing from the EMAIL_* settings to the DATABASES/CACHES style seems
like a win to me on its own.

- Niran

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple email connections

[Luke Plant]

On Tue, 2011-02-22 at 19:02 -0600, Niran Babalola wrote:
> Multiple databases and caches can currently be configured in one's
> settings file. It'd be nice if the same could be done with email
> connections. For example, Amazon's SES starts out new users with a low
> quota that they gradually increase, so splitting emails between SES
> and other connections to start out with is a useful approach.
> 
> Has any work been done on this? A quick Google turns up nothing. I've
> written code that does most of this, but I wanted to make sure it has
> general appeal before getting it in shape for a proper patch.

Is it not possible to do this already, by writing your own backend that
splits up e-mails as you see fit?

If we add support for multiple backends, the only improvement I see is
if we also add some method for deciding which backend to use - like the
ConnectionRouter for databases. Is it possible to have something similar
for e-mail, or will it end up being very specific to one set of needs?
Before adding, I would like to know that the way of splitting up e-mails
that is covered is a very common pattern that is needed by lots of
people.

Luke

-- 
As Ralph Waldo Emerson once said, "I hate quotations." 

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Suggestion: a new "nature" field in Trac

[mmcnickle]

On Feb 22, 11:22 am, Russell Keith-Magee 
wrote:

>  2) Directing people who are inclined to be altruistic to the right place.

For Firefox bugs, each patch can be flagged as follows:

Request a review from anyone: review=?
Request a review from someone specific: russellm: review?
Russel hates the patch: russellm: review-
Russel likes the patch: russellm: review+
Russel thinks Jannis is better place to review this: jezdez: review?

This obviously doesn't cure the "we need more people reviewing
patches" problem, but it does allow triagers to nudge the appropriate
people to review certain patches. A long list of "review these
patches" might be the motivation some people need.

It may be argued that this just adds to the administrivia of tickets,
but it is certainly effective for firefox. But that may be to the
large number of contributors willing to do patch reviews.

-- Martin


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple email connections

[Brendan Smith]

+1

On Tue, Feb 22, 2011 at 8:39 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Wed, Feb 23, 2011 at 9:02 AM, Niran Babalola  wrote:
> > Multiple databases and caches can currently be configured in one's
> > settings file. It'd be nice if the same could be done with email
> > connections. For example, Amazon's SES starts out new users with a low
> > quota that they gradually increase, so splitting emails between SES
> > and other connections to start out with is a useful approach.
> >
> > Has any work been done on this? A quick Google turns up nothing. I've
> > written code that does most of this, but I wanted to make sure it has
> > general appeal before getting it in shape for a proper patch.
>
> I'm not aware of any work that has been done in this area.
>
> As you have noticed, we've been moving away from singletons where
> possible; DATABASES in Django 1.2, CACHES in Django 1.3.
> EMAIL_BACKENDS would be a logical next step. Most of the email APIs
> are already configured to allow for multiple email servers; it's
> really just a matter of changing the way that email settings are
> parsed in get_connection().
>
> So -- if you want to polish this up for a 1.4 feature, it could be an
> easy 1.4 feature.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Brendan Smith, IT Specialist
National Priorities Project
http://www.nationalpriorities.org
http://www.costofwar.com
http://www.facebook.com/nationalpriorities
413 584 9556

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A word about CSRF Protection and AJAX

[Jonas Obrist]

I beg to differ luke.

Most of our AJAX POSTs we do are actually not a 'form'. Because we usually 
submit forms with 'normal' POST requests. 

What would be so terrible in just setting the cookie always?

Jonas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: database issue when using test_server MySQL Windows

[Chuck Harmston]

Hey Tim

Thanks for the report! I don't think this is a bug; you might want to read the 
documentation a little more closely.

http://docs.djangoproject.com/en/dev/ref/django-admin/#testserver-fixture-fixture

testserver runs the Django development server using data from the passed 
fixtures. This has two use cases, which are documented at the above link. I 
believe that you're looking for the functionality of manage.py's runserver 
command, which runs the development server with the database defined in the 
settings module.

http://docs.djangoproject.com/en/dev/ref/django-admin/#runserver-port-or-address-port

What you describe is the intended behavior and this thread is, needless to say, 
definitely in django-users territory at this point.

Chuck

On Wednesday, February 23, 2011 at 7:19 AM, Tim wrote: 
> Hi,
> 
> I'm new to Django and Python but I think I've found a bug with the
> testserver.
> 
> What happened is that Django wouldn't let me log in to my newly-
> created superuser account and kept saying "Please enter a correct
> username and password" despite the fact that I was 100% sure the
> information was correct. Also, I checked the data in the database I
> was using and the account was true for is_superuser, is_active and
> is_staff (in MySQL).
> 
> After a lot of messing around, I realized that Django testserver
> actually creates a separate "test_[databasename]" database with its
> own users - but when you create a superuser in shell, it only updates
> the real database (i.e. not in test_[databasename]).
> 
> Anyway - the only way I found around this was to manually copy the
> auth_user table after testserver is started from the actual database
> into the test_[databasename] database...
> 
> If anyone thinks I'm doing something wrong and this is not a bug,
> please let me know
> 
> Here's my setup:
> 
> Python 2.7
> Django 1.2.5
> MySQL for Python 1.2.3
> MySQL 5.1.41
> Windows 7 Pro
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Missing semi-colon

[Russell Keith-Magee]

On Wed, Feb 23, 2011 at 8:24 PM, Jonathan S  wrote:
> Aparently, there are several semicolons missing at several places:
>
> django/contrib/admin/templates/admin/edit_inline/tabular.html  lines
> 90, 94 and 124
> django/contrib/admin/templates/admin/edit_inline/stacked.html  lines
> 45, 48 and 78
>
> Of course, this really is a minor issue, but easy enough to fix.

Thanks for the report -- the best (and preferred) way to report this
is to open a ticket in Trac, ideally with a patch describing the
change you think needs to be made.

Yours,
Russ Magee %-)
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

database issue when using test_server MySQL Windows

[Tim]

Hi,

I'm new to Django and Python but I think I've found a bug with the
testserver.

What happened is that Django wouldn't let me log in to my newly-
created superuser account and kept saying "Please enter a correct
username and password" despite the fact that I was 100% sure the
information was correct. Also, I checked the data in the database I
was using and the account was true for is_superuser, is_active and
is_staff (in MySQL).

After a lot of messing around, I realized that Django testserver
actually creates a separate "test_[databasename]" database with its
own users - but when you create a superuser in shell, it only updates
the real database (i.e. not in test_[databasename]).

Anyway - the only way I found around this was to manually copy the
auth_user table after testserver is started from the actual database
into the test_[databasename] database...

If anyone thinks I'm doing something wrong and this is not a bug,
please let me know

Here's my setup:

Python 2.7
Django 1.2.5
MySQL for Python 1.2.3
MySQL 5.1.41
Windows 7 Pro

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Missing semi-colon

[Jonathan S]

Aparently, there are several semicolons missing at several places:

django/contrib/admin/templates/admin/edit_inline/tabular.html  lines
90, 94 and 124
django/contrib/admin/templates/admin/edit_inline/stacked.html  lines
45, 48 and 78

Of course, this really is a minor issue, but easy enough to fix.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Missing semi-colon

[Jonathan S]

Hi Django admin developers,

Can you please insert a semi-colon in the following file, behind line
90?

django/contrib/admin/templates/admin/edit_inline/tabular.html


var updateSelectFilter = function() {
// If any SelectFilter widgets are a part of the new form,
// instantiate a new SelectFilter instance for it.
if (typeof SelectFilter != "undefined"){
$(".selectfilter").each(function(index, value){
  var namearr = value.name.split('-');
  SelectFilter.init(value.id,
namearr[namearr.length-1], false, "{% admin_media_prefix %}");
})
--> please insert semi-colon here.
$(".selectfilterstacked").each(function(index, value){
  var namearr = value.name.split('-');
  SelectFilter.init(value.id,
namearr[namearr.length-1], true, "{% admin_media_prefix %}");
})
}
}

Thanks a lot,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.