Re: [Django] #19067: createsuperuser fails when custom user model has no username

[Django]

#19067: createsuperuser fails when custom user model has no username
---+-
 Reporter:  clelland   |Owner:  clelland
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by clelland):

 > The issue is that creating superusers with a 'username' has been around
 a while - so we can't change the signature of that method without breaking
 backwards compatibility.

 Agreed. That was the subtle point that I didn't pick up in the docs
 originally. (Actually, reading them again, it's left completely ambiguous
 in the docs what to do if your username field *isn't* called 'username'.
 The point is only made, extremely subtly, in
 `contrib/auth/tests/custom_user.py`, which uses `email` in `create_user`
 and `username` in `create_superuser`.

 This is backwards compatibility issue, and maybe we can't change the
 signature of the create_superuser method. In that case, though, the docs
 definitely need to be clearer about the exact method signature.

 > however, a point of confusion in your conclusion, is that just because
 the kwarg has to be username, doesn't mean that has to be the name of a
 field, or that a field named username has to be the one you use as a
 username, you'd just rewrite the above as:

 No, I stand by my point. If your user model has a required field called
 `username`, there is currently no way to write a manager for it unless
 that field is declared to be the USERNAME_FIELD. If it is in
 REQUIRED_FIELDS, then `createsuperuser.py` will try to call
 `create_superuser` with two keyword arguments called `username`.

 This breaks in at least two ways:

 `manage.py syncdb` will fail after querying for a new admin's credentials,
 terminating with

 {{{
 TypeError: create_superuser() got multiple values for keyword argument
 'username'
 }}}

 If you try to run `manage.py createsuperuser` directly, then it fails
 earlier: optparse will throw an error when it tries to create a second
 `--username` argument. The final error being

 {{{
 optparse.OptionConflictError: option --username: conflicting option
 string(s): --username
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15610: Generic Foreign Keys break when used with multi-db.

[Django]

#15610: Generic Foreign Keys break when used with multi-db.
--+
 Reporter:  legutierr |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by esimorre):

 see similar ticket #19068

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19068: comments in a multiple database context

[Django]

#19068: comments in a multiple database context
--+--
 Reporter:  esimorre  |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.comments  |  Version:
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by esimorre):

 not exactly because the target component is contrib.comment; but both
 should be analysed together.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19044: Allow get_success_url to access self. object in DeletionMixin

[Django]

#19044: Allow get_success_url to access self. object in DeletionMixin
--+
 Reporter:  anonymous |Owner:  nxvl
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Generic views |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by nxvl):

 * needs_docs:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19044: Allow get_success_url to access self. object in DeletionMixin

[Django]

#19044: Allow get_success_url to access self. object in DeletionMixin
--+
 Reporter:  anonymous |Owner:  nxvl
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Generic views |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by nxvl):

 * needs_tests:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19074: Small issues with custom user model documentation

[Django]

#19074: Small issues with custom user model documentation
-+-
 Reporter:  Bradley Ayers|Owner:  nobody
     |   Status:  new
 Type:   |  Version:  1.4
  Cleanup/optimization   |   Resolution:
Component:  Documentation| Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by russellm):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * type:  Uncategorized => Cleanup/optimization
 * needs_tests:   => 0
 * needs_docs:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19074: Small issues with custom user model documentation

[Django]

#19074: Small issues with custom user model documentation
+
 Reporter:  Bradley Ayers   |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Documentation   |Version:  1.4
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 In the example: (https://docs.djangoproject.com/en/dev/topics/auth/#a
 -full-example)

 - `MyUserManager.create_user` uses a `user` variable but
 `create_superuser` uses a `u` variable
 - Some inconsistent indentation

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19044: Allow get_success_url to access self. object in DeletionMixin

[Django]

#19044: Allow get_success_url to access self. object in DeletionMixin
--+
 Reporter:  anonymous |Owner:  nxvl
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Generic views |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by nxvl):

 * owner:  nobody => nxvl
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19071: Static files description

[Django]

