Re: [Django] #15178: Development server hangs very often when used with IE9 beta

[Django]

#15178: Development server hangs very often when used with IE9 beta
-+-
   Reporter: |  Owner:  nobody
  cataliniacob   | Status:  closed
   Type: |  Component:  Core (Other)
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:  ie9 development-
Version:  1.3-beta   |  server
 Resolution: |  Has patch:  0
  worksforme |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by anonymous):

 * version:  SVN => 1.3-beta
 * ui_ux:   => 0


Comment:

 I also had the problem with IE9, I foudnt hat by using the real IP address
 of the machine when starting the dev server instead of the default seemed
 to resolve the issue. Not sure why or whats really going there but this
 issue is popping up more and more doing some google searches.

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

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

Re: [Django] #7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse objects.

[Django]

#7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse
objects.
-+-
   Reporter:  mrmachine  |  Owner:  ccahoon
   Type:  New| Status:  new
  feature|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  stream HttpResponse
 Resolution: |  Content-Length
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by mrmachine):

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


Comment:

 Just updated the patch to apply cleanly against trunk again. Removed (now)
 redundant changes to CSRF middleware (it no longer breaks streaming). Also
 made `_get_content_generator()` consistent with `_get_content()` in that
 it now calls `smart_str()` on each chunk. This was causing me problems
 when passing a generator that yielded unicode strings instead of bytecode
 strings, which was breaking `compress_sequence()`.

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

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

Re: [Django] #16326: Un-pickled TemplateResponse objects can't be re-pickled

[Django]

#16326: Un-pickled TemplateResponse objects can't be re-pickled
--+-
   Reporter:  natrius |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Template system
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+-
Changes (by natrius):

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


Comment:

 I've attached a patch that fixes the problem. A further improvement would
 be for an un-pickled `TemplateResponse` to raise a more explicit exception
 when the removed attributes are accessed so it's clear what is going on.

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

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

Re: [Django] #16306: Form field documentation documents optional keyword arguments as field attributes.

[Django]

#16306: Form field documentation documents optional keyword arguments as  field
attributes.
-+-
   Reporter:  ShawnMilo  |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Forms
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  form field
   Triage Stage:  Design |  documentation
  decision needed|  Has patch:  0
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by SmileyChris):

 * needs_tests:  1 => 0
 * easy:  1 => 0


Comment:

 How does this look?

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

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

[Django] #16326: Un-pickled TemplateResponse objects can't be re-pickled

[Django]

#16326: Un-pickled TemplateResponse objects can't be re-pickled
-+-
 Reporter:  natrius  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Template system
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+-
 Pickling a `TemplateResponse` removes attributes that deal with rendering,
 presumably to make it clear that un-pickled `TemplateResponses` are
 completely baked and you can't do the typical things you'd do with a
 normal `TemplateResponse`. However, there's no check that ensures that the
 attributes exist before removing them, so if you try to re-pickle a
 `TemplateResponse`, you get a `KeyError`.

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

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

Re: [Django] #16317: Self-referencing model with natural key: dumpdata can't resolve dependencies

[Django]

#16317: Self-referencing model with natural key: dumpdata can't resolve
dependencies
-+-
   Reporter:  DrMeers|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core
Version:  1.3|  (Serialization)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by DrMeers):

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


