Re: [Django] #16027: Include app_label in ContentType.__unicode__

[Django]

#16027: Include app_label in ContentType.__unicode__
-+-
 Reporter:  jakub|Owner:  Fandekasp
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:   |   Resolution:
  contrib.contenttypes   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by ptone):

 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * version:  1.3 => master
 * needs_tests:  1 => 0
 * stage:  Design decision needed => Accepted


Comment:

 I think the disambiguation should be moved to a {{{__repr__}}} method, see
 for example #19543

 The translated verbose_name should stay per #16803 for {{{__unicode__}}}
 and the debug friendly value can be in {{{__repr__}}}

 I'm unsure what use the original description is referring to with selects
 of FKs though. I've left the title unmodified, because the comment history
 wouldn't make sense.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #11495: Improvements to django.views.static.serve directory indexes

[Django]

#11495: Improvements to django.views.static.serve directory indexes
--+---
 Reporter:  SmileyChris   |Owner:  SmileyChris
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+---
Changes (by ptone):

 * version:  1.0 => master
 * type:  Cleanup/optimization => Bug
 * stage:  Design decision needed => Accepted


Comment:

 Why should views.static.serve consider static file finders? As documented
 it is just a directory based tool.

 I'd move to splitting this into two tickets. Accept this one which has the
 narrow scope of standardizing the sort order across OS versions for basic
 static.serve, I think this isn't too contentious.

 The issue of how to incorporate static-file finders into index display can
 be sorted out separately, with its rationale and design proposal.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20121: LogEntry.get_admin_url uses a hard-coded path format.

[Django]

#20121: LogEntry.get_admin_url uses a hard-coded path format.
---+--
 Reporter:  floppya|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by floppya):

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


Comment:

 Github topic branch: https://github.com/floppya/django/tree/ticket_20121

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20121: LogEntry.get_admin_url uses a hard-coded path format.

[Django]

#20121: LogEntry.get_admin_url uses a hard-coded path format.
---+
 Reporter:  floppya|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The LogEntry model from contrib.admin assumes that admin change path for a
 ContentType always follows the {{app_name}}/{{model_name}}/{{id}}/ format.
 This causes incorrect links to be generated for the admin change log in
 cases where the model's change url is customized.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18004: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

[Django]

#18004: Django should not use `force_unicode(..., errors='replace')` when 
parsing
POST data.
-+-
 Reporter:  mrmachine|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  post data unicode| Triage Stage:
  utf8 encode decode transaction |  Unreviewed
  aborted|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by mrmachine):

 Thanks for the feedback. I will attempt to log the request body as you
 suggested, and hopefully narrow down the cause of these errors.

 However, while I understand the need to force incoming data to unicode
 instead of carrying around who-knows-what-encoded bytestrings, I am still
 not sure we should be doing so with `errors='replace'`, even if that turns
 out to not be the cause of my particular problem. It seems like the
 current code is itself a work-around to a problem we don't know exists
 (and expect not to exist). A work-around that silently alters and corrupts
 incoming data.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13910: Add generator version of Template.render(Context)

[Django]

#13910: Add generator version of Template.render(Context)
-+
 Reporter:  rooney   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by mindsocket):

 I'm hoping to revisit this ticket, are there any updates or others working
 on it already? If not, any changes since 1.5 that might influence how it
 should be implemented?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20120: If DEBUG mode is True and ALLOWED_HOSTS is empty you should get a console warning

[Django]

#20120: If DEBUG mode is True and ALLOWED_HOSTS is empty you should get a 
console
warning
---+
 Reporter:  ty@…   |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  HTTP handling  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 In Django 1.5, since the ALLOWED_HOSTS is required, the dev server should
 print a warning to the console on every request while ALLOWED_HOSTS is
 empty. Otherwise, anyone who misses the new feature will deploy a site to
 production that doesn't work.

 Note: This is different than ticket #19946 and ticket #19866, as those
 both address the DEBUG=False case. I think having a warning while
 DEBUG=True will help people avoid running into the 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18088: Add a "supports_foreign_key" database feature to ease testing

[Django]

#18088: Add a "supports_foreign_key" database feature to ease testing
--+
 Reporter:  akaariai  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by akaariai):

 * stage:  Design decision needed => Accepted


Comment:

 I think that as long as we have databases that do not support foreign keys
 then supports_foreign_keys flag is needed. So, accepted. This could of
 course be closed if somebody were to remove all databases without foreign
 key support.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #4120: some admin Javascript cleanups

[Django]

#4120: some admin Javascript cleanups
-+-
 Reporter:  arvin|Owner:
 Type:   |  andrewjesaitis
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  javascript admin | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Looks good to me, I don't think any of these is subject to the backwards
 compatibility policy.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #4045: some admin Javascript fixes and cleanups

[Django]

#4045: some admin Javascript fixes and cleanups
+--
 Reporter:  arvin   |Owner:  andrewjesaitis
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  admin calendar  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+--
Changes (by andrewjesaitis):

 * owner:  nobody => andrewjesaitis
 * status:  new => assigned
 * cc: andrewjesaitis (added)


Comment:

 Picking this up, but ticket #4120 is a prerequisite, so I'll wait on doing
 anything until that ticket is resolved. However, it looks like most of the
 things that need to be fixed -- attaching events to the document instead
 of window, have occurred during the intervening years. The only remaining
 thing would be to "more properly" remove the events using core.js
 removeEvent function rather that just setting window.document.onclick =
 null.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #4120: some admin Javascript cleanups

[Django]

#4120: some admin Javascript cleanups
-+-
 Reporter:  arvin|Owner:
 Type:   |  andrewjesaitis
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  javascript admin | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by andrewjesaitis):

 * owner:  nobody => andrewjesaitis
 * status:  new => assigned
 * cc: andrewjesaitis (added)