#19071: Static files description
---+--
 Reporter:  kris@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by ptone):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => needsinfo
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Specific improvements to the documentation are always welcome.

 There are currently two sections in the docs that address this in addition
 to the intro that summarizes the two steps under usage at the beginning.
 These cover everything that the FAQ item does.

 * https://docs.djangoproject.com/en/dev/howto/static-files/#serving-
 static-files-in-development
 * https://docs.djangoproject.com/en/dev/howto/static-files/#serving-
 static-files-in-production

 In addition there is a big warning box about how the dev server for static
 files will only work if DEBUG = True

 What elements of the FAQ text do you think would improve the current docs?
 If you can provide specific suggestions, or identify a specific
 shortcoming - please reopen with those details.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16211: using negated F()-expression in update query

[Django]

#16211: using negated F()-expression in update query
-+-
 Reporter:  wdoekes  |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by twoolie):

 So if we want &/| to work in the same way for Q and F objects then this
 should be the goal?

 {{{
 SQL  | ORM
 -+
 field1 &  field2 | F('field1').bitand(F('field2'))
 field1 && field2 | F('field1') & F('field2')
 field1 |  field2 | F('field1').bitor(F('field2'))
 field1 || field2 | F('field1') | F('field2')
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19067: createsuperuser fails when custom user model has no username

[Django]

#19067: createsuperuser fails when custom user model has no username
---+-
 Reporter:  clelland   |Owner:  clelland
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by ptone):

 OK - I can see the confusion.

 The issue is that creating superusers with a 'username' has been around a
 while - so we can't change the signature of that method without breaking
 backwards compatibility.

 however, a point of confusion in your conclusion, is that just because the
 kwarg has to be username, doesn't mean that has to be the name of a field,
 or that a field named username has to be the one you use as a username,
 you'd just rewrite the above as:

  {{{
  class SocialUserManager(BaseUserManager):


  def create_superuser(self, username, password, **kwargs):
  user = self.model(email=username, is_staff=True,
 is_superuser=True,
  **kwargs)
  user.set_password(password)
  user.save()
  return user
  }}}

 I generally prefer the explicitness of passing named kwargs rather than
 positional - as there is less chance for mistakes (assuming the first
 position is one thing when it is something else).

 I do agree this particular detail of legacy needs to be highlighted in the
 docs - and I'm considering a major refactor of the auth docs currently.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19068: comments in a multiple database context

[Django]

#19068: comments in a multiple database context
--+--
 Reporter:  esimorre  |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.comments  |  Version:
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by ptone):

 Is this not really a duplicate of #15610?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16039: syncdb with --database option fails

[Django]

#16039: syncdb with --database option fails
-+-
 Reporter:  yedpodtrzitko|Owner:
 Type:  Bug  |  mhaligowski
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mhaligowski):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


Comment:

 Patch provided here
 [https://github.com/mhaligowski/django/compare/ticket_16039], along with
 the test.

 I'll be grateful for a review, as I am unsure about the solution. It fixes
 the bug, but I believe there may be a better way to do that.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19073: strange behaviuor of select_related

[Django]

#19073: strange behaviuor of select_related
--+
 Reporter:  anonymous |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Sometimes Django uses inner join instead of left outer join in queries
 with select_related. This breaks queries with nullable OneToOne fields.
 Here's the example

 models:
 {{{
 class A(models.Model):
 pass

 class B(models.Model):
 pass

 class C(models.Model):
 b = models.OneToOneField(B)
 a = models.ForeignKey(A)

 class D(models.Model):
 b = models.OneToOneField(B, null=True)
 }}}

 code
 {{{
 D.objects.all()
 [, , ] #ok
 >>> D.objects.select_related('b').all()
 [, , ] #ok
 >>> D.objects.select_related('b', 'b__c').all()
 [, , ] #ok
 >>> D.objects.select_related('b', 'b__c__a').all()
 [] #WRONG! empty result
 >>> print D.objects.select_related('b', 'b__c__a').all().query
 SELECT "app1_d"."id", "app1_d"."b_id", "app1_b"."id", "app1_c"."id",
 "app1_c"."b_id", "app1_c"."a_id", "app1_a"."id" FROM "app1_d" LEFT OUTER
 JOIN "app1_b" ON ("app1_d"."b_id" = "app1_b"."id") LEFT OUTER JOIN
 "app1_c" ON ("app1_b"."id" = "app1_c"."b_id") INNER JOIN "app1_a" ON
 ("app1_c"."a_id" = "app1_a"."id")

 }}}

 '''INNER JOIN "app1_a"''' should be '''LEFT OUTER JOIN "app1_a"''' imo

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13870: Document transaction/connection management outside the web server context (was: psycopg2 backend never terminates isolating transactions)

[Django]

#13870: Document transaction/connection management outside the web server 
context
---+
 Reporter:  patrys |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timo):

 * cc: timograham@… (added)
 * needs_better_patch:  1 => 0
 * version:  1.2 => master
 * type:  Bug => New feature