Comment:

 (the intention is to serialise the self-referencing model separately
 natural keys, but use the natural key functionality in references from
 other 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16325: truncatewords_html and tables

[Django]

#16325: truncatewords_html and tables
--+-
 Reporter:  anonymous |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  Template system
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+-
 I noticed, that using truncatewords_html does truncate words in tables
 too, but if truncation point were happen in middle of row, it would be cut
 in middle.
 I'd recommend that this function wouldn't truncate in middle of row, but
 later, when that specific row ended.

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

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

Re: [Django] #16320: Please have view support for databases

[Django]

#16320: Please have view support for databases
-+-
   Reporter: |  Owner:  nobody
  benedict.m.holland@…   | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by benedict.m.holland@…):

 I can not imagine that linking up django to a database containing views is
 a project specific task. Views will also almost always contain foreign
 keys. Also the ability to create views is a standard database practice
 with any database in a production environment (and it just good programing
 practice anyway) and I do believe that since that is standard in any
 database that django should be able to create views and manipulate them.
 If anything having the ability to manually create them directly after
 specific tables have been created still seems like sort of a hack but less
 terrible.

 Let us say for example that I have a table and I want to put an is_active,
 or is_current column. While I could in fact put this in model code, it
 doesn't belong there, it belongs on the database and it has to be inside a
 view because it needs to be able to change whenever time changes (think
 is_active is true when start >= now() >= end).

 As I said before, unmanaged models do not work because I don't have a way
 to access the columns in the view (for example, is_active). If I forenkey
 off of the table containing the data, I will get an error trying to access
 is_active, but I have to foreignkey off of the table data because the
 view/table isn't created yet since it will only run my sql code after the
 syncdb.

 Basically, assume that you have a DB view which combines two tables in
 your model, A and B. The view is select * from A, select * from B and is
 called myView. I now want to access the foo column from B from the view
 and foreign key off of the view instead of table B.

 How can I currently do this in django as this is very common practice.

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

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

Re: [Django] #16319: add success_message in ClassViews

[Django]

#16319: add success_message in ClassViews
---+---
   Reporter:  wilsonpjunior@…  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Generic views
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by aaugustin):

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


Old description:

> sample:
>
> class CreatePersonView(CreateView):
> model = Person
> success_url = "/"
> success_message = "%(name)s was created successfully"
>

> after object created calls messages.sucess_message
>
> :-)

New description:

 sample:

 {{{
 class CreatePersonView(CreateView):
 model = Person
 success_url = "/"
 success_message = "%(name)s was created successfully"
 }}}

 after object created calls `messages.sucess_message`

 :-)

--

Comment:

 Just reformatted code excerpt.

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

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

Re: [Django] #16315: FileSystemStorage.listdir returns names with unicode normalization form that is different from names in database

[Django]

#16315: FileSystemStorage.listdir returns names with unicode normalization form
that is different from names in database
-+-
   Reporter:  philomat   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  File
Version:  1.3|  uploads/storage
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  storage unicode
  Unreviewed |  normalization
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 If I understand correctly, the bug is the fact that the file name is
 normalized in NFC form in the database and in NFD form on the filesystem.

 Django doesn't do any unicode normalisation — well, it does in two places,
 but they're obviously unrelated to the situation you describe.

 Maybe the normalization in NFC form appears when the string round-trips in
 the database. Or maybe the normalization in NFD form appears when the file
 is written on the file system. In both cases, that's outside the control
 of Django, but I'd like to understand what happens.

 Can you test:

 - writing a file called `u'\xe4'`, then `listdir()`, and see if it has
 turned into `u'a\u0308'`?
 - saving the string `u'a\u0308'` in the database (in any `CharField`),
 then retreive it, and see if it has turned into `u'\xe4'`

 Also, which database and which filesystem are you using?

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

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

Re: [Django] #12990: New Field Type: JSONField

[Django]

#12990: New Field Type: JSONField
-+-
   Reporter:  paltman|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2-beta   |   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 I've recently rolled my own implementation of this.

 I use it in a logging table where I want to store an event_kind (ex :
 "USER_LOGIN") + a datetime + a bunch of parameters  (ex : username, remote
 IP) that depend on the kind of event. I want to be able to add arbitrary
 parameters at any point. Normalizing parameters in a separate table (e.g.
 storing event_id, key, value in another table for each parameter) seems
 overkill — I don't want to add a model just for this.

 So I think there are some real-life use cases for storing a JSON-
 serialized dict in a database field. Since it's moderately difficult to
 get right, +0 for adding it in Django.

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

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

Re: [Django] #16320: Please have view support for databases

[Django]

#16320: Please have view support for databases
-+-
   Reporter: |  Owner:  nobody
  benedict.m.holland@…   | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * component:  ORM aggregation => Database layer (models, ORM)


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

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

Re: [Django] #16320: Please have view support for databases