Comment:

 This was quite an old ticket, but most of the original patch still
 applies. Consider it spring cleaning?!

 It is just js cleanup. No admin functionality. The most import change is
 that it removes a duplicative function from calendar.js, which is also
 found in core.js.

 The other two commits shuffle a couple functions into core.js. This ticket
 seemed to be a prerequisite to addressing #4045 which I will pick up once
 a call is made on this ticket.

 The only part of the original patch that didn't apply were the changes to
 js/admin/ordering.js, which appear to have been removed. This change
 looked to be removing a duplicative function as well.

 The associated pull request -- https://github.com/django/django/pull/948

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20112: UnicodeDecodeError with not UTF-8 charset database connection

[Django]

#20112: UnicodeDecodeError with not UTF-8 charset database connection
--+
 Reporter:  err   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.5
 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 kmtracey):

 It would be good if we could get an explanation of why original poster
 wants cp1251 encoding on the connection. It was a surprise to me that this
 would actually work -- I thought we forced the connection charset to utf-8
 ever since the merge of unicode branch. Rather it seems we just defaulted
 it to utf-8 and have been allowing override...I guess if this is the only
 place where that causes a problem, we could simply fix it. But I would not
 be surprised if there were other places where we assume utf-8 encoding on
 the connection. (Or I could be wrong about that, I was wrong about us
 forcing the connection charset to utf-8.)

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12306: Checkbox (label, field) ordering

[Django]

#12306: Checkbox (label, field) ordering
-+-
 Reporter:  EoghanM  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  1.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  label checkbox   | Triage Stage:  Design
  BooleanField   |  decision needed
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:   => wontfix


Comment:

 I'm going to close this for the same reasons as #13401.

 The long term solution is indeed something akin to floppyforms, but it
 hasn't been integrated yet due to performance concerns.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20112: UnicodeDecodeError with not UTF-8 charset database connection

[Django]

#20112: UnicodeDecodeError with not UTF-8 charset database connection
--+
 Reporter:  err   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.5
 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 claudep):

 If we allow specifying the charset with the OPTIONS key (as
 `get_connection_params` currently does for MySQL), we should probably also
 use that charset to decode `_last_executed`.

 Now I wouldn't be opposed to forcing `utf-8` with MySQL like we do with
 PostgreSQL, but I cannot measure all possible consequences. Maybe the
 original poster might explain why he choose to customized the charset,
 instead of keeping the default?

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

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

Re: [Django] #14057: Expose an interface for custom-escaping template content

[Django]

#14057: Expose an interface for custom-escaping template content
-+-
 Reporter:  steveire |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 I feel that this is going to add a significant amount of code to Django
 that won't be used very much in practice.

 Since escaping is critical to prevent XSS attacks, I'd really prefer to
 keep in as simple as possible.

 I appreciate the amount of effort that went into the patches, but as I
 read this ticket for the first time today, I think it should be closed as
 wontfix.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13984: template.loader.select_template should return template_name as well.

[Django]

#13984: template.loader.select_template should return template_name as well.
-+-
 Reporter:  DaNmarner|Owner:
 Type:  New feature  |  JoshStegmaier
Component:  Template system  |   Status:  closed
 Severity:  Normal   |  Version:  master
 Keywords:   |   Resolution:  duplicate
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):

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


Comment:

 The pattern used to change the result type isn't elegant...

 It seems to me that #16096 provides the same information with a better
 API.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18004: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

[Django]

#18004: Django should not use `force_unicode(..., errors='replace')` when 
parsing
POST data.
-+-
 Reporter:  mrmachine|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  post data unicode| Triage Stage:
  utf8 encode decode transaction |  Unreviewed
  aborted|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by kmtracey):

 In fact one way to trigger this error is to pass the invalid bytestring in
 as a raw query, for example:

 {{{
 >>> badq = 'SELECT * from "auth_user" WHERE "auth_user"."username" =
 \'\xea\x20\x20\''
 >>> from django.db import connection
 >>> cursor = connection.cursor()
 >>> cursor.execute(badq)
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/kmtracey/.virtualenvs/abc/local/lib/python2.7/site-
 packages/django/db/backends/util.py", line 34, in execute
 return self.cursor.execute(sql, params)
   File "/home/kmtracey/.virtualenvs/abc/local/lib/python2.7/site-
 packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in
 execute
 return self.cursor.execute(query, args)
 DatabaseError: invalid byte sequence for encoding "UTF8": 0xea2020
 }}}

 If instead you take the bytestring, decode it with errors=replace, and re-
 encode it as utf-8, the DB is fine with it (once you clear the error state
 on the transaction):

 {{{
 >>> cursor.execute(badq.decode('utf-8', errors='replace').encode('utf-8'))
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/kmtracey/.virtualenvs/abc/local/lib/python2.7/site-
 packages/django/db/backends/util.py", line 34, in execute
 return self.cursor.execute(sql, params)
   File "/home/kmtracey/.virtualenvs/abc/local/lib/python2.7/site-
 packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in
 execute
 return self.cursor.execute(query, args)
 DatabaseError: current transaction is aborted, commands ignored until end
 of transaction block

 >>> connection._rollback()
 >>> cursor.execute(badq.decode('utf-8', errors='replace').encode('utf-8'))
 >>>
 }}}

 That's essentially what the errors=replace on decoding post data is doing:
 ensuring that internally we work with unicode that can be encoded in utf-8
 when it needs to be rather than internally carrying around who-knows-what-
 encoded bytestrings that may or may not be safe to pass on to other
 subsystems. How the bytestring 0xea2020 is getting stuffed in the postgres
 connection is the question that needs to be answered first for this ticket
 -- I'm not at all convinced that is being caused by errors=replace on
 decode of post data.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18400: Unexpected {% if %} behavior

[Django]

#18400: Unexpected {% if %} behavior
--+
 Reporter:  apollo13  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Template system   |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  template, if, length  | 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):

 * stage:  Design decision needed => Accepted


Comment:

 I don't know what the right solution is, but it's definitely 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18651: Assignment tags should allow optional assignments

[Django]

