Re: [Django] #15025: Different template rendering semantics since r14992

[Django]

#15025: Different template rendering semantics since r14992
--+-
  Reporter:  donspaulding | Owner:  nobody 
Status:  new  | Milestone:  1.3
 Component:  Template system  |   Version:  SVN
Resolution:   |  Keywords:  blocker, regression
 Stage:  Accepted | Has_patch:  1  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by mrmachine):

  * has_patch:  0 => 1

Comment:

 Moved patch from #15034 to here, as I still think it solves the issue
 (with test).

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15025: Different template rendering semantics since r14992

[Django]

#15025: Different template rendering semantics since r14992
--+-
  Reporter:  donspaulding | Owner:  nobody 
Status:  new  | Milestone:  1.3
 Component:  Template system  |   Version:  SVN
Resolution:   |  Keywords:  blocker, regression
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by mrmachine):

  * milestone:  => 1.3

Comment:

 Looking at [14992], I believe that the problem is only on the debug page.

 When rendering normal templates, any template variable resolution that
 raises an exception *should* raise it loudly if the exception doesn't
 explicitly have an attribute `silent_variable_failure` which is `True`.
 The exception should then be displayed on the debug page or emailed to the
 developer, etc.

 The problem now with the debug page is that it is resolving local vars for
 each stack frame as template vars, which transforms the variable in the
 case of a callable. Besides possibly raising exceptions and crashing the
 debug page, this is incorrect behaviour for the debug page which should
 only be showing the `__repr__` for stack frame local vars, not evaluating
 and transforming them.

 For example, if your view has a variable `form_class` which is a subclass
 of `django.forms.Form`, the debug page should display this as a form class
 and not as an unbound form instance.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15018: LimitedStream.readline deals parameter not correct

[Django]

#15018: LimitedStream.readline deals parameter not correct
-+--
  Reporter:  xjdrew  | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by xjdrew):

  * status:  closed => reopened
  * resolution:  worksforme =>
  * component:  Uncategorized => Core framework

Comment:

 Replying to [comment:1 russellm]:
 > Your point 3 doesn't make any sense, and I can't work out what it might
 be a typo for.
 >
 > If you want to prove there is a problem here, write a formal test case.
 
[http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/requests/tests.py#L101
 There are existing tests for LimitedStream] covering a wide range of
 potential use cases; if you can encode your use case as a test that fails,
 please provide that test and reopen.
 [[BR]]
 Thanks for your comment and the test case suggestion.[[BR]]
 [[BR]]
 I make a mistake about point 3, it should be:[[BR]]
 '''3. and len(self.buffer) > size'''

 I make a usecase as below:[[BR]]
 first, I modify the function LimitedStream.readline to add some log as
 below:

 {{{
 def readline(self, size=None):
 print "buff length: %s" % len(self.buffer) ### print buffer
 size
 while '\n' not in self.buffer or \
   (size is not None and len(self.buffer) < size):
 }}}

 It will print the internal buffer status.

 second, I test the class as below:

 {{{
 >>> stream = LimitedStream(StringIO('te\nabcdefghijkhlmnopqrstuvwst'), 10)
  init buffer size => 10
 >>> stream.readline(5)
 buff length: 0
 'te\n'
 >>> stream.readline(1)
 buff length: 2
 'a'
 >>> stream.readline(1)
 buff length: 25  # buffer overflow
 'b'
 }}}


 it's easy to explain. at the beginning, the buffer size is 0, after I call
 readline(5), the buffer size becomes 2 (equals 5 - len(line) ), then I
 call readline(1), now it meets the three conditions I list before. so it
 execute '''chunk = self._read_limited(size - len(self.buffer))''', that is
 '''chunk = self._read_limited(-1)''', for the underlay StringIO, it reads
 all content. so when I call readline(1) again, you see, '''the buffer
 becomes 25, it's more than the size I init.'''

 If I replace StringIO with other stream, the behavior maybe different;
 And if the underlay stream is a very very very big file, the program maybe
 crash.
 ...

 So I suggest, it's a potential bug.

 best regards,
 Drew

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15035: collectstatic does not support remote backends that implement modified_time

[Django]

