Re: [Django] #11104: HAVING filter screws with extra() SQL parameter ordering

[Django]

#11104: HAVING filter screws with extra() SQL parameter ordering
--+-
  Reporter:  miracle2k| Owner: 
Status:  new  | Milestone: 
 Component:  ORM aggregation  |   Version:  SVN
Resolution:   |  Keywords: 
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by shauncutts):

 * cc: sha...@cuttshome.net (added)

-- 
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] #10284: ModelFormSet - objects are deleted even if commit=False

[Django]

#10284: ModelFormSet - objects are deleted even if commit=False
-+--
  Reporter:  laureline.gue...@makina-corpus.org  | Owner:  
nobody
Status:  new | Milestone:   
 
 Component:  Forms   |   Version:  1.0  
 
Resolution:  |  Keywords:   
 
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  1
 
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

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

[Django] #13681: admindocs

[Django]

#13681: admindocs
--+-
 Reporter:  elkan |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:  default settings.py   |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 alongside the default

 # Uncomment the next line to enable the admin:
 # 'django.contrib.admin',

 it would be nice to also have
 # 'django.contrib.admindocs',

 for newcomers.

-- 
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] #10284: ModelFormSet - objects are deleted even if commit=False

[Django]

#10284: ModelFormSet - objects are deleted even if commit=False
-+--
  Reporter:  laureline.gue...@makina-corpus.org  | Owner:  
nobody
Status:  new | Milestone:   
 
 Component:  Forms   |   Version:  1.0  
 
Resolution:  |  Keywords:   
 
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Comment (by Wedg):

 I'm also not understanding why the patch won't work - do we need to
 document the fact that if you call formset.save(commit=False) you'd need
 to call delete() for each instance in the formset.deleted_objects just
 like you'd have to call save() for other changed/new instances? (If the
 patch were applied...)

 From what I can tell, this is all that's happening in the
 BaseModelFormSet.save_existing_objects method, and all the objects that
 would have delete() called are stored in formset.deleted_objects.

-- 
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] #13680: loaddata should issue a warning when attempting to load data using an unknown serialization format even when it is unspecified

[Django]

#13680: loaddata should issue a warning when attempting to load data using an
unknown serialization format even when it is unspecified
---+
  Reporter:  stevecr...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Core framework|   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by stevecr...@gmail.com):

 I took a look at how loaddata processes fixtures and it appears that it
 builds a list of every possible combination of serialization and
 compression format then checks the filesystem for each one.

 In order to solve this issue, we'll need to either have a secondary
 filesystem search for files that start with the specified fixture_labels,
 or we'll need to change the way loaddata works by first examining the
 filesystem for matches and then determining if suitable
 compression/serialization support exists. If a core developer would like
 to give me a hint as to which solution fits best, I will try my hand at a
 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-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] #13680: loaddata should issue a warning when attempting to load data using an unknown serialization format even when it is unspecified

[Django]

#13680: loaddata should issue a warning when attempting to load data using an
unknown serialization format even when it is unspecified
---+
  Reporter:  stevecr...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Core framework|   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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] #13680: loaddata should issue a warning when attempting to load data using an unknown serialization format even when it is unspecified

[Django]

#13680: loaddata should issue a warning when attempting to load data using an
unknown serialization format even when it is unspecified
--+-
 Reporter:  stevecr...@gmail.com  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Core framework| Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 "loaddata" will issue a warning when you specify the filename and
 extension of the fixtures (in an unknown format) you want to load as seen
 in the following example:
 {{{
 ./manage.py loaddata myapp/fixtures/initial_data.yaml
 Problem installing fixture 'myapp/fixtures/initial_data': yaml is not a
 known serialization format.
 }}}

 "loaddata" has a less helpful message when you attempt to load data in an
 unknown format without specifying the file extension (the way syncdb
 does):
 {{{
 ./manage.py loaddata myapp/fixtures/initial_data
 No fixtures found.
 }}}

 When the file myapp/fixtures/initial_data.yaml exists, and pyyaml is not
 installed, the warning message should be the same whether or not you
 specify the file extension. I'd argue that anyone attempting to load
 database fixtures by name (sans extension) when a file exists with the
 same name would want to see this kind of warning. Some applications rely
 on initial_data fixtures and any user who issues ./manage syncdb and
 expects initial_data to load automatically could be frustrated if they
 fail to notice the 'No fixtures found' message. A warning is more
 appropriate in this 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.