Comment:

 Added a doc patch based on Gabriel's stackoverflow post.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18437: Incorrect double JOIN when using multiple .filter() calls on the same table

[Django]

#18437: Incorrect double JOIN when using multiple .filter() calls on the same 
table
-+-
 Reporter:  vdboor   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 I just ran into this issue. If you are doing filtering and later add some
 annotations like Count, Sum, etc. this is a unpleasant surprise and giving
 you wrong results.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19072: GeoDjango/GeoIP docs have outdated info

[Django]

#19072: GeoDjango/GeoIP docs have outdated info
---+--
 Reporter:  fcurella   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by fcurella):

 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19072: GeoDjango/GeoIP docs have outdated info

[Django]

#19072: GeoDjango/GeoIP docs have outdated info
---+
 Reporter:  fcurella   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 The doc about GeoIP states:

 > [...]  These datasets may be
 > downloaded from MaxMind.  Grab the `GeoIP.dat.gz` and
 `GeoLiteCity.dat.gz`
 > and unzip them in a directory [...]

 On the GeoMind server there isn't any file called `GeoIP.dat.gz`. The file
 is now called `GeoIPv6.dat.gz`

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17959: Silence output during GIS tests

[Django]

#17959: Silence output during GIS tests
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  test logging  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Claude Paroz ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"53c8b2c0c52cf999b644184bfe51e9f59d89286e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="53c8b2c0c52cf999b644184bfe51e9f59d89286e"
 Fixed #17959 -- Silenced output during GIS tests
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 53c8b2: Fixed #17959 -- Silenced output during GIS tests

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 53c8b2c0c52cf999b644184bfe51e9f59d89286e
  
https://github.com/django/django/commit/53c8b2c0c52cf999b644184bfe51e9f59d89286e
  Author: Claude Paroz 
  Date:   2012-10-04 (Thu, 04 Oct 2012)

  Changed paths:
M django/contrib/gis/gdal/libgdal.py
M django/contrib/gis/gdal/tests/test_ds.py
M django/contrib/gis/gdal/tests/test_geom.py
M django/contrib/gis/geos/libgeos.py
M django/contrib/gis/geos/tests/test_geos.py

  Log Message:
  ---
  Fixed #17959 -- Silenced output during GIS tests



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 0ad6d7: Removed unused and undocumented gdal_release_date ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 0ad6d7e61294befd5868c5ab422669d9ef3db52f
  
https://github.com/django/django/commit/0ad6d7e61294befd5868c5ab422669d9ef3db52f
  Author: Claude Paroz 
  Date:   2012-10-04 (Thu, 04 Oct 2012)

  Changed paths:
M django/contrib/gis/gdal/__init__.py
M django/contrib/gis/gdal/libgdal.py

  Log Message:
  ---
  Removed unused and undocumented gdal_release_date function



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15894: SITE_CACHE does not invalidate in multiprocess environments

[Django]