#15035: collectstatic does not support remote backends that implement 
modified_time
---+
 Reporter:  bendavis78 |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 My CDN (rackspace cloud files) supports getting the modified time of an
 object.  If I implement modified_time() in my cloud storage app, we get an
 exception:

 {{{
 Traceback (most recent call last):
   File "./manage.py", line 26, in 
 management.execute_from_command_line()
   File
 
"/home/ben/Projects/SavidWorks/ellableu/.env/src/django/django/core/management/__init__.py",
 line 429, in execute_from_command_line
 utility.execute()
   File
 
"/home/ben/Projects/SavidWorks/ellableu/.env/src/django/django/core/management/__init__.py",
 line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File
 
"/home/ben/Projects/SavidWorks/ellableu/.env/src/django/django/core/management/base.py",
 line 191, in run_from_argv
 self.execute(*args, **options.__dict__)
   File
 
"/home/ben/Projects/SavidWorks/ellableu/.env/src/django/django/core/management/base.py",
 line 220, in execute
 output = self.handle(*args, **options)
   File
 
"/home/ben/Projects/SavidWorks/ellableu/.env/src/django/django/core/management/base.py",
 line 351, in handle
 return self.handle_noargs(**options)
   File
 
"/home/ben/Projects/SavidWorks/ellableu/.env/src/django/django/contrib/staticfiles/management/commands/collectstatic.py",
 line 78, in handle_noargs
 self.copy_file(source, prefix, storage, **options)
   File
 
"/home/ben/Projects/SavidWorks/ellableu/.env/src/django/django/contrib/staticfiles/management/commands/collectstatic.py",
 line 130, in copy_file
 self.destination_storage.path(destination))
   File
 
"/home/ben/Projects/SavidWorks/ellableu/.env/src/django/django/core/files/storage.py",
 line 86, in path
 raise NotImplementedError("This backend doesn't support absolute
 paths.")
 NotImplementedError: This backend doesn't support absolute paths.
 }}}

 This can be fixed by setting destination_is_link to False when
 self.distination_local is False. Patch is attached.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15025: Different template rendering semantics since r14992

[Django]

#15025: Different template rendering semantics since r14992
--+-
  Reporter:  donspaulding | Owner:  nobody 
Status:  new  | Milestone: 
 Component:  Template system  |   Version:  SVN
Resolution:   |  Keywords:  blocker, regression
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by kmtracey):

 I think #15034 reported this again with a patch w/ test for the debug
 page. The description here makes me think problems due to this change may
 be more widespread than just the debug page?

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15034: Django's pretty error handling fails if there's a callable local var that generates an exception in the stack trace.

[Django]

#15034: Django's pretty error handling fails if there's a callable local var 
that
generates an exception in the stack trace.
-+--
  Reporter:  mrmachine   | Owner:  nobody   
  
Status:  closed  | Milestone:  1.3  
  
 Component:  Core framework  |   Version:  SVN  
  
Resolution:  duplicate   |  Keywords:  debug template 500 error 
exception hijacked
 Stage:  Unreviewed  | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

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

Comment:

 I believe this is #15025.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15034: Django's pretty error handling fails if there's a callable local var that generates an exception in the stack trace.

[Django]

#15034: Django's pretty error handling fails if there's a callable local var 
that
generates an exception in the stack trace.
-+--
  Reporter:  mrmachine   | Owner:  nobody   
  
Status:  new | Milestone:  1.3  
  
 Component:  Core framework  |   Version:  SVN  
  
Resolution:  |  Keywords:  debug template 500 error 
exception hijacked
 Stage:  Unreviewed  | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by mrmachine):

  * 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15034: Django's pretty error handling fails if there's a callable local var that generates an exception in the stack trace.

[Django]

#15034: Django's pretty error handling fails if there's a callable local var 
that
generates an exception in the stack trace.
-+--
  Reporter:  mrmachine   | Owner:  nobody   
  
Status:  new | Milestone:  1.3  
  
 Component:  Core framework  |   Version:  SVN  
  
Resolution:  |  Keywords:  debug template 500 error 
exception hijacked
 Stage:  Unreviewed  | Has_patch:  1
  
Needs_docs:  1   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by mrmachine):

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

Comment:

 Just added a patch with tests. I don't think this needs any documentation.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15034: Django's pretty error handling fails if there's a callable local var that generates an exception in the stack trace.

[Django]

#15034: Django's pretty error handling fails if there's a callable local var 
that
generates an exception in the stack trace.
-+--
 Reporter:  mrmachine|   Owner:  nobody 
   
   Status:  new  |   Milestone:  1.3
   