[Django]

#16320: Please have view support for databases
-+-
   Reporter: |  Owner:  nobody
  benedict.m.holland@…   | Status:  new
   Type:  New|  Component:  ORM aggregation
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 In this situation, I think you should stick with unmanaged models and
 create your tables manually in the test environment, for example with
 initial SQL.

 Your use case looks rather specific; I can't tell if a per-model post-
 syncdb signal would be generally 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12990: New Field Type: JSONField

[Django]

#12990: New Field Type: JSONField
-+-
   Reporter:  paltman|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2-beta   |   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by Lee S):

 I would love to see a canonical version of JSON fields included.

 I routinely find storing non-structured, non-searchable data in the
 database to be extremely useful in many use cases.  Setting up a NoSQL
 database is often overkill.  The real need is to store the odd JSON field
 in an otherwise traditional SQL model. The example cited above, storing
 flexible metadata is a common one -- for example, key/value pairs
 indicating user preferences.

 I'm at the point where I have to try one of the many implementations
 listed above and cross my fingers that it's not broken.

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

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

Re: [Django] #16322: Some mobile Accept-Language headers are not parsed

[Django]

#16322: Some mobile Accept-Language headers are not parsed
-+-
   Reporter:  Max|  Owner:  nobody
  Arnold   | Status:  new
   Type:  Bug|  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


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

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

Re: [Django] #16323: Typo in 'Raising 404' listing

[Django]

#16323: Typo in 'Raising 404' listing
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:  typo
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by aaugustin):

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


Comment:

 Http404 is not a function; it's a class and it inherits `Exception`.

 Python allows raising exceptions like this:
 http://docs.python.org/tutorial/errors.html#raising-exceptions
 > The sole argument to raise indicates the exception to be raised. This
 must be either an exception instance or an exception class (a class that
 derives from Exception).

 A grep over the source and docs shows that both kinds or `raise` (with a
 class or an instance) are commonly used.

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

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

Re: [Django] #16324: Dutch (NL) translation for "Password reset on %s"

[Django]

#16324: Dutch (NL) translation for "Password reset on %s"
--+
   Reporter:  dokterbob   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Translations
Version:  1.3 |   Severity:  Normal
 Resolution:  invalid |   Keywords:  dutch nl nl_NL
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+
Changes (by aaugustin):

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


Comment:

 Thanks for this report.

 However, we don't update Django translations via the ticket system. We use
 [http://www.transifex.net/projects/p/django/ Transifex]. If you're
 interested in helping out, please sign up for the
 [http://www.transifex.net/projects/p/django/team/nl/ Dutch translation
 team].

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

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

[Django] #16324: Dutch (NL) translation for "Password reset on %s"

[Django]

#16324: Dutch (NL) translation for "Password reset on %s"
+--
 Reporter:  dokterbob   |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Translations
  Version:  1.3 |   Severity:  Normal
 Keywords:  dutch nl nl_NL  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  1
UI/UX:  0   |
+--
 Currently, the subject of the email received after requesting a password
 reset reads (in Dutch): "Wachtwoord hersteld op %s"

 This implies that the password has in fact already been reset, while
 actually the user has to first confirm this action by clicking a link.
 Hence, the current situation can be confusing to the user.

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

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

[Django] #16323: Typo in 'Raising 404' listing

[Django]

#16323: Typo in 'Raising 404' listing
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords:  typo   |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+---
 in the 'Raising 404' listing there is a simple typo:
 Http404 is a function that's why line 7 should be

 raise Http404()

 and not raise Http404

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

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

[Django] #16322: Some mobile Accept-Language headers are not parsed

[Django]

#16322: Some mobile Accept-Language headers are not parsed
---+--
 Reporter:  Max Arnold   |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Internationalization
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+--
 Some mobile phones use spaces before or after semicolon in Accept-Language
 header. Django can't parse such headers:

 {{{
 "Accept-Language: en; q=1.0, *; q=0.5"
 "Accept-Language: ru-ru,*; q=0.5"
 }}}

 {{{
 >>> parse_accept_lang_header('en; q=1.0, *; q=0.5')
 >>> []
 }}}


 More examples here: http://stackoverflow.com/questions/377864/detect-
 mobile-supported-languages

 Another confirmation:
 https://www-304.ibm.com/support/docview.wss?uid=swg1PK98260&wv=1

 According to RFC 2616, there should be no whitespaces, but RFC 3282 allows
 CFWS and also I found this proposal http://lists.w3.org/Archives/Public
 /ietf-http-wg/2009OctDec/0177.html where OWS is explicitly mentioned.

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

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

Re: [Django] #16306: Form field documentation documents optional keyword arguments as field attributes.

[Django]

#16306: Form field documentation documents optional keyword arguments as  field
attributes.
-+-
   Reporter:  ShawnMilo  |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Forms
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  form field
   Triage Stage:  Design |  documentation
  decision needed|  Has patch:  0
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by ShawnMilo):

 * component:  Documentation => Forms
 * stage:  Accepted => Design decision needed