#15894: SITE_CACHE does not invalidate in multiprocess environments
+
 Reporter:  Kronuz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.sites   |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  cache invalidation  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by anonymous):

 The test by @krzysiumed
 (https://code.djangoproject.com/ticket/15894#comment:9) fails for me when
 using sqlite3, but passes with postgresql_psycopg2.

 While using sqlite, I can verify that `current_site = self.get(pk=sid)` in
 `SiteManager` returns the unchanged site when called from the first
 process (`check_if_domain_changed`). Thus, the `Site.save()` method
 properly deletes the cache entry, but the query to re-populate the cache
 returns an old object.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19071: Static files description

[Django]

#19071: Static files description
---+
 Reporter:  kris@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 So,I know I should smarter. Given.

 But I would really/heartily/fully recommend that the django doc
 maintainers put something like this: (from the Mezzanine FAQ) in addition
 to the intro paragraphs of https://docs.djangoproject.com/en/dev/howto
 /static-files/

 I find this very succinctly explains the difference between dev and
 production WRT static files.

 "Why aren’t my JavaScript and CSS files showing up?

 Mezzanine makes exclusive use of Django’s staticfiles app, for managing
 static files such as JavaScript, CSS, and images.

 When the DEBUG setting is set to True, as it would be during development,
 the URL defined by the setting STATIC_URL (usually /static/), will host
 any files found in the static directory of any application listed in the
 INSTALLED_APPS setting.

 When DEBUG is set to False, as it would be for your deployed production
 site, you must run the collectstatic command on your live site, which will
 copy all of the files from the static directory in each application, to
 the location defined by the STATIC_ROOT setting. You then need to
 configure an alias in your web server’s config (Apache, NGINX, etc) that
 maps the URL defined by STATIC_URL to serve files from this directory.

 Long story short, Django doesn’t serve static content when deployed in
 production, leaving this up to the public facing web server, which is
 absolutely the best tool for this job. Consult Django’s staticfiles guide
 for more information."

 pretty please with sugar on top? :-) (love the framework, really I do, use
 everyday allday just now (and for the last 11 months))

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19068: comments in a multiple database context

[Django]

#19068: comments in a multiple database context
--+--
 Reporter:  esimorre  |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.comments  |  Version:
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by esimorre):

 It is obvious that the line code below raise a "table xxx not found"
 exception if ContentType and the target model are stored in 2 distincts db
 {{{
 class ContentType:
 ...
 return
 self.model_class()._base_manager.using(self._state.db).get(**kwargs)
 }}}

 Same thing below if the Comment model and the target model are stored in 2
 distincts db
 {{{
 class CommentDetailsForm:
 ...
 possible_duplicates =
 self.get_comment_model()._default_manager.using(
 self.target_object._state.db
 )
 }}}

 By using the default manager "objects", the bug is fixed. I confirm that
 it works.

 It's very interesting, you can comment objects stored in a legacy database
 without storing extra data inside.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19068: comments in a multiple database context

[Django]

#19068: comments in a multiple database context
--+--
 Reporter:  esimorre  |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.comments  |  Version:
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by esimorre):

 * status:  closed => reopened
 * resolution:  needsinfo =>


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18978: Move cleanup management command to contrib.sessions

[Django]

#18978: Move cleanup management command to contrib.sessions
-+-
 Reporter:  rasca|Owner:  rasca
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-

Comment (by ptone):

 So I'm going to retract the whole idea of a "special" pattern for cleanup
 - as pointed by Aymeric in IRC and myself in comment 1 - there hasn't
 proven to be a big need for a generic cleanup routine, and implementing
 this pattern would be a case of YAGNI design.

 New tests are still needed - preferably inside contrib.sessions, not in
 admin_scripts where I would have expected the old ones to be, but I agree
 - this doesn't seem to be currently tested.

 There is also a tiny cleanup needed in bin/daily-cleanup.py

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19067: createsuperuser fails when custom user model has no username

[Django]