Component:  Core framework   | Version:  SVN
   
 Keywords:  debug template 500 error exception hijacked  |   Stage:  
Unreviewed
Has_patch:  0|  
-+--
 To reproduce, just add the following to any known working view:

 {{{
 from django.forms import BaseForm
 raise Exception
 }}}

 Instead of getting Django's pretty error handling, you will get a raw
 traceback in your browser that has nothing to do with the Exception you
 raised.

 The reason why is that `TECHNICAL_500_TEMPLATE` contains `{{
 var.1|pprint|force_escape }}` which triggers a call to
 `Variable().resolve()` which tries calling `var.1` (since it is callable)
 before passing it into the `pprint` filter.

 If `var.1` raises an exception when called, as `BaseForm` does (by design
 in this case as it's not meant to be called directly), the pretty error
 handling is hijacked and you have no idea what caused it.

 The fix is to call pprint() and force_escape() on each frame's local vars
 before passing them to the template as context.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11212: Don't encode emails with base64/qp

[Django]

#11212: Don't encode emails with base64/qp
---+
  Reporter:  phr   | Owner:  nobody   
Status:  new   | Milestone:  1.3  
 Component:  django.core.mail  |   Version:  SVN  
Resolution:|  Keywords:  send_mail
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by andrewbadr):

  * milestone:  => 1.3

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15033: sqlindexes doesn't create indexes for ForeignKeys on normal ManyToManyFields

[Django]

#15033: sqlindexes doesn't create indexes for ForeignKeys on normal
ManyToManyFields
+---
 Reporter:  cdestigter  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 [http://code.djangoproject.com/ticket/2350#comment:6 this comment] implies
 that the !ForeignKeys created by ManyToManyField tables should also have
 indexes (makes sense, right? Otherwise we'll have to always create them
 with custom SQL, or define a through relation every time, gross.)

 However sqlindexes doesn't create the indexes. It does create the (from,
 to) unique constraints, but that's actually not very useful for many
 queries...

 The fix is to change
 
[http://code.djangoproject.com/browser/django/trunk/django/core/management/sql.py#L140
 django/core/management/sql.py#L140]:

 {{{
 for model in models.get_models(app):
 }}}

 to:

 {{{
 for model in models.get_models(app, include_auto_created=True):
 }}}

 Tested in 1.2.4 and trunk (r15153).

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15032: Changeset 15031 breaks filtering to objects which are subclassed.

[Django]

#15032: Changeset 15031 breaks filtering to objects which are subclassed.
---+
  Reporter:  rene  | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  django.contrib.admin  |   Version:  1.2
   
Resolution:|  Keywords:  filtering 
subclassed object not allowed regression blocker
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * keywords:  filtering subclassed object not allowed => filtering
   subclassed object not allowed regression
   blocker
  * stage:  Unreviewed => Accepted
  * milestone:  => 1.3

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15031: I need an alternate ID field with built in validation.

[Django]

#15031: I need an alternate ID field with built in validation.
+---
  Reporter:  rcfeldmann | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 Trac is for logging known bugs in Django. If you have a "how do I"
 question, please ask on django-users.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15032: Changeset 15031 breaks filtering to objects which are subclassed.

[Django]

#15032: Changeset 15031 breaks filtering to objects which are subclassed.
---+
  Reporter:  rene  | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  django.contrib.admin  |   Version:  1.2

Resolution:|  Keywords:  filtering 
subclassed object not allowed
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by rene):

  * summary:  Changeset 15031 breaks filtering to objects which are are
  subclassed. => Changeset 15031 breaks filtering
  to objects which are subclassed.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15032: Changeset 15031 breaks filtering to objects which are are subclassed.

[Django]

#15032: Changeset 15031 breaks filtering to objects which are are subclassed.
---+
  Reporter:  rene  | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  django.contrib.admin  |   Version:  1.2

Resolution:|  Keywords:  filtering 
subclassed object not allowed
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by rene):

  * keywords:  => filtering subclassed object not allowed
  * needs_better_patch:  => 0
  * component:  Uncategorized => django.contrib.admin
  * 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15032: Changeset 15031 breaks filtering to objects which are are subclassed.

[Django]

