[Django] #16435: Configurable hidden settings in debug mode

[Django]

#16435: Configurable hidden settings in debug mode
--+--
 Reporter:  munderwood@…  |  Owner:  nobody
 Type:  New feature   | Status:  new
Milestone:|  Component:  Core (Other)
  Version:  1.3   |   Severity:  Normal
 Keywords:  settings.py   |   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+--
 Hi all,

 I've ran into the case where I have a settings variable in settings.py
 that I would like to have displayed starred out or hidden when in debug
 mode, like the databases PASSWORD variable. It appears that if its name
 contains SECRET, PASSWORD, PROFANITIES_LIST or SIGNATURE then the debug
 view will hide it, but anything else it wont.

 It would be nice from a user point of view to be able to add to this list
 of hidden keywords to hide specific things that dont fall under these four
 keywords.

 Cheers

 Mark

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
-+-
   Reporter:  semente|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  css, admin, pt-br
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-
Changes (by julien):

 * needs_tests:  1 => 0


Comment:

 That's fair enough, it's debatable and I'm clearly in the minority, so I'm
 removing the flag. Thanks guys for sharing your thoughts!

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #289: [patch] more details with "Please correct the errors below."

[Django]

#289: [patch] more details with "Please correct the errors below."
-+-
   Reporter:  brantley   |  Owner:  nobody
  (deadwisdom@…  | Status:  closed
   Type:  defect |  Component:  contrib.admin
  Milestone: |   Severity:  normal
Version: |   Keywords:  error please
 Resolution:  wontfix|  correct
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by anonymous):

 * ui_ux:   => 0
 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16371: model fieldname as css class in admin edit view

[Django]

#16371: model fieldname as css class in admin edit view
-+-
   Reporter: |  Owner:  nobody
  thomasbilk | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  css class admin
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by julien):

 Do you have specific examples where this is an issue? I for one actually
 have many customised admins that make use of the CSS class as it currently
 is (both for styling and JS transformations).

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16079: Clarify that handler404 and handler500 only applies to project

[Django]

#16079: Clarify that handler404 and handler500 only applies to project
-+-
   Reporter:  Martin |  Owner:  nobody
  Vilcans  | Status:  reopened
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1


Comment:

 Well, it now says that the handlers have to be declared in the "root
 URLconf". More clarification can always be added. In that case, the same
 type of clarification should be made for `handler500`. Please also
 generate your patch from the source tree. Thanks!

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16434: doc patch "widgets.extras" => "extras.widgets"

[Django]

#16434: doc patch "widgets.extras" => "extras.widgets"
---+---
 Reporter:  rfk|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  SVN|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+---
 This is a simple patch to fix references to "django.forms.widgets.extras".
 The correct module name is "django.forms.extras.widgets".

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14792: error in the default for TEMPLATE_CONTEXT_PROCESSORS

[Django]

#14792: error in the default for TEMPLATE_CONTEXT_PROCESSORS
-+-
   Reporter:  lawgon@…   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  settings
 Resolution: |  TEMPLATE_CONTEXT_PROCESSORS
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by lawgon):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 Since this comes up at least a couple of times a week on IRC, and seems to
 me a pretty common requirement, why not just uncomment it and add that
 fact to the docs?

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16524 - django/trunk/tests/regressiontests/i18n/patterns

[noreply]

Author: ramiro
Date: 2011-07-07 17:39:59 -0700 (Thu, 07 Jul 2011)
New Revision: 16524

Modified:
   django/trunk/tests/regressiontests/i18n/patterns/tests.py
Log:
FIlter warnings about deprecated syntax of the `url` template tag in recently 
added tests.

Modified: django/trunk/tests/regressiontests/i18n/patterns/tests.py
===
--- django/trunk/tests/regressiontests/i18n/patterns/tests.py   2011-07-07 
21:46:02 UTC (rev 16523)
+++ django/trunk/tests/regressiontests/i18n/patterns/tests.py   2011-07-08 
00:39:59 UTC (rev 16524)
@@ -1,6 +1,7 @@
 from __future__ import with_statement
 
 import os
+import warnings
 
 from django.core.exceptions import ImproperlyConfigured
 from django.core.urlresolvers import reverse, clear_url_caches
@@ -248,6 +249,14 @@
 """
 Test if the language tag works.
 """