#18651: Assignment tags should allow optional assignments
-+
 Reporter:  mitar|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

 * stage:  Design decision needed => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20117: Flatpages test failure in a project with language different to 'en'

[Django]

#20117: Flatpages test failure in a project with language different to 'en'
-+-
 Reporter:  matiasb  |Owner:  matiasb
 Type:  Bug  |   Status:  assigned
Component:  contrib.flatpages|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by grampajoe):

 * stage:  Accepted => Ready for checkin


Comment:

 Moving to RFC. It's a really small fix, and I don't think there's anything
 left to be done.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13401: Forms RadioInput produces invalid HTML

[Django]

#13401: Forms RadioInput produces invalid HTML
-+-
 Reporter:  pajatso  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 This change is backwards-incompatible. The link in comment 5 provides a
 workaround.

 The long term solution is a template-based form rendering system, which
 has been considered for a long time but only exists as an external app
 (floppyforms) at this time.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18004: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

[Django]

#18004: Django should not use `force_unicode(..., errors='replace')` when 
parsing
POST data.
-+-
 Reporter:  mrmachine|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  post data unicode| Triage Stage:
  utf8 encode decode transaction |  Unreviewed
  aborted|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kmtracey):

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


Comment:

 Indeed, we need some way to recreate and understand this issue before
 attempting any fix. I'm not at all sure, based on this description, that
 errors=replace is causing this. The "invalid byte sequence" error message
 noted in the description identifies the invalid byte sequence as 0xea2020.
 That is nothing at all like the expected utf-8 encoding of the unicode
 replacement character (which would be 0xefbfbd). The whole point of
 errors=replace is to take a bytestring we cannot figure out how to
 correctly decode and turn it into a valid unicode string, possibly
 containing the unicode replacement character if in fact the input
 bytestring is "broken". The unicode replacement character itself is a
 perfectly valid unicode character with a utf-8 encoding: for it to trigger
 a database error would indicate a bug in the database.

 The question is how the byte string 0xea2020 got stuffed onto the postgres
 connection -- this, as logged, is not a valid utf-8 byte sequence and
 therefore should never have been sent on the DB connection from Django.
 But without some way for us to trigger that happening I don't see how we
 can identify how it happened. Therefore closing this needsinfo since I
 don't see we can do anything to address this problem without a recreation
 scenario.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12651: AutoSlugField, that can recreate unique slugs during saving.

[Django]

#12651: AutoSlugField, that can recreate unique slugs during saving.
-+-
 Reporter:  Ciantic  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 The concept described in this ticket was accepted, the discussion is now
 about the implementation.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14586: Make interpolate JS function not require the named parameter.

[Django]

#14586: Make interpolate JS function not require the named parameter.
--+
 Reporter:  aminland  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Internationalization  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * needs_docs:  0 => 1
 * stage:  Design decision needed => Accepted


Comment:

 My JavaScript-fu is weak, but I'll try to move this forward...

 Apparently, JavaScript silently drop superfluous arguments, making this
 backwards-compatible. Julien, which backwards-incompatibilities did you
 have in mind?

 It still requires documenting the change.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16284: djangojs uses en as fallback language rather than projects language code

[Django]

#16284: djangojs uses en as fallback language rather than projects language code
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Internationalization  |  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:  Design decision needed => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14825: LocaleMiddleware should store language preferences if possible

[Django]

#14825: LocaleMiddleware should store language preferences if possible
--+
 Reporter:  vzima |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 This is a reasonable short-term workaround. #15902 will certainly take
 more time.

 The patch is a good starting point, but it needs tests. Also, please use
 `in` rather than `has_key`, and consider using `setdefault` where
 possible.

 I view this as a bugfix more than a new feature, but a line in the release
 notes can't hurt.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19527: bulk_create() can set the primary key

[Django]

#19527: bulk_create() can set the primary key
-+-
 Reporter:  Tuttle   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 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 aaugustin):

 * stage:  Design decision needed => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18004: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

[Django]

#18004: Django should not use `force_unicode(..., errors='replace')` when 
parsing
POST data.
-+-
 Reporter:  mrmachine|Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  post data unicode| Triage Stage:
  utf8 encode decode transaction |  Unreviewed
  aborted|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 (I moved the ticket back to unreviwed because there isn't enough info yet
 to accept it, even though it was opened long ago.)

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18004: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

[Django]

#18004: Django should not use `force_unicode(..., errors='replace')` when 
parsing
POST data.
-+-
 Reporter:  mrmachine|Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  post data unicode| Triage Stage:
  utf8 encode decode transaction |  Unreviewed
  aborted|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Unreviewed


Comment:

 Yes, I have strong objections to your proposal: I'm not going to add a
 workaround for a problem that we haven't identified yet.

 All of the above is vague, and we still don't know how to trigger this
 error.

 

 I did the research, and RFC 1867 says that file names must be encoded:

 > The client application should make best
 > effort to supply the file name; if the file name of the client's
 > operating system is not in US-ASCII, the file name might be
 > approximated or encoded using the method of RFC 1522.


 This is repeated in section 5.11 - Non-ASCII field names:

 > Note that mime headers are generally required to consist only of 7-
 > bit data in the US-ASCII character set. Hence field names should be
 > encoded according to the prescriptions of RFC 1522 if they contain
 > characters outside of that set. In HTML 2.0, the default character
 > set is ISO-8859-1, but non-ASCII characters in field names should be
 > encoded.


 RFC 1522 describes mime-encoding, and this encoding explicitly includes
 the charset.

 

 Note that you're the only person to have ever hit this problem; for all I
 know this could be a bug in your code. The only way to be sure is to log a
 request, and figure out why Django can't parse it.

 Here's what I would suggest: in the problematic view, catch the
 `DatabaseError`, and when it occurs, dump `request.body` in a file in
 binary mode. Once we have this file, we can figure out why Django ends up
 with invalid utf8 data.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20112: UnicodeDecodeError with not UTF-8 charset database connection