#19067: createsuperuser fails when custom user model has no username
---+-
 Reporter:  clelland   |Owner:  clelland
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by clelland):

 Here's what I actually did --

 I created a user model like this:

 {{{
 class SocialUser(AbstractBaseUser):
 # Use a sufficiently long email field
 email = models.EmailField(verbose_name='email address',
 max_length=254, unique=True)

 twitter_screenname = models.CharField(max_length=20, null=True,
 blank=True)
 facebook_user_id = models.BigIntegerField(null=True, blank=True)
 google_plus_userid = models.CharField(max_length=50, null=True,
 blank=True)

 is_staff = models.BooleanField(default=False)
 is_active = models.BooleanField(default=True)
 is_superuser = models.BooleanField(default=False)

 USERNAME_FIELD = 'email'
 REQUIRED_FIELDS = []

 objects = SocialUserManager()
 }}}

 and then, by mistake apparently, wrote the manager like this:

 {{{
 class SocialUserManager(BaseUserManager):

 def create_user(self, email, password=None, **kwargs):
 user = self.model(email=email, **kwargs)
 user.set_password(password)
 user.save()
 return user

 def create_superuser(self, email, password, **kwargs):
 user = self.model(email=email, is_staff=True, is_superuser=True,
 **kwargs)
 user.set_password(password)
 user.save()
 return user
 }}}

 (note that the first parameter on the manager methods is 'email', and not
 'username', as it is in the docs)

 At that point I ran syncdb on a brand new database.
 The createsuperuser management command correctly identifies the
 USERNAME_FIELD, and uses the name of that field to prompt for the new
 superuser's email address. However, then it calls
 SocialUserManager.create_superuser with all named parameters, including
 "username=". That failed, of course, since the method I
 wrote required an 'email' parameter instead.

 As I said in comment:1, absolutely feel free to close this as invalid;
 what I wrote was not what was in the instructions.

 My point afterwards, though, was that my patch fixes this, and makes the
 only requirement on create_user and create_superuser that the
 USERNAME_FIELD be the first positional parameter, and the password the
 second positional parameter.

 Right now, from my reading of the code (I haven't tested this or run into
 it in a real situation,) it looks like we have an undocumented restriction
 on user model fields:

 If your custom model has a field called 'username', that field MUST be
 the USERNAME_FIELD, or the manager methods will not work.

 I'll write up a test case for that and reopen the ticket for discussion on
 that point.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19061: Clarify the contract regarding is_active on custom users

[Django]

#19061: Clarify the contract regarding is_active on custom users
--+
 Reporter:  russellm  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by ptone):

 One potential issue with the property approach is that it a non-field
 implementation will prevent the use of is_active in querysets - this won't
 break current User.objects.filter(is_active=True) usage on existing
 auth.User objects, but will limit an optimized approach that use user
 object neutral.

 Part of the issue in making this call is the very messy history is_active
 has had in the way people have struggled with a clear definition of what
 it means:

 see #13125 and doc patches reference there.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18987: Django contrib admin redirection error on actions

[Django]

#18987: Django contrib admin redirection error on actions
-+-
 Reporter:  audirs2 [at] |Owner:  nobody
  gmail.com  |   Status:  new
 Type:  Uncategorized|  Version:  1.4
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  redirect |  Unreviewed
  remote_auth_backend nginx  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by audirs2 [at] gmail.com):

 Upon further investigation it appears to be caused by the HTTP module
 django/http/__init__.py in build_absolute_uri

 Where the location full path is returned incorrectly by urlparse in the
 form .domain.com/admin/appname/add/  and self.path is used by
 get_full_path both have the same issue.

 Suggest changing the behaviour of build abosolute url to check for this
 behaviour as their should always be a leading slash on the url so could
 check if that is the case and split the url if required.  e.g.

 {{{
self.path.split('/',1)[1]
 }}}

 to obtain the actual path?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16479: Forms generated from formsets use ErrorList instead of supplied error_class

[Django]

#16479: Forms generated from formsets use ErrorList instead of supplied 
error_class
-+-
 Reporter:  marcin.tustin@…  |Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  forms formsets   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by vicould):

 * stage:  Accepted => Ready for checkin


