[Django] #18522: Incosistencies and redundant checks in wizard view

[Django]

#18522: Incosistencies and redundant checks in wizard view
--+
 Reporter:  fahad@…   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.formtools |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Redundant check in the post method:

 file:
 django/contrib/formtools/wizard/views.py

 line 255:
 if wizard_goto_step and wizard_goto_step in self.get_form_list():

-- 
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] #18521: Add appropriate reST role to templates named in view docs

[Django]

#18521: Add appropriate reST role to templates named in view docs
-+-
 Reporter:  benspaulding |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.admindocs|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  admindocs|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by benspaulding):

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


Comment:

 I have made the fix on a branch and made a
 [https://github.com/django/django/pull/176 GitHub pull request].

-- 
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] #18521: Add appropriate reST role to templates named in view docs

[Django]

#18521: Add appropriate reST role to templates named in view docs
--+---
 Reporter:  benspaulding  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.admindocs |Version:  master
 Severity:  Normal|   Keywords:  admindocs
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+---
 Django ships with views that document the template used, but which do not
 correctly use the `:template:` reST role. This means that the admindocs
 build broken links for these templates.

-- 
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] #18520: forms.ImageField loads entire file into memory, crashes server

[Django]

#18520: forms.ImageField loads entire file into memory, crashes server
-+
 Reporter:  gregplaysguitar  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Forms|Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 The built-in ImageField (django.forms.ImageField) performs a couple of
 checks on uploaded images to make sure they're not corrupt. The downside
 of this is that the whole file gets loaded into memory, and if the file is
 large enough this can have dire consequences. Also, the file gets loaded
 into memory as a bitmap, so a JPEG or PNG that might only be a few MB on
 disk but very large in terms of pixels can potentially bring down a
 server.

 I'd consider this a bug, because django already intelligently decides
 whether to use an on-disk or in-memory temporary file for the image
 upload, but this is pointless when the file is getting loaded into memory
 anyway.

 To solve this problem, I've created an ImageField that checks the
 dimensions of the uploaded file before trying to load it into memory.
 Users will see a standard error message if they try to upload a file
 that's too large. Code is here: https://gist.github.com/3000513 (it also
 checks filesize; to be clear that's not what this ticket is about)

 I'm not sure exactly what the best solution for django is - adding the
 check to forms.ImageField is trivial, but determining the maximum size
 will require some thought. Perhaps it just becomes a setting, with a very
 large default of say 5000x5000?

-- 
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] #18465: Date and Timestamp formats for Oracle Backend incorrect with Oracle RAC 11g R2

[Django]

#18465: Date and Timestamp formats for Oracle Backend incorrect with Oracle RAC 
11g
R2
-+-
 Reporter:  josh.smeaton@…   |Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle backend NLS   |  Needs documentation:  0
  Date Format|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Josh Smeaton ):

 I think that's the right choice. If other users become affected later, at
 least the patch/information is here for them to help diagnose and re-raise
 the possibility of a backport. Thanks for getting this in so quickly
 Akaariai.

-- 
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] #15197: yaml serialization to HttpResponse fails

[Django]

#15197: yaml serialization to HttpResponse fails
--+
 Reporter:  fourga38  |Owner:  hirokiky
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:  yaml  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by hirokiky):

 Thank you. It's nice to be able to get the value with same method from
 both StringIO and HttpResponse. We may use them with same name 'stream'.
 However, I fell, adding a new method to HttpResponse is far from this
 ticket. This problem should be solved in new ticket (e.g. Adding getvalue
 to HttpResponse).

-- 
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] #15197: yaml serialization to HttpResponse fails

[Django]

#15197: yaml serialization to HttpResponse fails
--+
 Reporter:  fourga38  |Owner:  hirokiky
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:  yaml  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 Thanks for your work. Here is an alternative approach. However, adding a
 new method to !HttpResponse is not to be taken lightly, therefore I'd like
 to have another core dev approval for this.

-- 
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] #18515: Problematic validation code in FileField

[Django]

#18515: Problematic validation code in FileField
-+-
 Reporter:  yoyoma   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.4
  uploads/storage|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  max_length,  |  Needs documentation:  0
  FileField, fields  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by yoyoma):

 Holy mackerel! Fixed in 15 hours and committed? Thanks, Claude!