[Django]

#20112: UnicodeDecodeError with not UTF-8 charset database connection
--+
 Reporter:  err   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.5
 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):

 If the database handles the conversion, indeed, this isn't necessary (I
 wasn't sure).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20112: UnicodeDecodeError with not UTF-8 charset database connection

[Django]

#20112: UnicodeDecodeError with not UTF-8 charset database connection
--+
 Reporter:  err   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.5
 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 kmtracey):

 No...doesn't matter what the database/table/column charset is, it's fine
 for data on the connection to flow as utf-8, since utf-8 can encode any
 values for any other supported charset.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #3254: [patch] experimental fulltext search support for postgres, oracle and mssql

[Django]

#3254: [patch] experimental fulltext search support for postgres, oracle and 
mssql
-+-
 Reporter:  Ronny Pfannschmidt   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle fulltext  |  Needs documentation:  1
  search |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by niwi):

 * cc: niwi@… (added)


Comment:

 If in the future, are going to implement support for postgresql text
 search, you can have this as a reference implementation:
 https://github.com/niwibe/djorm-ext-
 pgfulltext/blob/master/djorm_pgfulltext/models.py

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

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

Re: [Django] #20112: UnicodeDecodeError with not UTF-8 charset database connection

[Django]

#20112: UnicodeDecodeError with not UTF-8 charset database connection
--+
 Reporter:  err   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.5
 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):

 Isn't this necessary for databases not created by Django (unmanaged
 models)?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17781: Django cache middleware does not set "Age" header as described in rfc2616

[Django]

#17781: Django cache middleware does not set "Age" header as described in 
rfc2616
-+-
 Reporter:  corentin.chary@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 No one besides the reporter expressed interest for this feature, there's
 no patch, and the description admits it's a lot of work with (as far as I
 can tell) mostly theoretical advantages.

 I'm going to close the ticket, please make your case on django-developers
 (preferrably with a patch) if you want this feature request to be
 implemented.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15574: IndexError: list index out of range caused by inline formsets

[Django]

#15574: IndexError: list index out of range caused by inline formsets
+
 Reporter:  poswald |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  inline formset  | 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:  Design decision needed => Accepted


Comment:

 This is obviously a bug, moving back to 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16149: Allow disabling choices in a

[Django]

#16149: Allow disabling choices in a 
-+
 Reporter:  scjody   |Owner:  scjody
 Type:  New feature  |   Status:  assigned
Component:  Forms|  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:  Design decision needed => Accepted


Comment:

 The discussion raised several concerns which must be addressed, but no
 one's against the idea.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 15f12d: Fix minor typo in tutorial

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 15f12d4181355604efa7b429fc3bcbae08d27f40
  
https://github.com/django/django/commit/15f12d4181355604efa7b429fc3bcbae08d27f40
  Author: Christos Kontas 
  Date:   2013-03-23 (Sat, 23 Mar 2013)

  Changed paths:
M docs/intro/tutorial01.txt

  Log Message:
  ---
  Fix minor typo in tutorial


  Commit: d384878cc1a73047e79d1a8c4bd924ad39ef8899
  
https://github.com/django/django/commit/d384878cc1a73047e79d1a8c4bd924ad39ef8899
  Author: Tim Graham 
  Date:   2013-03-23 (Sat, 23 Mar 2013)

  Changed paths:
M docs/intro/tutorial01.txt

  Log Message:
  ---
  Merge pull request #941 from xakon/master

Small typo error in tutorial


Compare: https://github.com/django/django/compare/f670cce9f539...d384878cc1a7

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

Re: [Django] #18088: Add a "supports_foreign_key" database feature to ease testing

[Django]

#18088: Add a "supports_foreign_key" database feature to ease testing
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Testing framework|   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Can we make a decision? Anssi, it's your call.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12089: test client fails to collect sub-contexts

[Django]

#12089: test client fails to collect sub-contexts
-+-
 Reporter:  akaihola |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  template context | Triage Stage:  Accepted
  TestClient |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 Accepting based on Russell's comments. The approach of the current patch
 is rejected, a backwards-compatible approach such as the one proposed in
 comment 12 must be found.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20112: UnicodeDecodeError with not UTF-8 charset database connection

[Django]

#20112: UnicodeDecodeError with not UTF-8 charset database connection
--+
 Reporter:  err   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.5
 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 kmtracey):

 I'm not sure we want to officially support setting the connection charset
 to anything other than utf-8 (or on MySQL the new fancy "real" utf-8 that
 actually supports more than 3-byte encodings, once we figure out how to do
 that). Ever since the unicode branch landed years ago Django has been by
 default setting the connection charset to utf-8...what's the use case for
 setting the connection charset to something more restrictive than utf-8?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18265: request.user cached value does not track request.session change

[Django]

#18265: request.user cached value does not track request.session change
-+-
 Reporter:  Tuttle   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 You can write to django-developers and see if other people would be
 interested by this change.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20117: Flatpages test failure in a project with language different to 'en'

[Django]

#20117: Flatpages test failure in a project with language different to 'en'
---+
 Reporter:  matiasb|Owner:  matiasb
 Type:  Bug|   Status:  assigned
Component:  contrib.flatpages  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by grampajoe):

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


Comment:

 Confirmed the failure, and confirmed tests pass with the 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18265: request.user cached value does not track request.session change

[Django]

#18265: request.user cached value does not track request.session change
-+-
 Reporter:  Tuttle   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Tuttle):

 Thank you for the answer. I try to understand your position.

 In my humble opinion every piece of code maintaining any cached value
 should be clever enough to track the cached value validity. It looks like
 it's currently the only thing standing in the way of supporting
 `request.session` replacing (which IMO is not too shameful technique by
 itself).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20119: typo error "in it's definition" > "in its definition"

[Django]

#20119: typo error "in it's definition" > "in its definition"
---+
 Reporter:  vinyll |  Owner:  nobody
 Type:  Uncategorized  | Status:  closed