+def setUp(self):
+self.save_warnings_state()
+warnings.filterwarnings('ignore', category=DeprecationWarning,
+module='django.template.defaulttags')
+
+def tearDown(self):
+self.restore_warnings_state()
+
 def test_strings_only(self):
 t = Template("""{% load i18n %}
 {% language 'nl' %}{% url no-prefix-translated %}{% endlanguage %}

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16079: Clarify that handler404 and handler500 only applies to project

[Django]

#16079: Clarify that handler404 and handler500 only applies to project
-+-
   Reporter:  Martin |  Owner:  nobody
  Vilcans  | Status:  reopened
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by anonymous):

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


Comment:

 I disagree. [16449] does not address this problem. The documentation still
 doesn't say anything about that the handlers only work in the project-
 level URLconf.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16374: ExceptionReporter may re-evaluate error-causing queryset, leading to a later DatabaseError that masks the original one

[Django]

#16374: ExceptionReporter may re-evaluate error-causing queryset, leading to a
later DatabaseError that masks the original one
-+-
   Reporter:  aaron  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Other)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  ExceptionReporter
   Triage Stage:  Accepted   |  DatabaseError current transaction
Needs documentation:  0  |  aborted error queryset
Patch needs improvement:  0  |  Has patch:  0
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by lukeplant):

 * component:  Generic views => Core (Other)


Comment:

 Regarding a hook in ``manage.py shell`` - that wouldn't be acceptable,
 because it is far from the only way that Django code is run from an
 interactive Python session.

 Here are some other options for stopping this happening:

  * For your second idea, instead of a global toggle, we could simply
 monkey patch `QuerySet.__repr__` when rendering the error page.
  * We could just do isinstance checks for `QuerySet`.
  * `QuerySet.__repr__` is potentially just one source of DB activity, so a
 fuller solution might be to turn the DB code into 'don't do anything'
 mode. This could be via some global, or by some monkey patching.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16433: Missing 'help_text' in admin form when showing the back reference for a OneToOne field.

[Django]

#16433: Missing 'help_text' in admin form when showing the back reference for a
OneToOne field.
-+---
 Reporter:  chris@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  contrib.admin
  Version:  SVN  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+---
 I'm receiving the following exception in the admin pages for a particular
 construct:


 {{{
 Caught AttributeError while rendering: 'RelatedObject' object has no
 attribute 'help_text'
 }}}


 Here's the pastebin for the full exception: http://dpaste.com/564587/

 The problem, I believe, is that help_text is missing for the admin screens
 when attempting to show a "read only" field of an object that was
 automatically generated from a OneToOneField.

 Here's a reduced form of the models and admin pages that cause the error.
 The application is an art show management software, that has artists,
 pieces, invoices, and a class called "invoice item" that will attach a
 piece to an invoice with a price associated. A piece doesnt have a "sale
 price" until it gets attached to an invoice, a piece can only be on one
 invoice, but an invoice can have many pieces:


 {{{
 class Piece ( models.Model ):
 # most detail omitted
 name = models.CharField ( max_length = 100 )

 class Invoice ( models.Model ):
 # most detail omitted
 total_paid = models.DecimalField ( max_digits=7, decimal_places=2,
 blank=True, null=True )

 class InvoiceItem ( models.Model ):
 piece = models.OneToOneField ( Piece )
 invoice = models.ForeignKey ( Invoice )
 price = models.DecimalField ( max_digits=7, decimal_places=2 )
 def __unicode__ ( self ):
 return "%s for $%s" % ( self.invoice, self.price )
 }}}


 then in admin.py:


 {{{
 class PieceAdmin ( admin.ModelAdmin ):
 # most detail omitted
 fields = ( 'artist', 'pieceid', 'name', 'location', 'not_for_sale',
 'adult', 'min_bid', 'buy_now', 'voice_auction', 'bidsheet_scanned',
 'status', 'top_bid', 'invoiceitem' )
 readonly_fields = ( 'top_bid', 'invoiceitem' )
 }}}


 Most of the "fields" relate to fields that were omitted in the models
 above, or are methods of the PieceAdmin class. Of note is the
 'invoiceitem' field. This is a field automatically generated for a Piece
 because of the OneToOneField field on InvoiceItem. Having this as a
 "readonly_fields" makes it available to the model (that seems to be a
 requirement), however, the presence of this at all generates the above
 exception. This code _did_ work in 1.3. I suspect that help_text is new
 for 1.4, but not all possible combinations of this or that have had the
 help_text added. The above is a bit of a corner-case, I know :)

 I can probably work around this bug by creating an invoiceitem method (in
 much the same way I created a top_bid method).

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16432: MultipleObjectMixin should handle pagination prior to get_context_data

[Django]

#16432: MultipleObjectMixin should handle pagination prior to get_context_data
--+---
 Reporter:  AndrewIngram  |  Owner:  nobody
 Type:  New feature   | Status:  new
Milestone:|  Component:  Generic views
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+---
 The current implementation of MultipleObjectMixin performs all its
 pagination operations as part of get_context_data. Some views might
 require knowledge of pagination earlier in the process, for example a
 ModelFormSetView I've implemented needs to know about the pagination at
 the point it instantiates the FormSet, which happens before
 get_context_data is called.

 At the moment we set self.object_list to the result of
 self.get_queryset(), I am wondering whether self.object_list should
 actually be the paginated result, and we can store the unpaginated
 queryset (unevaluated because we won't usually need it) as
 self.original_object_list (or something nicer) which would also be
 available in the context data.

 I'm concerned that any changes to accomodate this requirement might affect
 the API of MultipleObjectMixin in a backwards-incompatible way, so I'd
 like to get feedback from the core devs as to what the right way to tackle
 this is.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #3615: Can't define forward references in fixtures using MySQL with InnoDB

[Django]

#3615: Can't define forward references in fixtures using MySQL with InnoDB
-+-
   Reporter:  russellm   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  mysql innodb myisam
Needs documentation:  0  |  reference fixture
Patch needs improvement:  1  |  Has patch:  1
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by jsdalton):

 Replying to [comment:38 graham_king]:
 > With this patch, I'm getting errors in the multiple_database tests.
 (./runtests.py multiple_database). The error is always an IntegrityError
 'Cannot add or update a child row: a foreign key constraint fails', for
 various keys. I'll try and narrow it down further. My settings.DATABASES
 has two entires, a 'default' and an 'other', otherwise these tests can't
 run.
 >
 > All the other tests pass, which is a huge improvement on behavior
 without this patch, so congrats and thanks on getting this far.

 I'm getting the same errors in the multiple_database tests using InnoDB
 with or without my patch. Not sure it's related or not, but I'll take a
 closer look as well. FWIW, I'm noticing I don't get any errors when I run
 the tests in isolation, e.g.

 {{{
 $ ./runtests.py --settings=testproject.settings
 multiple_database.QueryTestCase.test_generic_key_reverse_operations
 }}}

 Whereas if I do this:

 {{{
 $ ./runtests.py --settings=testproject.settings
 multiple_database.QueryTestCase
 }}}


 The test_generic_key_reverse_operations() raises an IntegrityError.
 Something is not happening right with the database between tests, but I'm
 not sure what that is either.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16523 - django/trunk/docs/topics

[noreply]

Author: lukeplant
Date: 2011-07-07 14:46:02 -0700 (Thu, 07 Jul 2011)
New Revision: 16523

Modified:
   django/trunk/docs/topics/cache.txt
Log:
Removed a redundant line from the cache_page docs

The code example clearly includes the import, no need to mention it twice.

Modified: django/trunk/docs/topics/cache.txt
===
--- django/trunk/docs/topics/cache.txt  2011-07-07 01:12:45 UTC (rev 16522)
+++ django/trunk/docs/topics/cache.txt  2011-07-07 21:46:02 UTC (rev 16523)
@@ -574,9 +574,6 @@
 (r'^foo/(\d{1,2})/$', cache_page(60 * 15)(my_view)),
 )
 
-If you take this approach, don't forget to import ``cache_page`` within your
-URLconf.
-
 Template fragment caching
 =
 

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
-+-
   Reporter:  semente|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  css, admin, pt-br
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-

Comment (by lukeplant):

 I'd be happy to accept the change without a test. When it comes to testing
 specific output in HTML, the test can be extremely difficult to write in
 such a way that it really tests the issue, and even if you manage it, it
 can be so fragile that it is a liability not an asset - e.g. if you
 rearrange the HTML in the admin, the test will break (either by failing or
 by returning a false positive that just causes confusion later).

 I have seen tests written for very specific HTML output, and have often
 concluded that they were worse than useless.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16431: Redirects ignore query strings should be made optional.

[Django]

#16431: Redirects ignore query strings should be made optional.
-+--
 Reporter:  cnobile  |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Core (Other)
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+--
 Here at Scripps Publications we often get complaints from our sites that
 redirects do not pass the query string on to the redirected URI. I have
 looked at this code and except for ROM changes this code has remained the
 same since the 0.90 days. It seems that the Redirect model could have a
 Yes/No button to either tack on the query string or not. This would be a
 DB change and a code change, but not very difficult from my
 investigations.

 I don't have a patch, but could probably work one up if you feel it is
 necessary.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #3615: Can't define forward references in fixtures using MySQL with InnoDB

[Django]

#3615: Can't define forward references in fixtures using MySQL with InnoDB
-+-
   Reporter:  russellm   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  mysql innodb myisam
Needs documentation:  0  |  reference fixture
Patch needs improvement:  1  |  Has patch:  1
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by graham_king):

 With this patch, I'm getting errors in the multiple_database tests.
 (./runtests.py multiple_database). The error is always an IntegrityError
 'Cannot add or update a child row: a foreign key constraint fails', for
 various keys. I'll try and narrow it down further. My settings.DATABASES
 has two entires, a 'default' and an 'other', otherwise these tests can't
 run.

 All the other tests pass, which is a huge improvement on behavior without
 this patch, so congrats and thanks on getting this far.

 I'm using MySQL 5.1.54 / InnoDB on Ubuntu.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10870: Aggregates with joins ignore extra filters provided by setup_joins

[Django]

#10870: Aggregates with joins ignore extra filters provided by setup_joins
-+-
   Reporter:  fas|  Owner:  fas
   Type:  Bug| Status:  new
  Milestone:  1.3|  Component:  ORM aggregation
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  orm, aggregation,
   Triage Stage:  Accepted   |  join, contenttypes, filter
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 I did some work to allow the contenttype lookup in left joins. This is
 useful in and of itself (you can do something like
 Book.objects.filter(`notes__note__isnull`=True), and it will correctly
 find all books without any notes (before it would not have found any
 books). The work allows also to generate correct results when annotating
 and aggregating.

 There are some loose ends in the patch. First, the clone method of
 sql/query doesn't properly clone the extra_join_filters (the conditions
 need to be deep-copied if I am not mistaken). Second, there is some non-
 dryness in setup_joins. There is also general commenting and stuff like
 that that needs to be done. I don't know if the patch would break under
 more complex joins (the main problem is getting the extra_filter to the
 right join). So, more tests needed also.

 Github branch available at:
 https://github.com/akaariai/django/tree/generic_relations_left_joins

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16377: "Conditionally disabling actions" documentation needs updating

[Django]

#16377: "Conditionally disabling actions" documentation needs updating
-+-
   Reporter: |  Owner:  nobody
  pgullekson@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  1
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 FTR, I've mentioned that because Alex specifically removed the use of
 has_key in r14392 to speed up Django a bit. I think it was regarding using
 Django on PyPy.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16384: Documentation should warn against accessing request.POST in middleware

[Django]

#16384: Documentation should warn against accessing request.POST in middleware
---+---
   Reporter:  tomchristie  |  Owner:  tomchristie
   Type:  Bug  | Status:  new
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by aaugustin):

 OK, that's much better. I hadn't realized the proper solution for upload
 handlers was already described in the docs. Thanks for creating #16430.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16430: Stronger wording for CSRF protection in `modifying upload handlers on the fly`

[Django]

#16430: Stronger wording for CSRF protection in `modifying upload handlers on 
the
fly`
-+-
   Reporter: |  Owner:  nobody
  tomchristie| Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16371: model fieldname as css class in admin edit view

[Django]

#16371: model fieldname as css class in admin edit view
-+-
   Reporter: |  Owner:  nobody
  thomasbilk | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  css class admin
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 1
 * needs_tests:   => 0
 * easy:  1 => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * stage:  Unreviewed => Design decision needed


Comment:

 As is, the patch is backwards incompatible.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16374: ExceptionReporter may re-evaluate error-causing queryset, leading to a later DatabaseError that masks the original one

[Django]

#16374: ExceptionReporter may re-evaluate error-causing queryset, leading to a
later DatabaseError that masks the original one
-+-
   Reporter:  aaron  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Generic views
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  ExceptionReporter
   Triage Stage:  Accepted   |  DatabaseError current transaction
Needs documentation:  0  |  aborted error queryset
Patch needs improvement:  0  |  Has patch:  0
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16407: Unicode not working for direct SQL INSERT

[Django]

#16407: Unicode not working for direct SQL INSERT
-+-
   Reporter: |  Owner:  nobody
  mashedmeat | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by lukeplant):

 A quick note - you should use connection.ops.quote_name to quote the table
 name before doing string interpolation. This is not guaranteed to protect
 against malicious input, but can help with spaces and some other funny
 characters.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16406: Allow separate access to matches from urlpatterns and extra_context args

[Django]

#16406: Allow separate access to matches from urlpatterns and extra_context args
-+-
   Reporter:  apollo13   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  resolvers, reverse
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Design decision needed


-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16397: BaseCommand.execute() swallows ImportError, CommandError even when --traceback is used

[Django]

#16397: BaseCommand.execute() swallows ImportError, CommandError even when
--traceback is used
-+-
   Reporter:  charles@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Management
Version:  1.3|  commands)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16430: Stronger wording for CSRF protection in `modifying upload handlers on the fly`

[Django]

#16430: Stronger wording for CSRF protection in `modifying upload handlers on 
the
fly`
---+---
 Reporter:  tomchristie|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Uncategorized
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 The text in [https://docs.djangoproject.com/en/dev/topics/http/file-
 uploads/#modifying-upload-handlers-on-the-fly modifying upload handlers on
 the fly] could be more strongly worded regarding CSRF protection.

 It might be better if the text "Assuming you do need CSRF protection, you
 will then need to use csrf_protect() on the function that actually
 processes the request." simply read "You will then need to use
 csrf_protect() on the function that actually processes the request."

 Obviously it's a bit of a subjective issue, but I think the stronger
 implication that we're simply explaining how to defer ''when the CSRF
 validation runs'', rather than making a decision about ''if it should be
 run'' would be slightly better.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
-+-
   Reporter:  semente|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  css, admin, pt-br
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-

Comment (by semente):

 Replying to [comment:5 jezdez]:
 > Hmm, is it really valid for all languages to capitalize the first word?

 I'm almost sure that it is valid for all latin-based languages, but has
 other languages affected by this patch (you can see which one using
 {{{grep}}}) so maybe we should send that question to the i18n list and
 listen for opinions from people from that languages.

 About the test, I think is valid create a test for the {{{ capfirst }}}
 filter but not for that 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 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:  jezdez
   Type: | Status:  closed
  Uncategorized  |  Component:  Core (Other)
  Milestone:  1.3|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jamstooks ):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 After thinking about this, I wonder if it's worth falling back to GET for
 any failed request? I've found a variety of IIS servers running ASP.NET
 that are responding with 403 errors or simply timing out on HEAD requests.
 Any thoughts? Should I open another ticket about 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16384: Documentation should warn against accessing request.POST in middleware

[Django]

#16384: Documentation should warn against accessing request.POST in middleware
---+---
   Reporter:  tomchristie  |  Owner:  tomchristie
   Type:  Bug  | Status:  new
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by tomchristie):

 > I'm feeling uneasy about the (implied) suggestion to use @csrf_exempt,
 because of the security implications.

 That's a good point, I think that part is badly written.  Django's docs
 ''do'' already adequately explain how to modify upload handlers on the fly
 using @csrf_exempt/@csrf_protect, so it should mention both (and link to
 that part of the documentation) rather than imply that you should just
 turn off CSRF validation.

 How about the following:

 "**Note**

 Accessing `request.POST` or `request.REQUEST` inside middleware from
 `process_request` or `process_view` will prevent any view running after
 the middleware from being able to
 [https://docs.djangoproject.com/en/dev/topics/http/file-uploads
 /#modifying-upload-handlers-on-the-fly modify the upload handlers for the
 request], and should normally be avoided.

 Note that [https://docs.djangoproject.com/en/1.3/ref/contrib/csrf/#module-
 django.middleware.csrf the CSRF middleware] can be considered an
 exception, as it provides the @csrf_exempt and @csrf_protect decorators
 which allow views to explicitly control at what point the CSRF validation
 should occur."

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16079: Clarify that handler404 and handler500 only applies to project

[Django]

#16079: Clarify that handler404 and handler500 only applies to project
-+-
   Reporter:  Martin |  Owner:  nobody
  Vilcans  | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 This was addressed in [16449].

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15715: Add a non-trivial decorator example to class-based views docs

[Django]

#15715: Add a non-trivial decorator example to class-based views docs
-+-
   Reporter:  toofishes  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Accepted => Ready for checkin


Comment:

 That's great, thank you!

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16000: Add information about using natural keys to contenttype documentation

[Django]

#16000: Add information about using natural keys to contenttype documentation
-+-
   Reporter:  jsdalton   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * ui_ux:   => 0
 * stage:  Accepted => Ready for checkin


Comment:

 That looks great, thanks!

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11185: Document how to customize widgets

[Django]

#11185: Document how to customize widgets
-+-
   Reporter:  bensmith   |  Owner:  fadeev
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  Documentation
  Milestone:  1.3|   Severity:  Normal
Version:  1.0|   Keywords:  widget
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1
 * ui_ux:   => 0


Comment:

 The doc about widgets has recently been improved in [16408], however there
 are still several bits from the patch in this ticket that are worth
 considering. The patch now needs to be updated to fit with the latest
 version of the doc.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11505: Django's TestCase should reset the cache

[Django]

#11505: Django's TestCase should reset the cache
-+-
   Reporter: |  Owner:  andrewfong
  andrewfong | Status:  assigned
   Type:  New|  Component:  Testing framework
  feature|   Severity:  Normal
  Milestone: |   Keywords:  cache testing flush
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by jsdalton):

 * cc: jim.dalton@… (added)
 * needs_tests:  1 => 0


Comment:

 Replying to [comment:7 julien]:
 > #16401 is a duplicate and contains a much more thorough patch.

 Thanks julien for consolidating the new ticket I opened back to this one.

 I'm uploading the latest patch from that ticket here. In a nutshell, this
 approach monkey patches cache and get_cache during test setup and keeps
 track of any keys used during the test. After each test, those keys are
 flushed. We also prepend '_test' to the key prefix to ensure existing
 values are not overwritten. The patch is tested and working. I'm leaving
 it as "needs improvement" for now mainly because there is one test in the
 suite that is failing and I haven't determined why yet. It's minor
 whatever is is though.

 In sum, the patch works great and solves the problem. There was a bit of
 discussion here about the approach, however:
 https://groups.google.com/forum/#!topic/django-developers/zlaPsP13dUY .
 Jacob stated he wasn't necessarily a fan of monkey patching and suggested
 an alternative. I had some thoughts which I posted in response as well.

 If anyone reading this comment is interested in help push this ticket
 toward resolution, a great way would be to review this patch and then
 weigh in on that django dev discussion. If we can reach a consensus on
 django-dev I'd be happy to put in some time to implement whatever approach
 is agreed upon.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16384: Documentation should warn against accessing request.POST in middleware

[Django]

#16384: Documentation should warn against accessing request.POST in middleware
---+---
   Reporter:  tomchristie  |  Owner:  tomchristie
   Type:  Bug  | Status:  new
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by aaugustin):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 Django encourages using `CsrfViewMiddleware`, which does load
 `request.POST`, making this advice a bit pointless (and even counter-
 productive in some cases).

 I'm feeling uneasy about the (implied) suggestion to use `@csrf_exempt`,
 because of the security implications.

 I agree that we should mention this pitfall in the documentation, but I
 can't come up with a really good way to explain it.

 Maybe we should just to state the facts, i.e. say that middleware
 shouldn't access `request.POST`, but that Django's implementation of CSRF
 protection and custom upload handlers are incompatible.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
-+-
   Reporter:  semente|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  css, admin, pt-br
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-

Comment (by julien):

 No problem, I understand the frustration. Been there :-)

 Consistency in requiring tests for (nearly) everything is actually as
 important as the tests themselves, as it's always going to be subjective
 and debatable what is or is not big enough to require tests. Also,
 sometimes, small and seemingly harmless changes end up causing serious
 regressions. It is true that there are more important problems to solve in
 the admin, but everyone is free to spend their time working on the bits
 they want -- it's never going to be a waste of time. If someone cares
 enough about this problem then they'll fix it, write tests and fullfil all
 the requirements for this ticket to proceed.

 It's definitely OK to disagree, and please don't just take my word for it
 and don't let this disagreement hamper your contributions which are very
 much appreciated! :-)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
-+-
   Reporter:  semente|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  css, admin, pt-br
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-

Comment (by aaugustin):

 Sorry for the angry tone in my reply. I wanted to say that, in this
 particular case, the cost of writing a test is very high compared to the
 importance of the bugfix: an utterly minor aesthetic tweak.

 I know the theory of testing, and I agree that tests are important — just
 look at the number of tickets where I set "needs tests". But we have to be
 realistic: if a good Django hacker spends 30 minutes to write a test for
 this, it's a waste of time. There are much more important bugs to fix in
 the admin.

 In short, IMO, we're not focusing on the right priorities. It's OK if you
 disagree and that's why I won't toggle the flag. Now let's stop hijacking
 the tracker with our private discussions :)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
-+-
   Reporter:  semente|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  css, admin, pt-br
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-

Comment (by julien):

 Replying to [comment:6 aaugustin]:
 > I'm curious to know how many of the 33 occurrences of capfirst in the
 admin are actually tested by the test suite :(
 >
 > You'd better close the ticket as 'wontfix'. It's more realistic than
 hoping that someone's going to write tests for this.

 Only this one would need to be tested to proceed with this particular
 ticket. If other cases were tested then that'd be even better, but it's
 not necessary here. It's important to write tests even for seemingly small
 changes like this one to avoid future regressions.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
-+-
   Reporter:  semente|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  css, admin, pt-br
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-
Changes (by julien):

 * stage:  Accepted => Design decision needed


Comment:

 Replying to [comment:5 jezdez]:
 > Hmm, is it really valid for all languages to capitalize the first word?

 That's a good point, yet the admin already capitalizes the first word of
 some translatable strings (e.g. `verbose_name_plural` in
 `delete_selected_confirmation.html`). Moving to DDN until a clear answer
 can be provided on the best approach to handle 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
+---
   Reporter:  semente   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:  css, admin, pt-br
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  1 |
+---

Comment (by aaugustin):

 Replying to [comment:4 julien]:
 > That's right, using `capfirst` in the template is the way to go. This
 now needs tests :)

 I'm curious to know how many of the 33 occurrences of capfirst in the
 admin are actually tested by the test suite :(

 You'd better close the ticket as 'wontfix'. It's more realistic than
 hoping that someone's going to write tests 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16429: Add configurable caching to FilePathField

[Django]

#16429: Add configurable caching to FilePathField
---+
   Reporter:  pressureman  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Forms
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
Changes (by lukeplant):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
+---
   Reporter:  semente   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:  css, admin, pt-br
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  1 |
+---

Comment (by jezdez):

 Hmm, is it really valid for all languages to capitalize the first word?

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16377: "Conditionally disabling actions" documentation needs updating

[Django]

#16377: "Conditionally disabling actions" documentation needs updating
-+-
   Reporter: |  Owner:  nobody
  pgullekson@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  1
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


Comment:

 Thanks for the updated patch. IMO, writing the key twice is the lesser
 evil in this case ;)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
+---
   Reporter:  semente   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:  css, admin, pt-br
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  1 |
+---
Changes (by julien):

 * needs_tests:  0 => 1


Comment:

 That's right, using `capfirst` in the template is the way to go. This now
 needs tests :)

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

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

Re: [Django] #16377: "Conditionally disabling actions" documentation needs updating

[Django]

#16377: "Conditionally disabling actions" documentation needs updating
-+-
   Reporter: |  Owner:  nobody
  pgullekson@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:  1 => 0


Comment:

 I'm sure we could write a whole book on the respective merits of
 {{{
 mydict.pop('mykey', None)# that's unpythonic.
 }}}
 vs.
 {{{
 if 'mykey' in mydict:
 del mydict['mykey']  # we're writing the dict and key names twice!
 }}}
 vs.
 {{{
 try:
 del mydict['mykey']
 except KeyError:
 pass # four lines for this?
 }}}

 Anyway, here's an updated patch...

 Now, back to triaging the unreviewed tickets queue.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16377: "Conditionally disabling actions" documentation needs updating

[Django]

#16377: "Conditionally disabling actions" documentation needs updating
-+-
   Reporter: |  Owner:  nobody
  pgullekson@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by julien):

 Agreed, that's even better. Thanks for correcting me :p

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16394: BaseDateListView has allow_empty = False, documentation claims allow_empty = True

[Django]

#16394: BaseDateListView has allow_empty = False, documentation claims 
allow_empty
= True
-+-
   Reporter: |  Owner:  nobody
  r.tirrell@…| Status:  new
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #16413: changing settings.LOGIN_URL to end with something different than /login/, causes an error in testing your app

[Django]

#16413: changing settings.LOGIN_URL to end with something different than 
/login/,
causes an error in testing your app
+-
   Reporter:  haras |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.auth
Version:  SVN   |   Severity:  Release blocker
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  1
  UI/UX:  0 |
+-
Changes (by julien):

 * needs_better_patch:  0 => 1


Comment:

 I agree that only `auth`'s tests need fixing. However, the tests would be
 more robust if they explicitly overrode the `LOGIN_URL` setting.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16377: "Conditionally disabling actions" documentation needs updating

[Django]

#16377: "Conditionally disabling actions" documentation needs updating
-+-
   Reporter: |  Owner:  nobody
  pgullekson@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 Please don't use `has_key`. It's idiomatic to do:
 {{{
 if 'delete_selected' in self.actions:
 # whatever
 }}}

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16397: BaseCommand.execute() swallows ImportError, CommandError even when --traceback is used

[Django]

#16397: BaseCommand.execute() swallows ImportError, CommandError even when
--traceback is used
-+-
   Reporter:  charles@…  |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by anonymous):

 The easy-to-reproduce case is raising a !CommandError from anywhere in
 execution:

 {{{#!python
 from django.core.management.base import BaseCommand, CommandError

 class Command(BaseCommand):
 """Trigger an ImportError with no stack trace even when --traceback is
 used"""

 help = 'Demonstrate #16397'

 def handle(self, *arguments, **options):
 raise CommandError('foo')
 }}}

 ...in this case, running the command, even with `--traceback`, simply
 results in a single line of output: `Error: foo`.

 However, this isn't much of a bug -- !CommandErrors don't tend to happen
 anywhere but in management commands, and handling them in a user-friendly
 way tends to be desired behavior (though I think it might be fair to break
 that rule when `--traceback` is in use).

 The much more interesting case is triggering an !ImportError during
 `translation.activate()` -- this is what was biting me in practice.
 However, reproducing it (with the various bugs in my codebase which lead
 to it happening in practice fixed) appears to be nontrivial. I'll revisit
 this later.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16377: "Conditionally disabling actions" documentation needs updating

[Django]

#16377: "Conditionally disabling actions" documentation needs updating
-+-
   Reporter: |  Owner:  nobody
  pgullekson@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1


Comment:

 I think it would be a bit cleaner and read better using the conditional
 test: `if actions.has_key('delete_selected')`. What do you think?

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16429: Add configurable caching to FilePathField

[Django]

#16429: Add configurable caching to FilePathField
-+
 Reporter:  pressureman  |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Forms
  Version:  SVN  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+
 As noted by a couple of people on django-users, FilePathField does not
 automatically refresh choices if files are add to or removed from the path
 being pointed to (http://groups.google.com/group/django-
 users/browse_thread/thread/6778fa138b848996 and
 http://groups.google.com/group/django-
 users/browse_thread/thread/403d872cf9433905).

 A nice addition to FilePathField would be the ability to control how long
 the choices are cached for, ranging from "never cached" to "cached
 forever" (or at least for the lifetime of the webserver process).

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
-+-
   Reporter:  haras  |  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * 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-updates@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] #11505: Django's TestCase should reset the cache

[Django]

#11505: Django's TestCase should reset the cache
-+-
   Reporter: |  Owner:  andrewfong
  andrewfong | Status:  assigned
   Type:  New|  Component:  Testing framework
  feature|   Severity:  Normal
  Milestone: |   Keywords:  cache testing flush
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  1
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * needs_docs:  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-updates@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] #11505: Django's TestCase should reset the cache

[Django]

#11505: Django's TestCase should reset the cache
-+-
   Reporter: |  Owner:  andrewfong
  andrewfong | Status:  assigned
   Type:  New|  Component:  Testing framework
  feature|   Severity:  Normal
  Milestone: |   Keywords:  cache testing flush
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * type:  Bug => New feature


-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11505: Django's TestCase should reset the cache

[Django]

#11505: Django's TestCase should reset the cache
-+-
   Reporter: |  Owner:  andrewfong
  andrewfong | Status:  assigned
   Type:  Bug|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  cache testing flush
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 #16401 is a duplicate and contains a much more thorough 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16401: Cache should be reset after each test without flushing

[Django]

#16401: Cache should be reset after each test without flushing
---+---
   Reporter:  jsdalton |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Testing framework
Version:  SVN  |   Severity:  Normal
 Resolution:  duplicate|   Keywords:  cache
   Triage Stage:  Unreviewed   |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by julien):

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


Comment:

 I believe this is a duplicate of #11505.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16383: More specific errors when resolving template Variables

[Django]

#16383: More specific errors when resolving template Variables
-+-
   Reporter:  maraujop   |  Owner:  maraujop
   Type:  New| Status:  new
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  _resolve_lookup,
 Resolution: |  resolve, template, variable,
   Triage Stage:  Accepted   |  exception
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 Overall, I like the idea of raising more specific errors.

 See also #6907 and #11421.

 It would be useful to discuss the details on django-developers.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16379: Override UserManager

[Django]

#16379: Override UserManager
-+-
   Reporter:  thibaultj  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.auth
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage: |  auth,user,manager,usermanager
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 This is more a usage question than a bug in Django, and apollo13 provided
 a solution.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16421: Serializing TimeField throws Attribute Error

[Django]

#16421: Serializing TimeField throws Attribute Error
-+-
   Reporter: |  Owner:  nobody
  silent1mezzo   | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
  worksforme |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 I can't reproduce. I've written a test case, which I'm attaching to this
 ticket. I later noticed that the serialization of `TimeField`s is already
 tested by the `serializers_regress` tests.

 Also, I believe you patch is wrong:
 - `val` is supposed to be a time object or `None`, not a string; if the
 function is called with a string, the error must be fixed in the caller,
 or further up the stack.
 - when `val` is a time object, the function returns a string; but with you
 patch, when `val` is a string, you're returning a time object. I don't
 understand this at all.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14094: Cannot define CharField with unlimited length

[Django]

#14094: Cannot define CharField with unlimited length
-+-
   Reporter:  millerdev  |  Owner:  nobody
   Type:  New| Status:  reopened
  feature|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Design decision needed


-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16133: cannot access documentation django.contrib.admin

[Django]

#16133: cannot access documentation django.contrib.admin
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Djangoproject.com
Version:  1.3|  Web site
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by jezdez):

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


-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16428: bad link for contrib.admin module documentation

[Django]

#16428: bad link for contrib.admin module documentation
--+---
   Reporter:  anonymous   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Documentation
Version:  1.3 |   Severity:  Normal
 Resolution:  duplicate   |   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 aaugustin):

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


Comment:

 Duplicate of #16419 and #16133. Please take 10 seconds to search the
 tracker before submitting a 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16428: bad link for contrib.admin module documentation

[Django]

#16428: bad link for contrib.admin module documentation
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 links to https://docs.djangoproject.com/en/1.3/ref/contrib/adm/

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16423: ModelForm._post_clean() does not respect Model.clean() ValidationErrors that possess a message_dict, rather than a list of messages

[Django]

#16423: ModelForm._post_clean() does not respect Model.clean() ValidationErrors
that possess a message_dict, rather than a list of messages
-+-
   Reporter:  robboyle   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  modelform,
 Resolution: |  validation
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * stage:  Unreviewed => Design decision needed
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

Re: [Django] #16184: GeoDjango inspectdb fails for PostGIS

[Django]

#16184: GeoDjango inspectdb fails for PostGIS
--+
   Reporter:  radim.blazek@…  |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  GIS
Version:  SVN |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  1
Needs documentation:  0   |Needs tests:  1
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
Changes (by aaugustin):

 * needs_tests:  0 => 1
 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10899: easier manipulation of sessions by test client

[Django]

#10899: easier manipulation of sessions by test client
---+---
   Reporter:  tallfred |  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Testing framework
Version:  SVN  |   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 gennad):

 * ui_ux:   => 0


Comment:

 Any progress on this guys?

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16366: contrib.auth.tests.context_processors.AuthContextProcessorTests.test_session_not_accessed fails when project loads other middleware that access the session.

[Django]

#16366: 
contrib.auth.tests.context_processors.AuthContextProcessorTests.test_session_not_accessed
fails when project loads other middleware that access the session.
+--
   Reporter:  jsdalton  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.auth
Version:  SVN   |   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 aaugustin):

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


Comment:

 The problem looks valid.

 To resolve it, I would probably try to override
 `settings.CONTEXT_PROCESSOR` in the test. Your patch takes a different
 route. I can't say which approach is the best.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16397: BaseCommand.execute() swallows ImportError, CommandError even when --traceback is used

[Django]

#16397: BaseCommand.execute() swallows ImportError, CommandError even when
--traceback is used
-+-
   Reporter:  charles@…  |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Could you provide a snippet to help us reproduce this problem?

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16386: Handle subclasses in signal dispatcher

[Django]

#16386: Handle subclasses in signal dispatcher
-+-
   Reporter:  patrys |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Design decision needed
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I agree that in most cases, inherited classes should behave like their
 parent classes with regard to signals, but the backwards incompatibility
 can't be simply ignored.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16368: Custom sites model overridden by contrib.sites.model.Site

[Django]

#16368: Custom sites model overridden by contrib.sites.model.Site
-+-
   Reporter: |  Owner:  nobody
  briehan.lombaard@… | Status:  new
   Type:  Bug|  Component:  contrib.sites
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 I still believe the root cause of the problem is that
 `django.contrib.sites` gets imported at some point. Can you figure out
 why? For instance, patch django/contrib/sites/models.py to raise an
 exception, and paste the traceback here.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16300: Strange problem when using "make singlehtml" on docs/

[Django]

#16300: Strange problem when using "make singlehtml" on docs/
--+---
   Reporter:  foxwhisper  |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Documentation
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 I confirm the problem.

 I don't believe many people use `singlehtml`, as the resulting file takes
 more than 6Mb...

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by jezdez):

 * ui_ux:   => 0


Comment:

 Hm, so I'm not a big fan of the `model_url` template tag, `{% model_url
 'admin:%s_%s_changelist' opts.app_label opts.module_name %}` doesn't look
 very legible to me, in fact it looks like Pseudo Python. Why not but that
 in the actual Python code instead?

 Other than that this looks pretty awesome.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16417: GeoAdmin support in StackedInline

[Django]

#16417: GeoAdmin support in StackedInline
+
   Reporter:  martin@…  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  GIS
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
Changes (by aaugustin):

 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12504: django.contrib.gis.admin.GeoModelAdmin ignores ModelAdmin.readonly_fields

[Django]

#12504: django.contrib.gis.admin.GeoModelAdmin ignores 
ModelAdmin.readonly_fields
-+-
   Reporter:  friism |  Owner:  jbronn
   Type:  Bug| Status:  assigned
  Milestone: |  Component:  GIS
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  geodjango admin
   Triage Stage:  Design |  readonly_fields
  decision needed|  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 #14643 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14643: Readonly fields in GeoDjango admins

[Django]

#14643: Readonly fields in GeoDjango admins
---+
   Reporter:  kris@…   |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  GIS
Version:  1.2  |   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 aaugustin):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => duplicate
 * easy:   => 0


Comment:

 #12504 already reported 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16408: Query result types not being converted with Spatialite

[Django]

#16408: Query result types not being converted with Spatialite
-+-
   Reporter:  Antonio|  Owner:  nobody
  Eugenio Burriel   | Status:  new
   Type:  Bug|  Component:  GIS
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I didn't compile spatialite to confirm the bug, but the report is
 sufficiently detailed to accept the ticket.

 This doesn't look related to #15040 and #15169.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16362: Ignore, rather than disallow, negative lookahead assertions

[Django]

#16362: Ignore, rather than disallow, negative lookahead assertions
-+-
   Reporter:  charles@…  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_docs:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Core (Other)
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Reading the comment on #2977 and duplicate tickets, I think we can accept
 this. I'm a bit surprised that the patch is so simple, but why not.

 Until now, lookahead/behind assertions were forbidden, so it can't be
 backwards incompatible.

 The docs probably needs updating.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16372: TransactionTestCase doesn't count skipped cases in test result.

[Django]

#16372: TransactionTestCase doesn't count skipped cases in test result.
+---
   Reporter:  zimnyx|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by aaugustin):

 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #8892: ForeignKey relation not saved as expected

[Django]

#8892: ForeignKey relation not saved as expected
-+-
   Reporter:  julien |  Owner:  blacklwhite
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.0|  (models, ORM)
 Resolution: |   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 aaugustin):

 * needs_tests:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 Please don't mark your own patches as RFC — see the contribution
 guidelines.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14270: ManyToMany manager classes should be cached

[Django]

#14270: ManyToMany manager classes should be cached
-+-
   Reporter:  Alex   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by mrmachine):

 This change has the added benefit of exposing the related instance on the
 related objects manager for reverse relationships, which makes it possible
 to implement a userland `update_or_create()`, for example, and other
 methods that might need access to the related instance to work correctly
 or efficiently.

 Thanks.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14270: ManyToMany manager classes should be cached

[Django]

#14270: ManyToMany manager classes should be cached
-+-
   Reporter:  Alex   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by mrmachine):

 * cc: real.human@… (added)
 * ui_ux:   => 0
 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.