-- 
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] #18519: DateField ignores DATE_INPUT_FORMATS (because get_format ignores it)

[Django]

#18519: DateField ignores DATE_INPUT_FORMATS (because get_format ignores it)
-+-
 Reporter:   |  Owner:  nobody
  marcin.tustin@…| Status:  new
 Type:  Bug  |Version:  1.4
Component:  Forms|   Keywords:  DateField, django.utils.formats
 Severity:  Normal   |  Has patch:  0
 Triage Stage:  Unreviewed   |  UI/UX:  0
Easy pickings:  1|
-+-
 DateFields in forms do not have their behaviour altered by the setting
 DATE_INPUT_FORMATS.

 This happens because django.utils.get_format ignores it.

 Here is a transcript of a debug session demonstrating that:


 {{{
 In [14]: df.to_python('13-03-1978')
 ---
 ValidationError   Traceback (most recent call
 last)
 /home/marcintustin/webapps/django/oneclickcosvirt/lib/python2.7/site-
 packages/django/core/management/commands/shell.pyc in ()
 > 1 df.to_python('13-03-1978')

 /home/marcintustin/webapps/django/oneclickcosvirt/lib/python2.7/site-
 packages/django/forms/fields.pyc in to_python(self, value)
 377 if isinstance(value, datetime.date):
 378 return value
 --> 379 return super(DateField, self).to_python(value)
 380
 381 def strptime(self, value, format):

 /home/marcintustin/webapps/django/oneclickcosvirt/lib/python2.7/site-
 packages/django/forms/fields.pyc in to_python(self, value)
 354 except ValueError:
 355 continue
 --> 356 raise ValidationError(self.error_messages['invalid'])
 357
 358 def strptime(self, value, format):

 ValidationError: [u'Enter a valid date.']

 In [15]: import pdb; pdb.pm()
 > /home/marcintustin/webapps/django/oneclickcosvirt/lib/python2.7/site-
 packages/django/forms/fields.py(356)to_python()
 -> raise ValidationError(self.error_messages['invalid'])
 (Pdb) l
 351 usecs = int(usecs_str[:6].ljust(6,
 '0'))
 352 dt =
 datetime.datetime.strptime(datetime_str, format[:-3])
 353 return dt.replace(microsecond=usecs)
 354 except ValueError:
 355 continue
 356  -> raise ValidationError(self.error_messages['invalid'])
 357
 358 def strptime(self, value, format):
 359 raise NotImplementedError('Subclasses must define this
 method.')
 360
 361 class DateField(BaseTemporalField):
 (Pdb) format
 '%m/%d/%y'
 (Pdb) self.input_formats
 
 (Pdb) list(self.input_formats)
 *** Error in argument: '(self.input_formats)'
 (Pdb) self.input_formats
 
 (Pdb) tuple(self.input_formats)
 ('%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y')
 (Pdb) self
 
 (Pdb) formats
 
 (Pdb) formats.get_format_lazy('DATE_INPUT_FORMATS')
 
 (Pdb) tuple(formats.get_format_lazy('DATE_INPUT_FORMATS'))
 ('%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y')
 (Pdb) from django.conf import settings
 (Pdb) settings.DATE_INPUT_FORMATS
 ('%d-%m-%y', '%d-%b-%Y', '%d-%B-%y', '%d-%m-%Y', '%d-%b-%y', '%d-%B-%Y',
 '%d/%m/%y', '%d/%b/%Y', '%d/%B/%y', '%d/%m/%Y', '%d/%b/%y', '%d/%B/%Y',
 '%d %m %y', '%d %b %Y', '%d %B %y', '%d %m %Y', '%d %b %y', '%d %B %Y',
 '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', '%b %d %Y', '%b %d, %Y', '%d %b %Y',
 '%d %b, %Y', '%B %d %Y', '%B %d, %Y', '%d %B %Y', '%d %B, %Y', '%x')
 (Pdb) getattr(settings, 'DATE_INPUT_FORMATS')
 ('%d-%m-%y', '%d-%b-%Y', '%d-%B-%y', '%d-%m-%Y', '%d-%b-%y', '%d-%B-%Y',
 '%d/%m/%y', '%d/%b/%Y', '%d/%B/%y', '%d/%m/%Y', '%d/%b/%y', '%d/%B/%Y',
 '%d %m %y', '%d %b %Y', '%d %B %y', '%d %m %Y', '%d %b %y', '%d %B %Y',
 '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', '%b %d %Y', '%b %d, %Y', '%d %b %Y',
 '%d %b, %Y', '%B %d %Y', '%B %d, %Y', '%d %B %Y', '%d %B, %Y', '%x')
 (Pdb) formats.get_format('DATE_INPUT_FORMATS')
 ('%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y')
 (Pdb)
 }}}

-- 
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] #18465: Date and Timestamp formats for Oracle Backend incorrect with Oracle RAC 11g R2