#15032: Changeset 15031 breaks filtering to objects which are are subclassed.
---+
 Reporter:  rene   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 In changeset 15031 a security check is implemented which checks if the
 parameters in the URL query are indeed field names specified in the
 'list_filter' attribute of the AdminModel.

 This breaks the filtering of a inherintanced model object. See attached
 two files for a sample code.

 I have a 'Employee' class in models.py which is a subclass of
 'django.contrib.auth.models.User'.
 I have a WorkHour class in models.py which has a foreign key to
 'Employee'.
 In admin.py I have WorkHourAdmin which defines a list_filter attribute
 which includes the field 'employee'. This field is the foreign  key to
 Employee.

 The employee filter on 'WorkHour' admin object will generate a lookup key
 like this: 'employee  user_ptr  exact'

 In changeset 15031 this does not the pass the check in
 'django/contrib/admin/options.py' line 243

 The field 'employee  user ptr' is not defined in the 'list_filter'
 attribute on class WorkHourAdmin. But according to me this is a valid
 filtering.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13609: Using a non existent template in admin.Inlines produce error when posting the form

[Django]

#13609: Using a non existent template in admin.Inlines produce error when 
posting
the form
---+
  Reporter:  kunitoki  | Owner:  ojii   

Status:  new   | Milestone:  1.3

 Component:  django.contrib.admin  |   Version:  1.2-beta   

Resolution:|  Keywords:  Inline custom 
template ValidationError ManagementForm data missing tampered
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by ojii):

  * owner:  nobody => ojii

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14972: AdminEmailHandler breaks when report is missing stack trace information

[Django]

#14972: AdminEmailHandler breaks when report is missing stack trace information
-+--
  Reporter:  jamstooks   | Owner:  nobody   
Status:  new | Milestone:  1.3  
 Component:  Core framework  |   Version:  1.3-alpha
Resolution:  |  Keywords:  blocker  
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  1
Needs_better_patch:  0   |  
-+--
Changes (by jamstooks):

  * needs_tests:  0 => 1

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14972: AdminEmailHandler breaks when report is missing stack trace information

[Django]

#14972: AdminEmailHandler breaks when report is missing stack trace information
-+--
  Reporter:  jamstooks   | Owner:  nobody   
Status:  new | Milestone:  1.3  
 Component:  Core framework  |   Version:  1.3-alpha
Resolution:  |  Keywords:  blocker  
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by jamstooks):

 * cc: ben.stoo...@gmail.com (added)
  * has_patch:  0 => 1
  * summary:  AdminEmailHandler breaks when logger is missing stack trace
  information => AdminEmailHandler breaks when
  report is missing stack trace information

Comment:

 I'm actually thinking that this fix belongs in AdminEmailHandler because
 there really isn't a need to call ExceptionReporter if there isn't any
 exception data. Here's a first go at a patch.

 When there is no exception data, instead of using ExceptionReporter to
 create the html_message, I set that to None and use the records {{{msg}}}
 property to populate the message.

 I considered putting the {{{msg}}} text in the subject at first, but since
 it could be long (if triggered by a logger) I thought it better to put in
 the body of the email.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #811: [patch] IPv6 address field support

[Django]

#811: [patch] IPv6 address field support
-+--
  Reporter:  mattimust...@gmail.com  | Owner:  adrian   
  
Status:  reopened| Milestone:  1.3  
  
 Component:  Core framework  |   Version:  SVN  
  
Resolution:  |  Keywords:  ipv6 
IPAddressField
 Stage:  Accepted| Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by san...@steffann.nl):

  * keywords:  => ipv6 IPAddressField
  * milestone:  => 1.3

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14149: LIKE clauses fail in Oracle 9.2.0.7

[Django]

#14149: LIKE clauses fail in Oracle 9.2.0.7
---+
  Reporter:  JirkaV| Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:  oracle
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ikelly):

  * milestone:  => 1.3

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15031: I need an alternate ID field with built in validation.

[Django]