Comment:

 Also, a comment about using one of the following workarounds:

 1. Replace the field completely in the form's __init__.
 2. Add the field in the form's __init__ (don't have it in the original
 definition).

 Both of these would cause confusion for the maintenance developer: Either
 a field is appearing 'by magic' or it's not as defined in the form
 originally. Neither case is desirable.

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

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

[Django] #16321: Provide password management with API of authentication backend.

[Django]

#16321: Provide password management with API of authentication backend.
---+--
 Reporter:  iElectric  |  Owner:  nobody
 Type:  New feature| Status:  new
Milestone:  1.4|  Component:  contrib.auth
  Version:  1.3|   Severity:  Normal
 Keywords:  ldap set_password  |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+--
 Following: https://bitbucket.org/psagers/django-auth-ldap/issue/8/add-the-
 ablility-to-change-password

 Currently there is no easy way to override how User model manages
 passwords. An idea is to move everything password related to
 authentication backend and add ability for different backends as LDAP to
 provide their own behavior.

 PS: haven't started writing the patch yet, waiting for feedback. Also,
 Django has plans to refactor User model, this could happen in parallel.

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

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

[Django] #16320: Please have view support for databases

[Django]

#16320: Please have view support for databases
--+-
 Reporter:  benedict.m.holland@…  |  Owner:  nobody
 Type:  New feature   | Status:  new
Milestone:|  Component:  ORM aggregation
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+-
 I am linking django to a legacy app database with views. The views have
 primary keys associated with them and can not be synced using the
 ./managed.py syncdb if and when I need to recreate this db on my test
 environment. I can create the views with manual sql code but when I run
 the syncdb command the view doesn't exist and it throws and error saying
 that the foreign key to this view can not be created because the table
 doesn't exist.

 I think the solution is a signal which is sent directly after the model is
 saved to the database which would allow me to hook off of it to create the
 views. Currently the REALLY nasty hack I am doing is creating my own view,
 subclassing off an unmanaged model which is the view, and after the syncdb
 running custom sql to create the view. I have to foreign key off of the
 actual table (not the view) which means that none of the associated view
 columns are available with that object when I do foreign object
 referencing in code like: foo.object = object where foo.object is a
 foreign key. The only work around is to alter every single reference to
 foo.object to foo.object = View.objects.get() which is prohibitively
 expensive and could in fact break a lot of stuff.

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

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

Re: [Django] #14502: Feature: escape hatch for colliding template syntax in Django templates

[Django]

#14502: Feature: escape hatch for colliding template syntax in Django templates
---+-
   Reporter:  dgouldin |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Template system
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):

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


Comment:

 #16318 was a duplicate. It contains an alternative implementation.

 Another discussion : http://groups.google.com/group/django-
 developers/browse_thread/thread/eda0e9187adcbe36

 "verbatim" is a better name than "noparse" IMO — that's how people call
 this feature spontaneously.

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

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

Re: [Django] #16318: Add a standard verbatim tag

[Django]