[Django]

#18465: Date and Timestamp formats for Oracle Backend incorrect with Oracle RAC 
11g
R2
-+-
 Reporter:  josh.smeaton@…   |Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle backend NLS   |  Needs documentation:  0
  Date Format|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 I will wait with the backporting, I couldn't reproduce the error on Oracle
 XE 11g here on my machine. I applied the patch as there doesn't seem to be
 any documentation what is supposed to happen when NLS_TERRITORY is set
 together with something it is supposed to override, and there is at least
 one report of this on Oracle 11g RAC. The cost is one more query on
 connection setup.

 If it turns out there are more users possibly hit by this, and that this
 doesn't cause any problems for current users, then I will backport. (Sorry
 if this is overcautious, I am still not comfortable deciding what should
 be backported, what not).

-- 
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] #18465: Date and Timestamp formats for Oracle Backend incorrect with Oracle RAC 11g R2

[Django]

#18465: Date and Timestamp formats for Oracle Backend incorrect with Oracle RAC 
11g
R2
-+-
 Reporter:  josh.smeaton@…   |Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle backend NLS   |  Needs documentation:  0
  Date Format|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [fa182e8ae82f33764d5e1f70bcd45899e1bf17e6]:
 {{{
 #!CommitTicketReference repository=""
 revision="fa182e8ae82f33764d5e1f70bcd45899e1bf17e6"
 Fixed #18465 -- Set date formats correctly on Oracle

 Correctly configure NLS_SESSION_PARAMETERS to format Date and DateTime
 on Oracle backend.

 Thanks to Josh Smeaton for report & patch.
 }}}

-- 
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] fa182e: Fixed #18465 -- Set date formats correctly on Orac...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fa182e8ae82f33764d5e1f70bcd45899e1bf17e6
  
https://github.com/django/django/commit/fa182e8ae82f33764d5e1f70bcd45899e1bf17e6
  Author: Josh Smeaton 
  Date:   2012-06-26 (Tue, 26 Jun 2012)

  Changed paths:
M django/db/backends/oracle/base.py
M tests/regressiontests/backends/tests.py

  Log Message:
  ---
  Fixed #18465 -- Set date formats correctly on Oracle

Correctly configure NLS_SESSION_PARAMETERS to format Date and DateTime
on Oracle backend.

Thanks to Josh Smeaton for report & patch.



-- 
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] #18518: wsgi.py does not overwrite DJANGO_SETTINGS_MODULE in apache prefork

[Django]

#18518: wsgi.py does not overwrite DJANGO_SETTINGS_MODULE in apache prefork
---+--
 Reporter:  schaefer@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 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 carljm):

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


Comment:

 There is a reason to try to avoid overwriting the environment variable -
 there are quite a few use cases where you might want to set the
 environment variable yourself externally, if you are using multiple
 different settings files in your project (a common practice). The value
 hardcoded in the wsgi file is intended only as a fallback default. In
 general, hardcoded values should not override values set explicitly in the
 environment.

 Running multiple different Django sites in the same process under
 preforked Apache is an edge case, and it's easy enough to change the
 default wsgi file in your project (or use SetEnv in the virtualhost) if
 you are in that situation.

-- 
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] #9893: Filename + path length greater than 100 truncated on database insertion in Core.Storage

[Django]

#9893: Filename + path length greater than 100 truncated on database insertion 
in
Core.Storage
---+-
 Reporter:  Refefer|Owner:  aaugustin
 Type:  Bug|   Status:  closed