#15031: I need an alternate ID field with built in validation.
---+
 Reporter:  rcfeldmann |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I need users to enter an ID to access other users accounts.  I do not want
 to rely only on the default sequential ID as it would be too easy for an
 incorrect entry to bring up a different user.  Also malicious users can
 just sit and keep adding/subtacting one to every number to determine my
 entire user directory.

 I would like to add two digits to the end of the ID to make an extended
 ID.  The first part will be the core (django's default sequential number),
 concatenated with a digit that is calculated from the core's digits,
 concatenated again with a digit that is calculated from the previous two
 digits.

 Example would be user 0435 would become user 043527. (4+3+5=12 so
 just use the last digit of 2, 5+2=7 again using last digit if it were > 9)

 I was thinking I just need to have an extra field in my database.  So I
 would have ID and ID-Ext and make it appear to users as just one big ID.
 But here is the trouble.

 1) How do I get this to be calculated automatically when a new user is
 added?
 2) How do I get the URLs looking nice?  Without the extension, it would be
 "site/users/0435/", but I want them to enter "site/users/043527/".

 Another benefit of this is that my site looks a little more professional
 without the problem of convincing people to add them to my site seeing
 their user ID as 0005 letting them know I only have 4 other users at
 that point.  Instead they see 000550.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14947: regressiontests.fixtures_regress.tests.TestFixtures.test_dumpdata_uses_default_manager() fails with Python 2.7

[Django]

#14947: 
regressiontests.fixtures_regress.tests.TestFixtures.test_dumpdata_uses_default_manager()
fails with Python 2.7
+---
  Reporter:  Arfrever   | Owner:  nobody 
Status:  reopened   | Milestone:  1.3
 Component:  Uncategorized  |   Version:  1.2
Resolution: |  Keywords:  blocker, regression
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by tclineks):

 Ah, my mistake.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13902: When using a ManyToMany in list_filter, results may apper more than once

[Django]

#13902: When using a ManyToMany in list_filter, results may apper more than once
---+
  Reporter:  rasca | Owner:  rasca  
 
Status:  new   | Milestone:  1.3
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  admin change_list 
list_filter manytomany
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by rasca):

 I've just uploaded a new patch, not sure if it's correct though.

 The problem with the test fail was that the model inherited from another
 concrete model and the get_field() returned FieldDoesNotExist. This are
 the models from the test:

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

 class TitleTranslation(models.Model):
 title = models.ForeignKey(Title)
 text = models.CharField(max_length=100)

 class Recommender(Title):
 pass

 class Recommendation(Title):
 recommender = models.ForeignKey(Recommender)

 class RecommendationAdmin(admin.ModelAdmin):
 search_fields = ('titletranslation__text',
 'recommender__titletranslation__text',)

 }}}


 What I now did is to use get_field_by_name() and perform and extra check
 to see if it's a RelatedObject, in this case
 `isinstance(get_field_by_name('titletranslation')[0],
 models.related.RelatedObject)`

 I'm not familiarized with this part of Django, so I have no idea if what I
 did is correct. If it's not, can you give me some pointers please?

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14498: Forms passed to FormWizard.process_step are not guaranteed to have clean validate data

[Django]

#14498: Forms passed to FormWizard.process_step are not guaranteed to have clean
validate data
---+
  Reporter:  stas  | Owner:  lukeplant
Status:  reopened  | Milestone:   
 Component:  django.contrib.formtools  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by stas):

 * cc: s...@mozilla.com (added)

Comment:

 I can confirm the same issue that niels described. I have a 3-step wizard
 where the step1 form is set up depending on the user's choices in step0.
 When I go from step0 to step1 the wizard works as expected, because `form
 = self.get_form(next_step)` is executed after the processing loop from
 source:django/trunk/django/contrib/formtools/wizard.py#14574#L121.

 However, when I go from step1 to step2, step1 gets instantiated with `form
 = self.get_form(current_step, request.POST)` in
 source:django/trunk/django/contrib/formtools/wizard.py#14574#L96,
 ''before'' the processing loop has a chance to modify the form list. As a
 result, step1 form is still the one I defined in my view when
 instantiating my wizard.

 This is broken both in 1.2.X and on trunk.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14298: maximum open cursors exceeded on Jython and Oracle

[Django]

#14298: maximum open cursors exceeded on Jython and Oracle
---+
  Reporter:  stephanekonstantaropoulos | Owner:  xoror  
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  Oracle 
Jython
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  1  
  
Needs_better_patch:  1 |  
---+
Comment (by xoror):

 The ideal case would be *execute_sql() methods that closes the cursor
 except for queries that have iterators attached to them.
 Those can be closed in the _iter() functions (this is handled by the
 lookup dictionary)

 The patch is getting big due to the fact that cursors are returned and
 processed by subclasses and higher. We had to trace all of them
 to ensure proper closure. The patch will be way smaller if we could
 somehow manage the insert/update/delete parts to behave clean with the
 cursors.

 The current state makes django unuseable with jython/Oracle.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15027: Updated RU translation