Comment:

 Looks ready for checkin, pull request at
 [https://github.com/django/django/pull/423]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17365: Extend test discovery to include unittest2 test suite runner

[Django]

#17365: Extend test discovery to include unittest2 test suite runner
-+-
 Reporter:  jezdez   |Owner:  myusuf3
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by claudep):

 Looks good, but currently if I run `python manage.py test
 django.contrib.messages` in my project, no tests are run (currently, the
 files containing the tests do not match the test*.py pattern). Is this
 something that we intend to fix soon after this commit, by renaming
 affected contrib test files?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19070: urlize template filter raises exception in some cases

[Django]

#19070: urlize template filter raises exception in some cases
-+
 Reporter:  rivolaks@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Template system
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Attached a patch which fixes the specific square bracket issue (note that
 the issue is only accurate from Python 2.7).

 The question remains whether we should swallow exceptions around
 smart_urlquote. Aymeric?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18996: better document overridden model save not called on bulk update.

[Django]

#18996: better document overridden model save not called on bulk update.
-+-
 Reporter:  bram.dejong@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  docs overriding  |  Needs documentation:  1
  save bulk update   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by Elvard):

 Thanks, it's there https://github.com/django/django/pull/422

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18996: better document overridden model save not called on bulk update.

[Django]

#18996: better document overridden model save not called on bulk update.
-+-
 Reporter:  bram.dejong@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  docs overriding  |  Needs documentation:  1
  save bulk update   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by timo):

 * needs_better_patch:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19051: Error in testing/live-test-server example

[Django]

#19051: Error in testing/live-test-server example
---+
 Reporter:  glarrain   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"a35d7fd1e1c8e2a1e95b6d16949f9fb3977f15cb"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a35d7fd1e1c8e2a1e95b6d16949f9fb3977f15cb"
 [1.4.X] Fixed #19051 - Fixed Selenium tearDownClass method; thanks
 glarrain for the report.

 Backport of a1a5c0854f from master
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] a35d7f: [1.4.X] Fixed #19051 - Fixed Selenium tearDownClas...

[GitHub]

  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: a35d7fd1e1c8e2a1e95b6d16949f9fb3977f15cb
  
https://github.com/django/django/commit/a35d7fd1e1c8e2a1e95b6d16949f9fb3977f15cb
  Author: Tim Graham 
  Date:   2012-10-04 (Thu, 04 Oct 2012)

  Changed paths:
M django/contrib/admin/tests.py
M docs/topics/testing.txt

  Log Message:
  ---
  [1.4.X] Fixed #19051 - Fixed Selenium tearDownClass method; thanks glarrain 
for the report.

Backport of a1a5c0854f from master



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19051: Error in testing/live-test-server example

[Django]

#19051: Error in testing/live-test-server example
---+
 Reporter:  glarrain   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"a1a5c0854f0b0d3c94a772c8b994ee2d1d2f9be1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a1a5c0854f0b0d3c94a772c8b994ee2d1d2f9be1"
 Fixed #19051 - Fixed Selenium tearDownClass method; thanks glarrain for
 the report.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] a1a5c0: Fixed #19051 - Fixed Selenium tearDownClass method...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: a1a5c0854f0b0d3c94a772c8b994ee2d1d2f9be1
  
https://github.com/django/django/commit/a1a5c0854f0b0d3c94a772c8b994ee2d1d2f9be1
  Author: Tim Graham 
  Date:   2012-10-04 (Thu, 04 Oct 2012)

  Changed paths:
M django/contrib/admin/tests.py
M docs/topics/testing.txt

  Log Message:
  ---
  Fixed #19051 - Fixed Selenium tearDownClass method; thanks glarrain for the 
report.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17365: Extend test discovery to include unittest2 test suite runner

[Django]

#17365: Extend test discovery to include unittest2 test suite runner
-+-
 Reporter:  jezdez   |Owner:  myusuf3
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jezdez):

 * stage:  Accepted => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18987: Django contrib admin redirection error on actions

[Django]