Component:  Core (Other)   |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords:  storage, filename  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by Claude Paroz ):

 In [05d333ba3bb16af024c11966d2072de38fe9f82f]:
 {{{
 #!CommitTicketReference repository=""
 revision="05d333ba3bb16af024c11966d2072de38fe9f82f"
 Fixed #18515 -- Conditionally regenerated filename in FileField validation

 When a FileField value has been saved, a new validation should not
 regenerate a new filename when checking the length. Refs #9893.
 }}}

-- 
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] #18515: Problematic validation code in FileField

[Django]

#18515: Problematic validation code in FileField
-+-
 Reporter:  yoyoma   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.4
  uploads/storage|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  max_length,  |  Needs documentation:  0
  FileField, fields  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [05d333ba3bb16af024c11966d2072de38fe9f82f]:
 {{{
 #!CommitTicketReference repository=""
 revision="05d333ba3bb16af024c11966d2072de38fe9f82f"
 Fixed #18515 -- Conditionally regenerated filename in FileField validation

 When a FileField value has been saved, a new validation should not
 regenerate a new filename when checking the length. Refs #9893.
 }}}

-- 
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] 05d333: Fixed #18515 -- Conditionally regenerated filename...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 05d333ba3bb16af024c11966d2072de38fe9f82f
  
https://github.com/django/django/commit/05d333ba3bb16af024c11966d2072de38fe9f82f
  Author: Claude Paroz 
  Date:   2012-06-26 (Tue, 26 Jun 2012)

  Changed paths:
M django/db/models/fields/files.py
M tests/modeltests/files/models.py
M tests/modeltests/files/tests.py
M tests/regressiontests/model_fields/tests.py

  Log Message:
  ---
  Fixed #18515 -- Conditionally regenerated filename in FileField validation

When a FileField value has been saved, a new validation should not
regenerate a new filename when checking the length. Refs #9893.



-- 
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] #17485: Queries with both deferred fields and select_related defer field.name instead of field.attname

[Django]

#17485: Queries with both deferred fields and select_related defer field.name
instead of field.attname
-+-
 Reporter:  konk |Owner:  konk
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  defer|  Needs documentation:  0
  select_related |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [b6c356b7bb97f3d6d4831b31e67868313bbbc090]:
 {{{
 #!CommitTicketReference repository=""
 revision="b6c356b7bb97f3d6d4831b31e67868313bbbc090"
 Fixed #17485 -- Made defer work with select_related

 This commit tackles a couple of issues. First, in certain cases there
 were some mixups if field.attname or field.name should be deferred.
 Field.attname is now always used.

 Another issue tackled is a case where field is both deferred by
 .only(), and selected by select_related. This case is now an error.

 A lot of thanks to konk (Michal Petrucha) for the patch, and
 to Andrei Antoukh for review.
 }}}

-- 
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] b6c356: Fixed #17485 -- Made defer work with select_relate...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: b6c356b7bb97f3d6d4831b31e67868313bbbc090
  
https://github.com/django/django/commit/b6c356b7bb97f3d6d4831b31e67868313bbbc090
  Author: Anssi Kääriäinen 
  Date:   2012-06-26 (Tue, 26 Jun 2012)

  Changed paths:
M django/db/models/query.py
M django/db/models/query_utils.py
M django/db/models/sql/compiler.py
M django/db/models/sql/query.py
M docs/ref/models/querysets.txt
M tests/modeltests/defer/tests.py
M tests/regressiontests/defer_regress/models.py
M tests/regressiontests/defer_regress/tests.py
M tests/regressiontests/select_related_regress/tests.py

  Log Message:
  ---
  Fixed #17485 -- Made defer work with select_related

This commit tackles a couple of issues. First, in certain cases there
were some mixups if field.attname or field.name should be deferred.
Field.attname is now always used.

Another issue tackled is a case where field is both deferred by
.only(), and selected by select_related. This case is now an error.

A lot of thanks to konk (Michal Petrucha) for the patch, and
to Andrei Antoukh for review.



-- 
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] #15197: yaml serialization to HttpResponse fails

[Django]

#15197: yaml serialization to HttpResponse fails
--+
 Reporter:  fourga38  |Owner:  hirokiky
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:  yaml  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by anonymous):

 * 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] #18148: django.contrib.sites.managers.CurrentSiteManager should be able to span multiple models