[Django]

#15027: Updated RU translation
---+
  Reporter:  blackraven| Owner:  blackraven 
Status:  new   | Milestone: 
 Component:  Translations  |   Version:  SVN
Resolution:|  Keywords:  russian translation
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by blackraven):

  * 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14298: maximum open cursors exceeded on Jython and Oracle

[Django]

#14298: maximum open cursors exceeded on Jython and Oracle
---+
  Reporter:  stephanekonstantaropoulos | Owner:  xoror  
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  Oracle 
Jython
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  1  
  
Needs_better_patch:  1 |  
---+
Comment (by Alex):

 This patch is far too invasive IMO, I'll want to think on 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15026: Test failures in django.contrib.sessions on default project when memcached used as CACHE_BACKEND

[Django]

#15026: Test failures in django.contrib.sessions on default project when 
memcached
used as CACHE_BACKEND
--+-
  Reporter:  jsdalton | Owner:  nobody
Status:  new  | Milestone:  1.3   
 Component:  django.contrib.sessions  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Design decision needed   | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by jsdalton):

  * has_patch:  0 => 1
  * stage:  Ready for checkin => Design decision needed

Comment:

 Actually, I thought about it a bit more this a.m. It occurred to me that
 calling cache.clear() will clear the entire cache, not just the keys set
 during the test run: "Be careful with this; clear() will remove everything
 from the cache, not just the keys set by your application."

 I've submitted what I think is a better approach, which is just to ensure
 that both of the session records created specifically during
 `test_invalid_key` are deleted. I wrapped the code in a try/finally block
 since an AssertionError might prevent those records from being deleted.

 I flipped this back to "Design decision needed" just to ensure a committer
 reviewed this slightly different approach, rather than assuming the new
 patch was 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14298: maximum open cursors exceeded on Jython and Oracle

[Django]

#14298: maximum open cursors exceeded on Jython and Oracle
---+
  Reporter:  stephanekonstantaropoulos | Owner:  xoror  
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  Oracle 
Jython
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  1  
  
Needs_better_patch:  1 |  
---+
Comment (by xoror):

 Ok,

 I've created a new patch. There's one part in the updatecompiler that's
 invokes related objects that needs special attention.

 def execute_sql(self, result_type):
 """
 Execute the specified update. Returns the number of rows affected
 by
 the primary update query. The "primary update query" is the first
 non-empty query that is executed. Row counts for any subsequent,
 related queries are not available.
 """
 cursor = super(SQLUpdateCompiler, self).execute_sql(result_type)
 rows = cursor and cursor.rowcount or 0
 is_empty = cursor is None
 # explicit close, a Del prob won't trigger immediate GC in Jython
 cursor.close()
 del cursor
 for query in self.query.get_related_updates():
 qcompiler = query.get_compiler(self.using)
 aux_rows = qcompiler.execute_sql(result_type)
 if is_empty:
 rows = aux_rows
 is_empty = False
 if (result_type is None and type(qcompiler).__name__ not in
 ['SQLInsertCompiler','SQLUpdateCompiler']):
 # Only insert and update compilers are cursor close-safe.
 # Other compilers using SQLCompiler.execute_sql(None) will
 return open cursor.
 aux_rows.close()
 return rows

 The SQLCompiler base class will return a cursor for result_type = None. So
 all subclasses that do not override this needs to be cleaned manually. I'm
 not really a fan of using type() but I don't know how to solve this
 otherwise in python.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14928: manage runserver does not allow host name as address

[Django]

#14928: manage runserver does not allow host name as address
+---
  Reporter:  Karmel Allison | Owner:  lrekucki 
Status:  new| Milestone:  1.3  
 Component:  django-admin.py runserver  |   Version:  1.3-alpha
Resolution: |  Keywords:  blocker  
 Stage:  Design decision needed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by claudep):

 I've also a use case where I need to provide a FQDN to runserver (handling
 of various subdomains in an app). I do not see the real advantage of using
 the regex instead of the simpler (r)split that was previously used. The
 addr part of the 'addr:port' sequence is my business, not Django's.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15025: Different template rendering semantics since r14992

[Django]

#15025: Different template rendering semantics since r14992
--+-
  Reporter:  donspaulding | Owner:  nobody 