[Django] #13679: ModelForms (and hence the admin) no longer honor the default value for a ForeignKey

[Django]

#13679: ModelForms (and hence the admin) no longer honor the default value for a
ForeignKey
-+--
 Reporter:  3point2  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Forms| Version:  1.2   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 In Django 1.1, it was possible to use a callable to set the default value
 on a !ForeignKey field. This functionality was broken in r12721 and
 doesn't currently work in Django 1.2.

 Example:
 {{{
 def get_default():
 return SomeModel.objects.get(id=5)

 class Test(models.Model):
 foo = models.ForeignKey(SomeModel, default=get_default)
 }}}

 This model should display in the admin with the default !SomeModel already
 selected in the drop-down box. The !ModelForm code that does this seems to
 have been confused by the changes made in r12721.

 The code in the Field class in django/db/models/fields/!__init!__.py could
 also do with a cleanup: formfield() first checks has_default() before
 calling get_default(), which also checks has_default(). The patch in
 r12721 adds to this duplication of logic by checking if self.default is
 callable, which is also done by get_default().

-- 
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] #3544: Fix {% include %} to allow recursive includes

[Django]

#3544: Fix {% include %} to allow recursive includes
+---
  Reporter:  David Danier   | 
Owner:  nobody   
Status:  new| 
Milestone:   
 Component:  Template system|   
Version:  SVN  
Resolution: |  
Keywords:  tplrf-patched
 Stage:  Design decision needed | 
Has_patch:  1
Needs_docs:  1  |   
Needs_tests:  1
Needs_better_patch:  1  |  
+---
Changes (by RaceCondition):

 * cc: RaceCondition (added)

Comment:

 What exactly is keeping the diff from being added to trunk? And meanwhile,
 is there a workaround for displaying recursive data structures? inclusion
 tags?

-- 
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] #13678: Improve RawQuerySet coverage

[Django]

#13678: Improve RawQuerySet coverage
---+
  Reporter:  dcramer   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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] #13678: Improve RawQuerySet coverage

[Django]

#13678: Improve RawQuerySet coverage
--+-
 Reporter:  dcramer   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Right now the RawQuerySet throws an assertion if the query does not start
 with SELECT. While this is useful, it cripples the functionality stopping
 you from doing things like recursive queries in PostgreSQL.

 For example, the recursive query looks like:

 {{{
 WITH RECURSIVE ... () SELECT
 }}}

-- 
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] #13677: wrong backend with multidb and modelformset

[Django]

#13677: wrong backend with multidb and modelformset
---+
 Reporter:  pollux |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 When using a !ModelFormSet with a queryset using a DB different from the
 'default' one, the validation of the fields fails.

 debugging the code shows that the db used is the wrong one:
 {{{
 -> self.instance.clean_fields(exclude=exclude)
   /usr/lib/pymodules/python2.5/django/db/models/base.py(902)clean_fields()
 -> setattr(self, f.attname, f.clean(raw_value, self))
 /usr/lib/pymodules/python2.5/django/db/models/fields/__init__.py(194)clean()
 -> self.validate(value, model_instance)
 /usr/lib/pymodules/python2.5/django/db/models/fields/related.py(831)validate()
 -> qs = self.rel.to._default_manager.filter(**{self.rel.field_name:value})
 > /usr/lib/pymodules/python2.5/django/db/models/manager.py(141)filter()
 -> return self.get_query_set().filter(*args, **kwargs)
 (Pdb) p self.get_query_set().db
 'default'
 }}}

 The !ModelFormSet was created by creating Form with a queryset:
 {{{
 def make_projecttask_formset(p, extra=0):
 class _ProjectTaskForm(forms.ModelForm):
 project = forms.ModelChoiceField(label="Project",
 queryset=Project.objects.using('otherdb').filter(project_id=p.project_id))
 ...
 return modelformset_factory(ew_projecttask, form=_ProjectTaskForm,
 extra=extra)
 }}}

 Expected behavior: used db should be the same as in the queryset

 Note: it seems the problems is known (bug not fixed):
  * discussed in http://groups.google.com/group/django-
 developers/browse_thread/thread/22e52a2fd03eac82
  * someone proposed a patch at
 http://github.com/aparo/django/commit/edcdc1d9364224fcbc3b810b9d9fa19a10cd537c
 (only the fields/related part imho)