Component:  Documentation  |Version:  1.5
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+

Comment (by Claude Paroz ):

 In [changeset:"8772f9b4a6fd424c404cc1945ec57ddc767397ef"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8772f9b4a6fd424c404cc1945ec57ddc767397ef"
 [1.5.x] Fixed #20119 -- Fixed typo in auth docs

 Thanks vinyll for the report.
 Backport of f670cce9f53 from master.
 }}}

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

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

[django/django] 8772f9: [1.5.x] Fixed #20119 -- Fixed typo in auth docs

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 8772f9b4a6fd424c404cc1945ec57ddc767397ef
  
https://github.com/django/django/commit/8772f9b4a6fd424c404cc1945ec57ddc767397ef
  Author: Claude Paroz 
  Date:   2013-03-23 (Sat, 23 Mar 2013)

  Changed paths:
M docs/topics/auth/customizing.txt

  Log Message:
  ---
  [1.5.x] Fixed #20119 -- Fixed typo in auth docs

Thanks vinyll for the report.
Backport of f670cce9f53 from master.



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

Re: [Django] #20119: typo error "in it's definition" > "in its definition"

[Django]

#20119: typo error "in it's definition" > "in its definition"
---+
 Reporter:  vinyll |  Owner:  nobody
 Type:  Uncategorized  | Status:  closed
Component:  Documentation  |Version:  1.5
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"f670cce9f53984277a8ca3b191f162bebab19ea9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f670cce9f53984277a8ca3b191f162bebab19ea9"
 Fixed #20119 -- Fixed typo in auth docs

 Thanks vinyll for the report.
 }}}

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

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

[django/django] f670cc: Fixed #20119 -- Fixed typo in auth docs

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f670cce9f53984277a8ca3b191f162bebab19ea9
  
https://github.com/django/django/commit/f670cce9f53984277a8ca3b191f162bebab19ea9
  Author: Claude Paroz 
  Date:   2013-03-23 (Sat, 23 Mar 2013)

  Changed paths:
M docs/topics/auth/customizing.txt

  Log Message:
  ---
  Fixed #20119 -- Fixed typo in auth docs

Thanks vinyll for the report.



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

Re: [Django] #12846: [PATCH] Support for compiled pyc files

[Django]

#12846: [PATCH] Support for compiled pyc files
--+
 Reporter:  dap   |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 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 claudep):

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


Comment:

 These sorts of requests have been won't fixed in other tickets (see
 #14952). Closing.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12752: validators should allow check against empty to be customized

[Django]

#12752: validators should allow check against empty to be customized
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.2-alpha
  (models, ORM)  |   Resolution:
 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|
-+-

Comment (by claudep):

 From [22be90dd171dee], `empty_values` is now a field attribute, and is
 customizable.
 Is this sufficient to resolve your use case, or do you really need a
 custom method to achieve what you want?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9388: Year navigation in admin's date widgets' calendar

[Django]

#9388: Year navigation in admin's date widgets' calendar
-+-
 Reporter:  framos   |Owner:  versae
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin calendar year  | Triage Stage:  Accepted
  previous next widget ui|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 This sounds useful, I don't know which design decision was expected.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6412: [patch] Check for file permissions for proper error messages

[Django]

#6412: [patch] Check for file permissions for proper error messages
--+
 Reporter:  mbeachy@… |Owner:  MarkusH
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by MarkusH):

 * cc: MarkusH (added)
 * needs_better_patch:  1 => 0


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

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

Re: [Django] #6412: [patch] Check for file permissions for proper error messages

[Django]

#6412: [patch] Check for file permissions for proper error messages
--+
 Reporter:  mbeachy@… |Owner:  MarkusH
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by MarkusH):

 I updated the patch to use the `NamedTemporaryFile` for the former two
 tests. The latter works on a directory, hence there is no way to
 automatically remove that directory.

 https://github.com/django/django/pull/947

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20119: typo error "in it's definition" > "in its definition"

[Django]

#20119: typo error "in it's definition" > "in its definition"
---+
 Reporter:  vinyll |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 
https://docs.djangoproject.com/en/dev/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD

 It should be written "in its definition"

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14874: remove js-confirms on changelist

[Django]

#14874: remove js-confirms on changelist
-+-
 Reporter:  sehmaschine@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  1
-+-
Changes (by jezdez):

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


Comment:

 apollo13 and me have discussed this at the Django sprint in Berlin and
 don't see enough reasons to remove this user facing feature.
 Inconsistencies in the code doesn't mean we should remove it completely,
 but rather consider fixing the other places to apply the same.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20118: Upgrade from Django 1.4 to 1.5 creates South migration

[Django]

#20118: Upgrade from Django 1.4 to 1.5 creates South migration
---+
 Reporter:  coolRR |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I noticed that South suddenly wants to create a new schema migration. I'm
 guessing that this is due to my upgrade from Django 1.4 to Django 1.5.

 The migrations added `on_delete=models.SET_NULL`, I believe.

 I suggest that this become part of the upgrade guide. Better have South
 create and apply those migrations as quickly as possible after the
 upgrade, instead of discovering it some time afterwards.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20073: Provide API for creating User objects in tests

[Django]

#20073: Provide API for creating User objects in tests
+
 Reporter:  jacek.tomek@…   |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  contrib.auth|  Version:  1.5
 Severity:  Normal  |   Resolution:
 Keywords:  1.5 user tests  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by jacek.tomek@…):

 Ok, I see. So I would like not to mock the user - in order to test if app
 really works in project with some custom user model.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9055: Percent sign in SQL statement behaves different with CursorDebugWrapper

[Django]