#18987: Django contrib admin redirection error on actions
-+-
 Reporter:  audirs2 [at] |Owner:  nobody
  gmail.com  |   Status:  new
 Type:  Uncategorized|  Version:  1.4
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  redirect |  Unreviewed
  remote_auth_backend nginx  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by audirs2 [at] gmail.com):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Appears to be caused by TemplateResponse handling

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19070: urlize template filter raises exception in some cases

[Django]

#19070: urlize template filter raises exception in some cases
---+
 Reporter:  rivolaks@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In some cases, urlize template filter fails because it's trying to parse
 ipv6 url and exception is raised:

 {{{
 >>> from django.utils.html import urlize
 >>> urlize('www.ee]')
 Traceback (most recent call last):
   File "", line 1, in 
   File "django/utils/functional.py", line 193, in wrapper
 return func(*args, **kwargs)
   File "django/utils/html.py", line 213, in urlize
 url = smart_urlquote('http://%s' % middle)
   File "django/utils/html.py", line 152, in smart_urlquote
 scheme, netloc, path, query, fragment = urlsplit(url)
   File "/usr/lib/python2.7/urlparse.py", line 183, in urlsplit
 raise ValueError("Invalid IPv6 URL")
 ValueError: Invalid IPv6 URL
 }}}

 'www.google.com]' also breaks, but 'google.com]' doesn't.

 IMHO urlize filter should never raise exceptions. In my case it is used on
 plaintext user input which we have no control over, and I'm assuming that
 errors in Django's template rendering are always handled internally and
 silently. In this case I'd expect urlize() to catch the ValueError from
 urlsplit and handle it somehow, e.g. by skipping the url.

 Happens in both 1.4 as well as master, 1.3 is not affected.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17207: create_template_postgis-debian.sh cant use UTF8 on PostgreSQL 8.4

[Django]

#17207: create_template_postgis-debian.sh cant use UTF8 on PostgreSQL 8.4
-+
 Reporter:  artur@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  postgis  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Claude Paroz ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"725128289398ba4bce60a4093d9d69bbcea01d92"]:
 {{{
 #!CommitTicketReference repository=""
 revision="725128289398ba4bce60a4093d9d69bbcea01d92"
 Fixed #17207 -- Added a troubleshooting note about failing createdb
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 89544b: Readded docs anchor removed in 92b5341b and still ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 89544b2bd2323cdc5c29e056838a23abcee07d6e
  
https://github.com/django/django/commit/89544b2bd2323cdc5c29e056838a23abcee07d6e
  Author: Claude Paroz 
  Date:   2012-10-04 (Thu, 04 Oct 2012)

  Changed paths:
M docs/ref/contrib/gis/install.txt

  Log Message:
  ---
  Readded docs anchor removed in 92b5341b and still in use


  Commit: 725128289398ba4bce60a4093d9d69bbcea01d92
  
https://github.com/django/django/commit/725128289398ba4bce60a4093d9d69bbcea01d92
  Author: John Paulett 
  Date:   2012-10-04 (Thu, 04 Oct 2012)

  Changed paths:
M docs/ref/contrib/gis/install.txt

  Log Message:
  ---
  Fixed #17207 -- Added a troubleshooting note about failing createdb


Compare: https://github.com/django/django/compare/234ca6c61d27...725128289398

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19051: Error in testing/live-test-server example

[Django]

#19051: Error in testing/live-test-server example
---+
 Reporter:  glarrain   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * has_patch:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 On my system, ordering of those lines can be swapped without failures, so
 it may be system dependent (tested with selenium 2.20 and 2.25). But it
 makes sense to quit selenium before trying to kill the thread, so +1 for
 the change (both in docs and in !AdminSeleniumWebDriverTestCase).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18978: Move cleanup management command to contrib.sessions

[Django]

#18978: Move cleanup management command to contrib.sessions
-+-
 Reporter:  rasca|Owner:  rasca
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-

Comment (by Elvard):

 The pull is there: https://github.com/django/django/pull/420

 And yes, I assume that future implementation of cleanup would require more
 discussion. I'll leave it for now.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.