-- 
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] #7712: UploadedFile missing readline method

[Django]

#7712: UploadedFile missing readline method
---+
  Reporter:  artagnon  | Owner:  nobody 
Status:  closed| Milestone: 
 Component:  File uploads/storage  |   Version:  SVN
Resolution:  fixed |  Keywords:  upload uploadedfile
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by ericholscher):

 This reminded me of this ticket.

 
http://www.flickr.com/photos/idangazit/4647862449/sizes/l/in/set-72157624124904034/

-- 
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] #13676: broken hash in link to Python strftime docs, in settings doc

[Django]

#13676: broken hash in link to Python strftime docs, in settings doc
---+
 Reporter:  carljm |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 This is about as minor as a doc bug can be, but: the
 [http://docs.djangoproject.com/en/dev/ref/settings/#time-input-formats
 TIME_INPUT_FORMATS documentation] links to the strftime documentation in
 the Python docs at this URL: http://docs.python.org/library/datetime.html
 #strftime-behavior

 This link works, but the hashtag is no longer correct, so you have to
 scroll and find the strftime info manually. The correct URL for the
 strftime details is now: http://docs.python.org/library/datetime.html
 #strftime-strptime-behavior

 Either the hashtag should be removed from this link as too fragile, or it
 should be updated.

-- 
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] #7048: Support clearing FileFields with ModelForms

[Django]

#7048: Support clearing FileFields with ModelForms
---+
  Reporter:  jarrow| Owner:  brosner
Status:  assigned  | Milestone: 
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  1  
Needs_better_patch:  0 |  
---+
Changes (by trent):

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

-- 
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] #13675: Allow savepoint_{rollback,commit} in TestCase

[Django]

#13675: Allow savepoint_{rollback,commit} in TestCase
+---
  Reporter:  Alex   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 I totally duped #12979.  I should search trac before filing a new bug
 (just kidding, I did, trac search sucks).

-- 
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] #13675: Allow savepoint_{rollback,commit} in TestCase

[Django]

#13675: Allow savepoint_{rollback,commit} in TestCase
---+
 Reporter:  Alex   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 currently all "transaction" functions are disabled in TestCase (as opposed
 to TransactionTestCase), including savepoint ones.  However savepoints are
 perfectly fine within the context of a transaction (that's the poitn!).
 They should therefore be alive.

-- 
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] #56: MySQL id columns should be UNSIGNED

[Django]

#56: MySQL id columns should be UNSIGNED
---+
  Reporter:  Manuzhai    | Owner:  
glassresistor
Status:  new   | Milestone:  1.3
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  mysql  
  
 Stage:  Design decision needed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by adamnelson):

 Maybe send the ticket to the django-developers group ... It needs a
 commiter to approve and this ticket is so old it might be hidden.

-- 
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] #13674: Javascript for adding inline fields doesn't update "for" attribute in label

[Django]

#13674: Javascript for adding inline fields doesn't update "for" attribute in 
label
---+
 Reporter:  Jonas  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords:  admin  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 I do some checking for required fields using Javascript in the admin.
 Doing that, I noticed that adding inline fields doesn't update the "for"
 attribute for the new  fields. If the field is called "image", the
 newly added field label looks like this:

 {{{
 Image:
 }}}

 This is the patch that solved it for me:

 {{{
 diff --git a/django/contrib/admin/media/js/inlines.js
 b/django/contrib/admin/media/js/inlines.js
 index cf79023..90b50b5 100644
 --- a/django/contrib/admin/media/js/inlines.js
 +++ b/django/contrib/admin/media/js/inlines.js
 @@ -75,6 +75,14 @@
 }).each(function() {
 var el = $(this);
 el.attr("name",
 el.attr("name").replace(/__prefix__/g, nextIndex));
 +   })
 +   .end()
 +   .filter(function() {
 +   var el = $(this);
 +   return el.attr("for") &&
 el.attr("for").search(/__prefix__/) >= 0;
 +   }).each(function() {
 +   var el = $(this);
 +   el.attr("for",
 el.attr("for").replace(/__prefix__/g, nextIndex));
 });
 if (row.is("tr")) {
 // If the forms are laid out in
 table rows, insert
 }}}