#9055: Percent sign in SQL statement behaves different with CursorDebugWrapper
-+-
 Reporter:  guettli  |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"76aecfbc4b49f5ab0613cccff1df6fab03253fab"]:
 {{{
 #!CommitTicketReference repository=""
 revision="76aecfbc4b49f5ab0613cccff1df6fab03253fab"
 Fixed #9055 -- Standardized behaviour of parameter escaping in db cursors

 Previously, depending on the database backend or the cursor type,
 you'd need to double the percent signs in the query before passing
 it to cursor.execute. Now cursor.execute consistently need percent
 doubling whenever params argument is not None (placeholder substitution
 will happen).
 Thanks Thomas Güttler for the report and Walter Doekes for his work
 on the 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 76aecf: Fixed #9055 -- Standardized behaviour of parameter...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 76aecfbc4b49f5ab0613cccff1df6fab03253fab
  
https://github.com/django/django/commit/76aecfbc4b49f5ab0613cccff1df6fab03253fab
  Author: Claude Paroz 
  Date:   2013-03-23 (Sat, 23 Mar 2013)

  Changed paths:
M django/db/backends/__init__.py
M django/db/backends/mysql/base.py
M django/db/backends/oracle/base.py
M django/db/backends/sqlite3/base.py
M django/db/backends/util.py
M docs/topics/db/sql.txt
M tests/backends/tests.py

  Log Message:
  ---
  Fixed #9055 -- Standardized behaviour of parameter escaping in db cursors

Previously, depending on the database backend or the cursor type,
you'd need to double the percent signs in the query before passing
it to cursor.execute. Now cursor.execute consistently need percent
doubling whenever params argument is not None (placeholder substitution
will happen).
Thanks Thomas Güttler for the report and Walter Doekes for his work
on the patch.



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

Re: [Django] #6412: [patch] Check for file permissions for proper error messages

[Django]

#6412: [patch] Check for file permissions for proper error messages
--+
 Reporter:  mbeachy@… |Owner:  MarkusH
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   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 MarkusH):

 * owner:  dokterbob => MarkusH


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16089: Adding/Removing admin Inlines on the fly

[Django]

#16089: Adding/Removing admin Inlines on the fly
-+-
 Reporter:  sheep2   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by apollo13):

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


Comment:

 I think this was fixed in c2e19e26bc33d34eff57079bd1a6838ff64d9e81, some
 example code (should work, untested):
 {{{
 def get_inline_instances(self, request, obj=None):
   if obj is None:
 return []
   return super(Bla, self).get_inline_instances(request, obj)
 }}}
 If there are still issues please reopen the ticket and provide more
 information.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6412: [patch] Check for file permissions for proper error messages

[Django]

#6412: [patch] Check for file permissions for proper error messages
--+-
 Reporter:  mbeachy@… |Owner:  dokterbob
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   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 jezdez):

 * needs_better_patch:  0 => 1


Comment:

 The patch looks almost good, although using a `NamedTemporaryFile` would
 be 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20073: Provide API for creating User objects in tests

[Django]

#20073: Provide API for creating User objects in tests
+
 Reporter:  jacek.tomek@…   |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  contrib.auth|  Version:  1.5
 Severity:  Normal  |   Resolution:
 Keywords:  1.5 user tests  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by anonymous):

 As far as I understand, mocking and creating a User instance are 2
 different things. For mocking you could just use sth like python mock
 library. You wouldn't need an actual User instance which is really what
 you are trying to avoid by mocking the object.

 Am I being clear enough? By mocking the user you can avoid depending on
 any User class and just test against the expected API.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13972: Field initial value callable should take a request object as an argument

[Django]

#13972: Field initial value callable should take a request object as an argument
-+-
 Reporter:  mitar|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  1.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by apollo13):

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


Comment:

 Jupp, wontfix, forms shouldn't have to know about the request.

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

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

Re: [Django] #17413: Serialization or getting non-HTML version of form errors is not easy

[Django]

#17413: Serialization or getting non-HTML version of form errors is not easy
-+-
 Reporter:  kmike|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  form errors  | Triage Stage:  Accepted
  serialization  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by apollo13):

 * stage:  Design decision needed => Accepted


Comment:

 Would be nice to have.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18272: ModelChoiceField's queryset attribute persists between two form instances

[Django]

#18272: ModelChoiceField's queryset attribute persists between two form 
instances
-+-
 Reporter:  bmispelon|Owner:  Spark23
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  modelchoicefield | Triage Stage:  Design
  deepcopy   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by apollo13):

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


Comment:

 Closing as wontfix as suggested by Preston.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19126: runserver versus model validation

[Django]

#19126: runserver versus model validation
-+-
 Reporter:  direvus  |Owner:  nobody
 Type:  Bug  |   Status:  new
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|
-+-

Comment (by direvus):

 Replying to [comment:8 aaugustin]:
 > Can you bring this up on django-developers? If other users are affected
 by this issue, their feedback will be interesting.

 No problem -- I have posted my message but it hasn't shown up on the list
 yet, I suppose it's waiting for moderation.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20117: Flatpages test failure in a project with language different to 'en'

[Django]

#20117: Flatpages test failure in a project with language different to 'en'
---+--
 Reporter:  matiasb|Owner:  matiasb
 Type:  Bug|   Status:  assigned
Component:  contrib.flatpages  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by matiasb):

 * status:  new => assigned
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Created pull request fixing the test:
 https://github.com/django/django/pull/946
 Tests passing with SQLite.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6412: [patch] Check for file permissions for proper error messages

[Django]

#6412: [patch] Check for file permissions for proper error messages
--+-
 Reporter:  mbeachy@… |Owner:  dokterbob
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+-
Changes (by MarkusH):

 * needs_tests:  1 => 0


Comment:

 I tested the linked pull request
 (https://github.com/django/django/pull/838) on Python 2.7.3 and Python
 3.3.0 with Linux. The tests pass for both versions.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13181: ChoiceField.choices need to accept callable, not only list or tuple

[Django]

#13181: ChoiceField.choices need to accept callable, not only list or tuple
--+
 Reporter:  mariarchi |Owner:
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  1.2-beta
 Severity:  Normal|   Resolution:
 Keywords:  ChoiceField, choices  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by apollo13):

 * stage:  Design decision needed => Accepted