#16318: Add a standard verbatim tag
-+-
   Reporter: |  Owner:  nobody
  calvinspealman | Status:  closed
   Type:  New|  Component:  Template system
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  SVN|  Has patch:  0
 Resolution:  duplicate  |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Related discussion threads:

 * http://groups.google.com/group/django-
 
developers/browse_thread/thread/e914638d8fe859de/752e44fd9ddc8229?lnk=gst&q=verbatim#752e44fd9ddc8229
 * http://groups.google.com/group/django-
 
developers/browse_thread/thread/eda0e9187adcbe36/4a27e9a79266cf55?lnk=gst&q=verbatim#4a27e9a79266cf55

 This is actually a duplicate of #14502 which is mentioned in the first of
 these two threads.

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

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

[Django] #16319: add success_message in ClassViews

[Django]

#16319: add success_message in ClassViews
-+---
 Reporter:  wilsonpjunior@…  |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:  1.4  |  Component:  Generic views
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+---
 sample:

 class CreatePersonView(CreateView):
 model = Person
 success_url = "/"
 success_message = "%(name)s was created successfully"


 after object created calls messages.sucess_message

 :-)

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

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

Re: [Django] #16318: Add a standard verbatim tag

[Django]

#16318: Add a standard verbatim tag
-+-
   Reporter: |  Owner:  nobody
  calvinspealman | Status:  new
   Type:  New|  Component:  Template system
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  SVN|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by calvinspealman):

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