[Django]

#18148: django.contrib.sites.managers.CurrentSiteManager should be able to span
multiple models
---+
 Reporter:  rgeoghegan |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  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 krzysiumed):

 * 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] #10944: Site app should be able to make absolute URLs.

[Django]

#10944: Site app should be able to make absolute URLs.
---+--
 Reporter:  jdunck |Owner:  krzysiumed
 Type:  New feature|   Status:  assigned
Component:  contrib.sites  |  Version:  1.0
 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 krzysiumed):

 * 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] #13559: Need a contextprocessor for current site

[Django]

#13559: Need a contextprocessor for current site
---+--
 Reporter:  tonnzor|Owner:  krzysiumed
 Type:  New feature|   Status:  assigned
Component:  contrib.sites  |  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 krzysiumed):

 * 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] #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
+
Changes (by krzysiumed):

 * cc: krzysiumed@… (added)
 * owner:  fcurella => nobody


-- 
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] #13559: Need a contextprocessor for current site

[Django]

#13559: Need a contextprocessor for current site
---+--
 Reporter:  tonnzor|Owner:  krzysiumed
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  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 krzysiumed):

 * easy:  1 => 0


Comment:

 I did some minor changes in hop's patch:
 - Repaired a few broken links at
 
[[https://docs.djangoproject.com/en/dev/ref/contrib/sites/|/ref/contrib/sites.txt]]
 doc.
 - Added note at [[https://docs.djangoproject.com/en/1.4/ref/settings
 /#template-context-processors|/ref/settings/#template-context-
 processors]].
 - Sites tests used [[https://docs.djangoproject.com/en/1.4/ref/generic-
 views/#django-views-generic-simple-direct-to-
 template|django.views.generic.simple.direct_to_template]]
   function which comes from old function-based generic views which
   were permanently deleted. This made some tests broken.
   [[https://docs.djangoproject.com/en/dev/ref/class-based-
 
views/base/#django.views.generic.base.TemplateView|django.view.generic.TemplateView]]
 is used now and all tests pass.
 - Refactored context processors' tests -- joined `ContextProcessorTest`
   and `RequestSiteContextTest`, tests use
   [[https://docs.djangoproject.com/en/dev/topics/testing/?from=olddocs
 #overriding-settings|django.test.utils.override_settings]] instead of
 overriding settings
   in `setUp` and `tearDown`.
 - Formatted in PEP8 style.

-- 
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] #7145: 'NoneType' object has no attribute 'year' in admin change list when using date_hierarchy with a date field with null values

[Django]

#7145: 'NoneType' object has no attribute 'year' in admin change list when using
date_hierarchy with a date field with null values
-+-
 Reporter:  Eric Walstad |Owner:  nobody
     |   Status:  reopened
 Type:  Uncategorized|  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * status:  closed => reopened
 * severity:   => Normal
 * resolution:  worksforme =>
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => Uncategorized


Comment:

 is ind 1.4

-- 
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] #18518: wsgi.py does not overwrite DJANGO_SETTINGS_MODULE in apache prefork

[Django]

#18518: wsgi.py does not overwrite DJANGO_SETTINGS_MODULE in apache prefork
---+
 Reporter:  schaefer@… |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The wsgi.py Django WSGI application shipped with Django 1.4 contains the
 following piece of code:

 {{{
 os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name
 }}.settings")
 }}}

 (Obviously adapted to the respective project)

 Using setdefault() here is wrong. When using a preforked Apache, different
 WSGI-application can be run consecutively in the same process. If they use
 different setting modules, the second application will not overwrite the
 settings module of the first, resulting in the wrong Django application to
 be shown.

 == Reproduction ==

 - Create two Django projects
 - Host each of them on a different virtual host
 - Reload one a number of times to "seed" the processes
 - Reload the other one. Notice that (randomly) it shows the *first*
 project instead of the second

 == Fix ==

 Replace the aforementioned line with the following:

 {{{
 os.environ["DJANGO_SETTINGS_MODULE"] = "{{ project_name }}.settings"
 }}}

 There is no reason to try and avoid overwriting the environment variable.

-- 
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] #18296: Make creating apps inside project folder more intuitive with manage.py startapp command

[Django]

#18296: Make creating apps inside project folder more intuitive with manage.py
startapp command
-+-
 Reporter:  lgp171188@…  |Owner:
 Type:   |  vanessagomes
  Cleanup/optimization   |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  manage.py, startapp  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by vanessagomes):

 * cc: vanessagomes (added)