Comment:

 Moving back to "Accepted" since the ticket per se is accepted and we are
 dropping DDN.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20117: Flatpages test failure in a project with language different to 'en'

[Django]

#20117: Flatpages test failure in a project with language different to 'en'
---+-
 Reporter:  matiasb|  Owner:  matiasb
 Type:  Bug| Status:  new
Component:  contrib.flatpages  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 Having a project with contrib.flatpages in INSTALLED_APPS and a
 LANGUAGE_CODE setting different to 'en' (for example, LANGUAGE_CODE = 'fr-
 fr'), running flatpages tests I'm getting a failing test:

 {{{
 $ ./manage.py test flatpages
 Creating test database for alias 'default'...
 .F...
 ==
 FAIL: test_flatpage_admin_form_url_uniqueness_validation
 (django.contrib.flatpages.tests.forms.FlatpageAdminFormTests)
 The flatpage admin form correctly enforces url uniqueness among flatpages
 of the same site
 --
 Traceback (most recent call last):
   File
 
"/home/matiasb/projects/django/dev/django/django/contrib/flatpages/tests/forms.py",
 line 65, in test_flatpage_admin_form_url_uniqueness_validation
 {'__all__': ['Flatpage with url /myflatpage1/ already exists for site
 example.com']})
 AssertionError: {u'__all__': [u"La page statique \xe0 l'URL /myflatpage1/
 existe d\xe9j\xe0 pour le site example.com"]} != {u'__all__': [u'Flatpage
 with url /myflatpage1/ already exists for site example.com']}

 --
 Ran 49 tests in 4.370s

 FAILED (failures=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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15215: API for simpler (permission or any) checks for generic view classes

[Django]

#15215: API for simpler (permission or any) checks for generic view classes
---+
 Reporter:  Ciantic|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Generic views  |  Version:  master
 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 apollo13):

 * stage:  Design decision needed => Accepted


Comment:

 Accepting the ticket based on the fact that this stuff should be easier.
 Not sure that the suggested approach is the best way though.

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

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

Re: [Django] #19624: Generic Detail View context contains object twice.

[Django]

#19624: Generic Detail View context contains object twice.
-+-
 Reporter:  mail@…   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:
Component:  Generic views|  1.5-beta-1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  generic view | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by apollo13):

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


Comment:

 Yes, this is on purpose, "object" is useful for real generic code, but one
 often wants to use a more fitting name. I don't see the duplication as an
 issue.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14760: Admin inlines with file/image field fails to save_as

[Django]

#14760: Admin inlines with file/image field fails to save_as
---+
 Reporter:  paulos |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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 apollo13):

 * stage:  Design decision needed => Accepted


Comment:

 Moving out of DDN since it is a valid issue, the safer solution would be
 to copy the file if the storage backends would allow 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20059: Test failure in humanize app for some languages

[Django]

#20059: Test failure in humanize app for some languages
--+
 Reporter:  orangain@…|Owner:  matiasb
 Type:  Bug   |   Status:  assigned
Component:  contrib.humanize  |  Version:  1.5
 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 matiasb):

 * has_patch:  0 => 1


Comment:

 Created pull request: https://github.com/django/django/pull/945
 All tests passing with SQLite.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9055: Percent sign in SQL statement behaves different with CursorDebugWrapper

[Django]

#9055: Percent sign in SQL statement behaves different with CursorDebugWrapper
-+-
 Reporter:  guettli  |Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * owner:  nobody => claudep
 * status:  new => assigned
 * stage:  Accepted => Ready for checkin


Comment:

 I'm going to kill this one...

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

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

Re: [Django] #18672: Model hooks for custom sql on syncdb and flush

[Django]

#18672: Model hooks for custom sql on syncdb and flush
-+-
 Reporter:  niwi |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * stage:  Design decision needed => Accepted


Comment:

 I do think having a better way to install custom SQL is needed. For
 example if you need some views for your database the current ways of
 running the SQL is really lacking.

 However the right solution is likely to wait for schema migrations, they
 could offer a much better solution than what hooks can offer. I am marking
 this as accepted in the meaning that a better way for installing custom
 SQL is needed. If the model hooks are the right way needs still more
 discussion.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20116: ValidationError in form wizard with formsets

[Django]

#20116: ValidationError in form wizard with formsets
---+--
 Reporter:  foonicorn  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.formtools  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords:  formset, wizard| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by steph):

 No, I think this is another problem, because #19189 is about re-validating
 things an sending a user back to a form. This ticket is about an finished
 wizard (done was called and response was rendered) and the user clicks the
 back button of the browser.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17878: Recursive order_with_respect_to

[Django]

#17878: Recursive order_with_respect_to
-+-
 Reporter:  eric@…   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 This feature sounds quite complicated to implement and there isn't much
 interest.

 I suggest making your case on django-developers; a patch (at least a proof
 of concept) would help.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16735: Queryset values should be aliasable

[Django]

#16735: Queryset values should be aliasable
-+-
 Reporter:  alex.latchford@… |Owner:  nate_b
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  queryset, alias, |  Needs documentation:  0
  values |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 Unless I missed something, there isn't any objection to adding this
 feature to `values`.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19373: Windows file locking requires pywin32

[Django]

#19373: Windows file locking requires pywin32
--+
 Reporter:  techtonik |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  File uploads/storage  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by apollo13):

 * stage:  Design decision needed => Accepted


Comment:

 We should at least document the gain of an installed PyWin32.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19371: django.forms.DateTimeField does not properly handle aware datetimes as inputs

[Django]

#19371: django.forms.DateTimeField does not properly handle aware datetimes as
inputs
-+-
 Reporter:  delinhabit   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  forms,   | Triage Stage:  Accepted
  DateTimeField, timezones   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 The forms fields aren't designed to handle aware datetimes. The input
 should be rejected as invalid, because it doesn't match any of
 `DATETIME_INPUT_FORMATS`. I don't why it's accepted without an error.

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

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

Re: [Django] #19580: Unify reverse foreign key and m2m querying behavior

[Django]

#19580: Unify reverse foreign key and m2m querying behavior
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 Yes, it's better to error loudly on operations that can't work because the
 database didn't generate an id for the object yet.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20112: UnicodeDecodeError with not UTF-8 charset database connection

[Django]

#20112: UnicodeDecodeError with not UTF-8 charset database connection
--+
 Reporter:  err   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.5
 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 claudep):

 For PostgreSQL, I don't think this is an issue, as we are hard-coding
 `UTF8` in `init_connection_state`.

 For MySQL, I'd rather use the same charset we are passing when initing the
 connection (`self.connection.get_connection_params()['charset']`). This
 might be less dependent on MysqlDB implementation.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19117: Database and memcached connections break after fork.

[Django]

#19117: Database and memcached connections break after fork.
-+-
 Reporter:  sebastian_noack  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 A quick workaround is to close the database and cache connection before
 forking; they'll be automatically reopened on the first subsequent access.

 I'm not eager to add this code, because it's non-trivial, impossible to
 test, and rarely useful...

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18242: Making widget type accessible in template

[Django]

#18242: Making widget type accessible in template
-+-
 Reporter:  selwin   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 It's already possible to apply arbitrary CSS classes to widgets:
 
https://docs.djangoproject.com/en/stable/ref/forms/widgets/#django.forms.Widget.attrs

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13917: Multiple popup window feature of related objects popup through id_to_windowname

[Django]

#13917: Multiple popup window feature of related objects popup through
id_to_windowname
---+
 Reporter:  davidcooper|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.2
 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:  1
---+
Changes (by aaugustin):

 * stage:  Design decision needed => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15711: Abstract model managers should return subclass instances

[Django]

#15711: Abstract model managers should return subclass instances
-+-
 Reporter:  jdunck   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  pony |  decision needed
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:   => wontfix


Comment:

 On one hand, this is a cool feature, and on the other hand, it's a partial
 implementation of STI. It has been implemented externally, see
 django_polymorphic.

 My gut feeling is that a partial implementation will be buggy in many edge
 cases. To include something like this in core, we must be confident that
 we can handle all cases correctly, and I don't think we have enough info
 yet.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17186: Inverted F expression (negation)

[Django]

#17186: Inverted F expression (negation)
-+-
 Reporter:  niwi |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 This feature shouldn't be expected to give meaningful results on anything
 other than a boolean value.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16112: Excluding some value in a related model excludes objects without that model

[Django]

#16112: Excluding some value in a related model excludes objects without that 
model
-+-
 Reporter:  adehnert |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
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:   => fixed


Comment:

 (I was wrong in my first comment -- in SQL `NULL != ` evaluates
 to `False`.)

 Anyway, I just tried your example, and Django now consistently uses LEFT
 OUTER JOIN. This was fixed, maybe at the same time as #14876.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18959: Error message for table names > 50 characters is very poor.

[Django]

#18959: Error message for table names > 50 characters is very poor.
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  permission| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * type:  Uncategorized => Cleanup/optimization


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16220: Add introspection for multicolumn indexes

[Django]

#16220: Add introspection for multicolumn indexes
-+-
 Reporter:  jgelens  |Owner:  jgelens
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  dceu2011 inspectdb   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 What design decision is expected?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19264: prefetch_one_level is slow

[Django]

#19264: prefetch_one_level is slow
-+-
 Reporter:  simonpercivall   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 Accepting based on Luke's comment.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19512: Aggregate or Annotaion on previously Annotated values

[Django]

#19512: Aggregate or Annotaion on previously Annotated values
-+-
 Reporter:  eye-see-you@…|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  django, annotate,|  decision needed
  aggregate  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 If someone has a good patch for this, why not, but at the moment there
 isn't one.

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

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

Re: [Django] #17778: RequestContext methods pollute template variables

[Django]

#17778: RequestContext methods pollute template variables
-+--
 Reporter:  KyleMac  |Owner:
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:  sprint2013   | 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):

 * stage:  Design decision needed => Accepted


Comment:

 Under which circumstances would Django try to access attributes on the
 context?

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

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

Re: [Django] #20099: Allow filtering 404 reports by user agent

[Django]

#20099: Allow filtering 404 reports by user agent
---+
 Reporter:  coolRR |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by coolRR):

 I'm not sure what you're suggesting. If you're suggesting to keep the old
 name and negativity so it'll be easier for people to understand that this
 method is related to `IGNORABLE_404_URLS`, I disagree.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17834: ETag generated from empty content can break http caching