-- 
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] #56: MySQL id columns should be UNSIGNED

[Django]

#56: MySQL id columns should be UNSIGNED
---+
  Reporter:  Manuzhai    | Owner:  
glassresistor
Status:  new   | Milestone:  1.3
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  mysql  
  
 Stage:  Design decision needed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by ssspiochld):

 As it was claimed by @adamnelson as `Design decision needed` I wont change
 the status as `accepted`/`ready for checkin` or should I?

-- 
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] #12500: Support for MySQL Connector/Python

[Django]

#12500: Support for MySQL Connector/Python
+---
  Reporter:  geertjanvdk| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution: |  Keywords:  backend mysql myconnpy
 Stage:  Someday/Maybe  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by dulepov):

 * cc: wwbj2r6...@snkmail.com (added)
  * keywords:  backend mysql => backend mysql myconnpy

-- 
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] #11722: Query lookups that reference an F() expression produce invalid sql

[Django]

#11722: Query lookups that reference an F() expression produce invalid sql
---+
  Reporter:  plan...@provplan.org  | Owner: 
 
Status:  new   | Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:|  Keywords:  F() 
expression query sql
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  1  
 
Needs_better_patch:  1 |  
---+
Changes (by Ubercore):

  * owner:  Ubercore =>
  * status:  assigned => new

Comment:

 Removing myself from this ticket due to lack of time/progress. I still
 plan on looking at it when time is available!

-- 
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] #10758: sys.exc_info() should not be stored on a local variable

[Django]

#10758: sys.exc_info() should not be stored on a local variable
+---
  Reporter:  piotr.findei...@azouk.com  | Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by guettli):

 * cc: h...@tbz-pariv.de (added)

-- 
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] #13673: DEBUG=False and 404 / Flatpages

[Django]

#13673: DEBUG=False and 404 / Flatpages
-+--
 Reporter:  michael.mil...@12mm.net  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Uncategorized| Version:  1.2   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Flatpages and 404 Errors work as expected when running in DEBUG=True mode.

 Setting DEBUG=False disables flatpages and 404 errors return the correct
 404 page but with 200 Http Code and not 404 code.

-- 
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] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
-+--
  Reporter:  etianen | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by DrMeers):

 * cc: DrMeers (added)

-- 
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] #13167: Non-existent arg passed to template filter raises VariableDoesNotExist

[Django]

#13167: Non-existent arg passed to template filter raises VariableDoesNotExist
-+--
  Reporter:  copelco | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Template system |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by kmtracey):

 #13672 (concerned the behavior of the cache tag, specifically, when handed
 non-existed arguments) was closed as a dupe of this one.

-- 
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] #13672: template cache tag should gracefully handle uninitialized variables

[Django]

#13672: template cache tag should gracefully handle uninitialized variables
+---
  Reporter:  nbv4   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution:  duplicate  |  Keywords:  template cache
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

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

Comment:

 #13167 is open for tracking the general problem of !VariableDoesNotExist
 being raised by non-existent filter/tag arguments. There is at least one
 tag (if) that suppresses this behavior, but in general
 !VariableDoesNotExist has been raised for these error cases since before
 1.0. The proposal to change the general behavior involves checking
 TEMPLATE_DEBUG to decide whether to raise an exception or not. Since I
 believe we want to fix the problem in general and not take a tag-by-tag
 approach, I'm going to close this as a dupe of that.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13628: Documentation should discourage the usage of doctests

[Django]

#13628: Documentation should discourage the usage of doctests
+---
  Reporter:  d0ugal | Owner:  d0ugal
Status:  assigned   | Milestone:  1.3   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by d0ugal):

  * needs_better_patch:  1 => 0

Comment:

 Added a new patch that makes more sense. Apologies for the previous rush
 sloppy version.

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