Status:  new  | Milestone: 
 Component:  Template system  |   Version:  SVN
Resolution:   |  Keywords:  blocker, regression
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by anonymous):

 * cc: mb0...@gmail.com (added)

Comment:

 I'm not sure but I guess my case is also related to these changes.
 I get the error: 'ModelForm' object has no attribute '_meta'' caused by a
 {% url profile_overview %} in my template.
 Full traceback here: http://dpaste.com/hold/294818/

 Havent figured out why, but its not there if I go back to r14991.
 More details here:
 http://groups.google.com/group/django-
 users/browse_thread/thread/f1318aecfbc30f76/b16ca41934f76518#b16ca41934f76518

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14955: URLField validation should use HEAD requet instead of GET

[Django]

#14955: URLField validation should use HEAD requet instead of GET
-+--
  Reporter:  claudep | Owner: 
Status:  new | Milestone:  1.3
 Component:  Core framework  |   Version:  SVN
Resolution:  |  Keywords: 
 Stage:  Accepted| Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by claudep):

  * owner:  claudep =>
  * needs_better_patch:  1 => 0

Comment:

 Thanks Luke for the useful insight. The patch now falls back to GET when
 response code is 405 or 501.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14924: I18N looks for translations in the reverse order of the apps

[Django]

#14924: I18N looks for translations in the reverse order of the apps
---+
  Reporter:  vanschelven   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Internationalization  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

  * component:  Uncategorized => Internationalization

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15024: The order of the list returned by django.utils.formats.get_format_modules changes since version 1.2.4

[Django]

#15024: The order of the list returned by 
django.utils.formats.get_format_modules
changes since version 1.2.4
---+
  Reporter:  DavidReynolds | Owner:  nobody 
Status:  reopened  | Milestone:  1.3
 Component:  Internationalization  |   Version:  1.2
Resolution:|  Keywords:  blocker, regression
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * keywords:  => blocker, regression
  * stage:  Unreviewed => Accepted
  * component:  Uncategorized => Internationalization
  * milestone:  => 1.3

Comment:

 Ok - confirmed with en_GB (i18n and l10n enabled); I couldn't reproduce
 with de_DE. It's also a regression from 1.2.3, making this a release
 blocker.

 Still no idea why it would be happening, 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15024: The order of the list returned by django.utils.formats.get_format_modules changes since version 1.2.4

[Django]

#15024: The order of the list returned by 
django.utils.formats.get_format_modules
changes since version 1.2.4
+---
  Reporter:  DavidReynolds  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by DavidReynolds):

 My guess would be the ordering of django.conf.locale.en_GB and
 django.conf.locale.en is changing

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15024: The order of the list returned by django.utils.formats.get_format_modules changes since version 1.2.4

[Django]

#15024: The order of the list returned by 
django.utils.formats.get_format_modules
changes since version 1.2.4
+---
  Reporter:  DavidReynolds  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by DavidReynolds):

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

Comment:

 I can recreate it with a new project in a clean virtualenv.  I think the
 key to what makes it change is setting the LANGUAGE_CODE to 'en-gb' -
 could you try that on your setup and see if you can recreate 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15024: The order of the list returned by django.utils.formats.get_format_modules changes since version 1.2.4

[Django]

#15024: The order of the list returned by 
django.utils.formats.get_format_modules
changes since version 1.2.4
+---
  Reporter:  DavidReynolds  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  worksforme |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 I can't reproduce this, and I can't think of any obvious reason why
 formats would be in unpredictable order; to the best of my knowledge,
 they're always stored and retrieved in list/tuple order.

 If you can provide more complete reproduction instructions (possibly a
 project that duplicates the problem), please reopen.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15030: ModelAdmin media docs don't mention STATIC_URL

[Django]

#15030: ModelAdmin media docs don't mention STATIC_URL
+---
  Reporter:  jezdez | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * version:  1.2 => SVN
  * 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15030: ModelAdmin media docs don't mention STATIC_URL

[Django]

#15030: ModelAdmin media docs don't mention STATIC_URL
---+
 Reporter:  jezdez |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Documentation  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The section in http://docs.djangoproject.com/en/dev/ref/contrib/admin
 /#modeladmin-media-definitions should properly mention what is in
 http://docs.djangoproject.com/en/dev/topics/forms/media/#paths-in-media-
 definitions or just delete the reference to MEDIA_URL.

-- 
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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.