Comment:

 I think we should open a new ticket about the docs, so we can discuss if
 we should change a little bit of...

-- 
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] #13809: FileField open method is only accepting 'rb' modes

[Django]

#13809: FileField open method is only accepting 'rb' modes
--+
 Reporter:  canassa   |Owner:
 Type:  Bug   |   Status:  new
Component:  File uploads/storage  |  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
--+

Comment (by claudep):

 #16964 was a duplicate.

-- 
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] #16964: FileField files can't be opened in write mode if not closed before

[Django]

#16964: FileField files can't be opened in write mode if not closed before
-+-
 Reporter:  jonash   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.3
  uploads/storage|   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

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


Comment:

 Duplicate of #13809

-- 
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] #13314: "FileField" validation does not account for "upload_to" when counting characters

[Django]

#13314: "FileField" validation does not account for "upload_to" when counting
characters
+-
 Reporter:  denilsonsa  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  1.1
 Severity:  Normal  |   Resolution:  duplicate
 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):

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


Comment:

 Duplicate of #9893.

-- 
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] #15197: yaml serialization to HttpResponse fails

[Django]

#15197: yaml serialization to HttpResponse fails
--+
 Reporter:  fourga38  |Owner:  hirokiky
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:  yaml  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by hirokiky):

 * owner:  nobody => hirokiky


-- 
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] #13809: FileField open method is only accepting 'rb' modes

[Django]

#13809: FileField open method is only accepting 'rb' modes
--+
 Reporter:  canassa   |Owner:
 Type:  Bug   |   Status:  new
Component:  File uploads/storage  |  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 claudep):

 * owner:  nobody =>
 * status:  reopened => new
 * has_patch:  0 => 1
 * needs_tests:  1 => 0


Comment:

 The patch is still not optimal, because the file is opened in 'rb' mode
 upon access, then closed and reopened in the specified mode. Seems to
 work, though.

-- 
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] #8341: InlineModelAdmin is missing `can_delete` and `can_order`

[Django]

#8341: InlineModelAdmin is missing `can_delete` and `can_order`
---+
 Reporter:  ciantic@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 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 brillgen):

 * cc: dev@… (added)
 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 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] #18517: URLField does not support url with underscore

[Django]

#18517: URLField does not support url with underscore
-+--
 Reporter:  guoqiao  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.4
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  URLFiled | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--

Comment (by aaugustin):

 To be honest, the URLValidator doesn't aim for strict conformance to RFC.
 Rather, it attempts to catch typos in URLs entered manually in the admin.

 Of course, it follows the RFC whenever possible, but it's also written
 with real-life use cases in mind.

-- 
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] #18517: URLField does not support url with underscore

[Django]

#18517: URLField does not support url with underscore
-+--
 Reporter:  guoqiao  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.4
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  URLFiled | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by claudep):

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


Comment:

 The Django URLValidator is aiming to check if URLs are valid according to
 official rules (RFC 1034/1035) which forbid the usage of underscores in
 hostnames (read also http://www.quora.com/Domain-Name-System-DNS/Why-are-
 underscores-not-allowed-in-DNS-host-names).

 If you want to relax rules for your particular usage, just subclass
 fields/validators and adapt them. But I don't think we should change the
 default validator for broken existing URLs.

 About the example you provided, see
 https://github.com/rtfd/readthedocs.org/issues/148

-- 
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] #18517: URLField does not support url with underscore

[Django]

#18517: URLField does not support url with underscore
-+--
 Reporter:  guoqiao  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  URLFiled | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--

Old description:

> if your url has a '_' in it, like this:
> http://django_compressor.readthedocs.org/
> the URLField will complain that it is not a valid url. the problem lies
> in the '_' symbol. I find in the source code as Following:
> class URLValidator(RegexValidator):
> regex = re.compile(
> r'^(?:http|ftp)s?://' # http:// or https://
> r'(?:(?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+(?:[A-Z]{2,6}\.?|[A-Z0-9-]{2,}\.?)|'
> #domain...
> r'localhost|' #localhost...
> r'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})' # ...or ip
> r'(?::\d+)?' # optional port
> r'(?:/?|[/?]\S+)$', re.IGNORECASE)
> the related part is this line:
> r'(?:(?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+(?:[A-Z]{2,6}\.?|[A-Z0-9-]{2,}\.?)|'
> It's clear that '_' is not included in the pattern.
> I think this is not reaonable for there's a lot of url has a '_' in it.

New description:

 if your url has a '_' in it, like this:
  * http://django_compressor.readthedocs.org/
 the URLField will complain that it is not a valid url. the problem lies in
 the '_' symbol. I find in the source code as Following:
 {{{
 class URLValidator(RegexValidator):
 regex = re.compile(
 r'^(?:http|ftp)s?://' # http:// or https://
 
r'(?:(?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+(?:[A-Z]{2,6}\.?|[A-Z0-9-]{2,}\.?)|'
 #domain...
 r'localhost|' #localhost...
 r'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})' # ...or ip
 r'(?::\d+)?' # optional port
 r'(?:/?|[/?]\S+)$', re.IGNORECASE)
 }}}

 the related part is this line:
 {{{
 
r'(?:(?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+(?:[A-Z]{2,6}\.?|[A-Z0-9-]{2,}\.?)|'
 }}}

 It's clear that '_' is not included in the pattern.
 I think this is not reaonable for there's a lot of url has a '_' in it.

--

Comment (by claudep):

 Reformatted, please use preview before posting the ticket.

-- 
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] #18515: Problematic validation code in FileField

[Django]

#18515: Problematic validation code in FileField
-+-
 Reporter:  yoyoma   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  1.4
  uploads/storage|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  max_length,  |  Needs documentation:  0
  FileField, fields  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by claudep):

 * component:  Uncategorized => File uploads/storage
 * has_patch:  0 => 1
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


-- 
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] #18517: URLField does not support url with underscore

[Django]

#18517: URLField does not support url with underscore
-+--
 Reporter:  guoqiao  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  URLFiled | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by guoqiao):

 * cc: guoqiao (added)
 * needs_better_patch:   => 0
 * component:  Uncategorized => Core (URLs)
 * needs_tests:   => 0
 * easy:  0 => 1
 * keywords:   => URLFiled
 * needs_docs:   => 0
 * type:  Uncategorized => Bug


-- 
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] #18517: URLField does not support url with underscore

[Django]

#18517: URLField does not support url with underscore
---+
 Reporter:  guoqiao|  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
---+
 if your url has a '_' in it, like this:
 http://django_compressor.readthedocs.org/
 the URLField will complain that it is not a valid url. the problem lies in
 the '_' symbol. I find in the source code as Following:
 class URLValidator(RegexValidator):
 regex = re.compile(
 r'^(?:http|ftp)s?://' # http:// or https://
 
r'(?:(?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+(?:[A-Z]{2,6}\.?|[A-Z0-9-]{2,}\.?)|'
 #domain...
 r'localhost|' #localhost...
 r'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})' # ...or ip
 r'(?::\d+)?' # optional port
 r'(?:/?|[/?]\S+)$', re.IGNORECASE)
 the related part is this line:
 
r'(?:(?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+(?:[A-Z]{2,6}\.?|[A-Z0-9-]{2,}\.?)|'
 It's clear that '_' is not included in the pattern.
 I think this is not reaonable for there's a lot of url has a '_' in it.

-- 
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] #18516: NoReverseMatch error when following authentication tutorial

[Django]

#18516: NoReverseMatch error when following authentication tutorial
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 You're most likely using the docs for the development version of Django,
 while running the code of Django 1.4.

 The are a few dozen other tickets in this tracker if you need more
 explanations.

-- 
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] #18516: NoReverseMatch error when following authentication tutorial

[Django]

#18516: NoReverseMatch error when following authentication tutorial
--+
 Reporter:  anonymous |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Page:  https://docs.djangoproject.com/en/dev/topics/auth/

 Fix:  no quotes in
  
 e.g.
 

 See also:  http://stackoverflow.com/questions/4981026/no-reverse-match-
 error

-- 
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.