[Django]

#17834: ETag generated from empty content can break http caching
---+
 Reporter:  paulegan   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by aaugustin):

 #12789 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12789: ConditionalGetMiddleware behavior improvement.

[Django]

#12789: ConditionalGetMiddleware behavior improvement.
-+-
 Reporter:  penzoil  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  ETag,| Triage Stage:  Design
  ConditionalGetMiddleware,  |  decision needed
  patch_response_headers |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 As said by Russell early in the thread, this is actually a problem with
 ETag generation, which is tracked in #17834.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15729: Cache middleware issues after restart when using mod_wsgi with PyLibMC

[Django]

#15729: Cache middleware issues after restart when using mod_wsgi with PyLibMC
-+-
 Reporter:  jsdalton |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.3
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 There's more questions than answers on this ticket... If you want to
 advance this bug, get feedback from the pylibmc maintainers, and suggest a
 workaround.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20099: Allow filtering 404 reports by user agent

[Django]

#20099: Allow filtering 404 reports by user agent
---+
 Reporter:  coolRR |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by aaugustin):

 I thought about the double negative, but I felt it was still worth
 emphasizing the relation with IGNORABLE_404_URLS.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #11506: session.flush should not delete the old session

[Django]

#11506: session.flush should not delete the old session
--+
 Reporter:  Glenn |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * stage:  Design decision needed => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.