Comment:

 (taken from https://gist.github.com/629508 )

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

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

[Django] #16318: Add a standard verbatim tag

[Django]

#16318: Add a standard verbatim tag
+-
 Reporter:  calvinspealman  |  Owner:  nobody
 Type:  New feature | Status:  new
Milestone:  1.4 |  Component:  Template system
  Version:  SVN |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+-
 jQuery templates use constructs like:

 {{if condition}} print something{{/if}}

 This, of course, completely screws up Django templates,
 because Django thinks {{ and }} mean something.

 Wrap {% verbatim %} and {% endverbatim %} around those
 blocks of jQuery templates and this will try its best
 to output the contents with no changes.


 {{{
 from django import template

 register = template.Library()


 class VerbatimNode(template.Node):

 def __init__(self, text):
 self.text = text

 def render(self, context):
 return self.text


 @register.tag
 def verbatim(parser, token):
 text = []
 while 1:
 token = parser.tokens.pop(0)
 if token.contents == 'endverbatim':
 break
 if token.token_type == template.TOKEN_VAR:
 text.append('{{')
 elif token.token_type == template.TOKEN_BLOCK:
 text.append('{%')
 text.append(token.contents)
 if token.token_type == template.TOKEN_VAR:
 text.append('}}')
 elif token.token_type == template.TOKEN_BLOCK:
 text.append('%}')
 return VerbatimNode(''.join(text))
 }}}

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

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

Re: [Django] #16308: CheckboxSelectMultiple can not show the data on the view

[Django]

#16308: CheckboxSelectMultiple can not show the data on the view
-+-
   Reporter: |  Owner:  nobody
  jekyllhy3@…| Status:  reopened
   Type: |  Component:  Documentation
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:  Checkbox Select
Version:  1.3|  Multiple
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 Reopening so that this ticket can be reviewed again (I don't have time to
 do it just now).

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

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

[Changeset] r16445 - django/trunk/django/contrib/admin/views

[noreply]

Author: jezdez
Date: 2011-06-22 05:20:52 -0700 (Wed, 22 Jun 2011)
New Revision: 16445

Modified:
   django/trunk/django/contrib/admin/views/main.py
Log:
Fixed typos in admin views wrt list_filter. Refs #16311.

Modified: django/trunk/django/contrib/admin/views/main.py
===
--- django/trunk/django/contrib/admin/views/main.py 2011-06-22 06:01:44 UTC 
(rev 16444)
+++ django/trunk/django/contrib/admin/views/main.py 2011-06-22 12:20:52 UTC 
(rev 16445)
@@ -91,21 +91,21 @@
 filter_specs = []
 cleaned_params, use_distinct = self.get_lookup_params(use_distinct)
 if self.list_filter:
-for list_filer in self.list_filter:
-if callable(list_filer):
+for list_filter in self.list_filter:
+if callable(list_filter):
 # This is simply a custom list filter class.
-spec = list_filer(request, cleaned_params,
+spec = list_filter(request, cleaned_params,
 self.model, self.model_admin)
 else:
 field_path = None
-if isinstance(list_filer, (tuple, list)):
+if isinstance(list_filter, (tuple, list)):
 # This is a custom FieldListFilter class for a given 
field.
-field, field_list_filter_class = list_filer
+field, field_list_filter_class = list_filter
 else:
 # This is simply a field name, so use the default
 # FieldListFilter class that has been registered for
 # the type of the given field.
-field, field_list_filter_class = list_filer, 
FieldListFilter.create
+field, field_list_filter_class = list_filter, 
FieldListFilter.create
 if not isinstance(field, models.Field):
 field_path = field
 field = get_fields_from_path(self.model, 
field_path)[-1]

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

Re: [Django] #16311: Option to limit list_filter to related_objects of instances of the list

[Django]

#16311: Option to limit list_filter to related_objects of instances of the list
-+-
   Reporter:  Stanislas  |  Owner:  nobody
  Guerra | Status:  new
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone: |   Keywords:  admin, list_filter,
Version:  1.3|  limit_choices_to
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 In [16445]:
 {{{
 #!CommitTicketReference repository="" revision="16445"
 Fixed typos in admin views wrt list_filter. Refs #16311.
 }}}

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

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

[Django] #16317: Self-referencing model with natural key: dumpdata can't resolve dependencies

[Django]

#16317: Self-referencing model with natural key: dumpdata can't resolve
dependencies
-+--
 Reporter:  DrMeers  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Core (Serialization)
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+--
 I have a self-referencing model with a natural key, but dumpdata won't
 serialize it:

 {{{
 Error: Can't resolve dependencies for app_label.ModelName in
 serialized app list
 }}}

 This is probably perfectly valid if use_natural_keys=True, but shouldn't I
 be able to serialize it without natural keys? I suspect
 dumpdata.sort_dependencies should take the flag setting into consideration
 before throwing natural-key-based dependencies into the mix?

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

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

Re: [Django] #12990: New Field Type: JSONField

[Django]

#12990: New Field Type: JSONField
-+-
   Reporter:  paltman|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2-beta   |   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by guettli):

 By setting up a NoSQL store you loose the transactional atomic behavior:
 commit all or nothing. AFAIK two-phase commit is not supported by django.
 I think a JSONField inside django would be good. I don't want to query the
 JSON value. I just use JSONField like cache that never expires.

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

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

Re: [Django] #16311: Option to limit list_filter to related_objects of instances of the list

[Django]

#16311: Option to limit list_filter to related_objects of instances of the list
-+-
   Reporter:  Stanislas  |  Owner:  nobody
  Guerra | Status:  new
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone: |   Keywords:  admin, list_filter,
Version:  1.3|  limit_choices_to
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by Stanislas Guerra ):

 Thanks for the feedback.

 I have rewritten the patch for the trunk according to your suggestions and
 the usage is now :


 {{{
 from django.contrib.admin.filters import RelatedOnlyFieldListFilter

 class OrderAdmin(admin.ModelAdmin):
 ...
 list_filter = ('support', 'agency', ('parutions',
 RelatedOnlyFieldListFilter))

 }}}

 Writting some tests now.

 By the way, is `list_filer` a typo in `contrib.admin.views.main` (line 82)
 ?


 {{{
for list_filer in self.list_filter:
 if callable(list_filer):
 # This is simply a custom list filter class.
 spec = list_filer(request, cleaned_params,
 self.model, self.model_admin)
 else:
 field_path = None
 if isinstance(list_filer, (tuple, list)):
 # This is a custom FieldListFilter class for a
 given field.
 field, field_list_filter_class = list_filer
 else:
 # This is simply a field name, so use the default
 # FieldListFilter class that has been registered
 for
 # the type of the given field.
 field, field_list_filter_class = list_filer,
 FieldListFilter.create

 }}}

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

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