Re: [Django] #9345: Various string consistency fixes

[Django]

#9345: Various string consistency fixes
-+---
   Reporter:  Semmel |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Uncategorized
Version:  1.0|   Severity:  Normal
 Resolution:  wontfix|   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+---

Comment (by julien):

 Replying to [comment:13 Semmel]:
 > "email" seems to fit it better. :) Any use for the few other fixes that
 were included in the patch?

 I think it's a bit confusing to have a patch addressing multiple
 inconsistencies in multiple places. It will be easier if you create
 separate tickets for each chunk of related issues.

-- 
Ticket URL: 
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] #15953: Allow setting individual fields as 'unique' from the model Meta options

[Django]

#15953: Allow setting individual fields as 'unique' from the model Meta options
-+-
   Reporter:  julien |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Description changed by julien:

Old description:

> I'm dealing with this case:
>
> {{{#!python
> class A(models.Model):
> blah = models.CharField(max_length=100)
>
> class Meta:
> abstract = True
>
> class B(A):
> pass
> }}}
>
> ... where `A` is in a separate app than `B` and is used in multiple
> different contexts. I need to have the `blah` field be unique for `B`,
> whereas it shouldn't necessarily be unique in every other context where
> it is used. The only way I've found so far is:
>
> {{{#!python
> class B(A):
> pass
>
> B._meta.get_field('blah')._unique = True # Ugliness alert!
> }}}
>
> Is it envisageable to allow setting the `unique` flag for individual
> fields from the Meta options, in the same way as with `unique_together`?
> Something like this for example:
>
> {{{#!python
> class B(models.Model):
>
> class Meta:
> unique = ('blah',)
> }}}

New description:

 I'm dealing with this case:

 {{{#!python
 class A(models.Model):
 blah = models.CharField(max_length=100)

 class Meta:
 abstract = True

 class B(A):
 pass
 }}}

 ... where `A` is in a separate app than `B` and is used in multiple
 different contexts. I need to have the `blah` field be unique for `B`,
 whereas it shouldn't necessarily be unique in every other context where it
 is used. The only way I've found so far is:

 {{{#!python
 class B(A):
 pass

 B._meta.get_field('blah')._unique = True # Ugliness alert!
 }}}

 Is it envisageable to allow setting the `unique` flag for individual
 fields from the Meta options, in the same way as with `unique_together`?
 Something like this for example:

 {{{#!python
 class B(A):

 class Meta:
 unique = ('blah',)
 }}}

--

-- 
Ticket URL: 
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] #15953: Allow setting individual fields as 'unique' from the model Meta options

[Django]

#15953: Allow setting individual fields as 'unique' from the model Meta options
-+-
   Reporter:  julien |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Old description:

> I'm dealing with this case:
>
> {{{#!python
> class A(models.Model):
> blah = models.CharField(max_length=100)
>
> class Meta:
> abstract = True
>
> class B(models.Model):
> pass
> }}}
>
> ... where `A` is in a separate app than `B` and is used in multiple
> different contexts. I need to have the `blah` field be unique for `B`,
> whereas it shouldn't necessarily be unique in every other context where
> it is used. The only way I've found so far is:
>
> {{{#!python
> class B(models.Model):
> pass
>
> B._meta.get_field('blah')._unique = True # Ugliness alert!
> }}}
>
> Is it envisageable to allow setting the `unique` flag for individual
> fields from the Meta options, in the same way as with `unique_together`?
> Something like this for example:
>
> {{{#!python
> class B(models.Model):
>
> class Meta:
> unique = ('blah',)
> }}}

New description:

 I'm dealing with this case:

 {{{#!python
 class A(models.Model):
 blah = models.CharField(max_length=100)

 class Meta:
 abstract = True

 class B(A):
 pass
 }}}

 ... where `A` is in a separate app than `B` and is used in multiple
 different contexts. I need to have the `blah` field be unique for `B`,
 whereas it shouldn't necessarily be unique in every other context where it
 is used. The only way I've found so far is:

 {{{#!python
 class B(A):
 pass

 B._meta.get_field('blah')._unique = True # Ugliness alert!
 }}}

 Is it envisageable to allow setting the `unique` flag for individual
 fields from the Meta options, in the same way as with `unique_together`?
 Something like this for example:

 {{{#!python
 class B(models.Model):

 class Meta:
 unique = ('blah',)
 }}}

--

Comment (by julien):

 (fixed description: `B` inherits from `A`)

-- 
Ticket URL: 
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] #15907: Generic inlines ignoring the exclude information from a custom form.

[Django]

#15907: Generic inlines ignoring the exclude information from a custom form.
-+-
   Reporter: |  Owner:  nobody
  leonelfreire   | Status:  new
   Type:  Bug|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  form, exclude,
 Resolution: |  generic, inline
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by prestontimmons):

 I combined the patches with tests and fix into one. Leonel, your patch had
 lines to combine the fields attribute. I couldn't reproduce a case where
 fields ever showed up wrong, so I left that out. If there's a bug I'm
 missing it'd be cool to fix that as well.

-- 
Ticket URL: 
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] #15953: Allow setting individual fields as 'unique' from the model Meta options

[Django]

#15953: Allow setting individual fields as 'unique' from the model Meta options
-+-
 Reporter:  julien   |Owner:  nobody
 Type:  New feature  |   Status:  new
Milestone:   |Component:  Database
  Version:  1.3  |  layer (models, ORM)
 Keywords:   | Severity:  Normal
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
-+-
 I'm dealing with this case:

 {{{#!python
 class A(models.Model):
 blah = models.CharField(max_length=100)

 class Meta:
 abstract = True

 class B(models.Model):
 pass
 }}}

 ... where `A` is in a separate app than `B` and is used in multiple
 different contexts. I need to have the `blah` field be unique for `B`,
 whereas it shouldn't necessarily be unique in every other context where it
 is used. The only way I've found so far is:

 {{{#!python
 class B(models.Model):
 pass

 B._meta.get_field('blah')._unique = True # Ugliness alert!
 }}}

 Is it envisageable to allow setting the `unique` flag for individual
 fields from the Meta options, in the same way as with `unique_together`?
 Something like this for example:

 {{{#!python
 class B(models.Model):

 class Meta:
 unique = ('blah',)
 }}}

-- 
Ticket URL: 
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] r16141 - django/trunk/docs/ref/templates

[noreply]

Author: Alex
Date: 2011-05-02 20:15:28 -0700 (Mon, 02 May 2011)
New Revision: 16141

Modified:
   django/trunk/docs/ref/templates/builtins.txt
Log:
Fixed #15952 -- fixed an error in the template builtins docs.

Modified: django/trunk/docs/ref/templates/builtins.txt
===
--- django/trunk/docs/ref/templates/builtins.txt2011-05-01 20:11:04 UTC 
(rev 16140)
+++ django/trunk/docs/ref/templates/builtins.txt2011-05-03 03:15:28 UTC 
(rev 16141)
@@ -493,7 +493,7 @@
 {% endif %}
 
 ``not in`` operator
-
+^^^
 
 Not contained within.  This is the negation of the ``in`` operator.
 

-- 
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] #15952: "not in" improperly spaced in docs

[Django]

#15952: "not in" improperly spaced in docs
-+-
   Reporter:  Leo|  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone:  1.4|  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  0
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by Alex):

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


Comment:

 In [16141]:
 {{{
 #!CommitTicketReference repository="" revision="16141"
 Fixed #15952 -- fixed an error in the template builtins docs.
 }}}

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

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

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

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  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
---+---

Comment (by julien):

 I've just discussed the `post_url_continue` issue with Ramiro on IRC and
 it was decided that it won't be tackled by the work in this ticket. It
 will be done as part of #8001 instead.

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

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

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

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  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
---+---

Comment (by julien):

 Replying to [comment:13 ramiro]:
 > Am I wrong if I say that comment:4 and comments from comment:6 onwards
 belong in #8001 and not here? Ths ticket is only about making current
 handling on intra-admin site handling of URLs.

 I was wrong in linking this issue to #5925 -- I initially thought that
 `reverse_lazy` may help here, but in fact it can't.

 However, I think that the other comments about `post_url_continue` are
 still relevant (this was even mentioned in the original report). If we can
 find a neat implementation for dealing with `post_url_continue` then that
 would be helpful for #8001 too. But, regardless of #8001, I think we
 should still do something to remove the hardcoded value of
 `post_url_continue` at the same time as the other things in the admin
 views and templates.

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

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

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

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  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
---+---

Comment (by ramiro):

 Am I wrong if I say that comment:4 and comments from comment:6 onwards
 belong in #8001 and not here? Ths ticket is only about making current
 handling on intra-admin site handling of 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 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] #15952: "not in" improperly spaced in docs

[Django]

#15952: "not in" improperly spaced in docs
-+-
   Reporter:  Leo|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  0
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Ready for checkin
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #15952: "not in" improperly spaced in docs

[Django]

#15952: "not in" improperly spaced in docs
-+---
 Reporter:  Leo  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:  1.4  |  Component:  Documentation
  Version:  SVN  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  1
-+---
 On this page: http://docs.djangoproject.com/en/dev/ref/templates/builtins/
 if you look over in the right nav, the entry for 'not in' is de-dented too
 much. It should be another level to the right.

 The culprit is:
 
http://code.djangoproject.com/browser/django/trunk/docs/ref/templates/builtins.txt#L496

 That line should actually be:

 `^^^`

 Instead of:

 ``

 One character shorter and carets instead of tildes

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

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

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

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  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
---+---

Comment (by julien):

 Replying to [comment:11 burzak]:
 > I like this...
 > {{{
 > #!python
 > if post_url_continue is None:
 > post_url_continue = reverse("admin:%s_%s_change" %
 (opts.app_label, opts.module_name), args=(pk_value,),
 current_app=self.admin_site.name)
 > }}}

 I like this better too. It all depends on whether we're allowing this or
 not (based on the backward compatibility policy). I think it's worth
 breaking compatibility in this case, as it would make the implementation a
 lot cleaner, and the `response_add` method is not documented yet anyway.

 Maybe this is worth asking on the dev-list for other opinions.

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

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

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

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  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
---+---

Comment (by burzak):

 Replying to [comment:10 julien]:
 > Replying to [comment:8 burzak]:
 > > I did something like that here [0]. I changed the default value to
 None and I made an 'if' like this in order to maintain backward
 compatibility:
 > >
 > > {{{
 > > #!python
 > >
 > > if post_url_continue is not None:
 > > post_url_continue = post_url_continue % pk_value
 > > else:
 > > post_url_continue = reverse("admin:%s_%s_change" %
 (opts.app_label, opts.module_name), args=(pk_value,),
 current_app=self.admin_site.name)
 > > }}}
 >
 > Cool, that makes sense. However, this could be a bit limiting as you
 couldn't pass a pre-formatted string -- it would necessarily require a
 string format to insert `pk_value`.
 >
 > I can think of 2 options, either/or:
 >
 > * we consider that `response_add` is not part of the official API (it's
 not documented) and therefore we don't worry about breaking backwards
 compatibility. We then just assume that `post_url_continue` is either
 `None` or a pre-formatted string.
 > * we first try to insert `pk_value` into `post_url_continue`, but if an
 exception is raised then we assumed it's a pre-formatted string and move
 on with it.
 >
 > Hope that makes sense. What do you think?


 I tend to think that if somebody pass a `post_url_continue` this have to
 be pre-formatted since the user must know where to go.

 I like the idea of keeping the code clean and do not add any try/catch. If
 the backward compatibility is not so much important in this situation I
 would be happy removing the `pk_value`.

 I like this...
 {{{
 #!python
 if post_url_continue is None:
 post_url_continue = reverse("admin:%s_%s_change" %
 (opts.app_label, opts.module_name), args=(pk_value,),
 current_app=self.admin_site.name)
 }}}

 rather than:
 {{{
 #!python
 if post_url_continue is None:
 post_url_continue = reverse("admin:%s_%s_change" %
 (opts.app_label, opts.module_name), args=(pk_value,),
 current_app=self.admin_site.name)
 else:
 try:
 post_url_continue = post_url_continue % pk_value
 except TypeError:
 pass
 }}}

-- 
Ticket URL: 
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] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
-+-
   Reporter: |  Owner:  jkocherhans
  Honza_Kral | Status:  assigned
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone: |   Keywords:  nfa-someday
Version:  SVN|  list_filter filterspec nfa-
 Resolution: |  changelist ep2008
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by julien):

 Thanks Jannis! All your changes make sense. I've made a few more changes
 in the latest patch:

 * Renamed `contrib.admin.filterspecs` to `contrib.admin.filters`. Feels
 cleaner and makes more sense now that we've renamed everything from
 `FilterSpec` to `ListFilter`.
 * Removed references to parameter slugification in doc and code comments.
 * `ChangeList.get_query_set()` now receives the `request` as parameter
 (instead of setting a request attribute to the `ChangeList` object as
 introduced in patch 7).
 * Added tests to ensure that `title` and `parameter_name` are correctly
 defined.

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

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

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

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  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
---+---

Comment (by julien):

 Replying to [comment:8 burzak]:
 > I did something like that here [0]. I changed the default value to None
 and I made an 'if' like this in order to maintain backward compatibility:
 >
 > {{{
 > #!python
 >
 > if post_url_continue is not None:
 > post_url_continue = post_url_continue % pk_value
 > else:
 > post_url_continue = reverse("admin:%s_%s_change" %
 (opts.app_label, opts.module_name), args=(pk_value,),
 current_app=self.admin_site.name)
 > }}}

 Cool, that makes sense. However, this could be a bit limiting as you
 couldn't pass a pre-formatted string -- it would necessarily require a
 string format to insert `pk_value`.

 I can think of 2 options, either/or:

 * we consider that `response_add` is not part of the official API (it's
 not documented) and therefore we don't worry about breaking backwards
 compatibility. We then just assume that `post_url_continue` is either
 `None` or a pre-formatted string.
 * we first try to insert `pk_value` into `post_url_continue`, but if an
 exception is raised then we assumed it's a pre-formatted string and move
 on with it.

 Hope that makes sense. What do you think?

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

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

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

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  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
---+---
Changes (by burzak):

 * cc: dario.ocles@… (added)


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

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

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

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  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
---+---

Comment (by burzak):

 Replying to [comment:7 julien]:
 > Or probably a better approach is to default `post_url_continue` to
 `None`:
 >
 > {{{
 > #!python
 > def response_add(self, request, obj, post_url_continue=None):
 > ...
 > if post_url_continue is None:
 > post_url_continue = reverse('admin:%s_%s_change' %
 > (opts.app_label, module_name),
 > args=pk_value,
 >
 current_app=self.admin_site.name)
 > ...
 > }}}

 I did something like that here [0]. I changed the default value to None
 and I made an 'if' like this in order to maintain backward compatibility:

 {{{
 #!python

 if post_url_continue is not None:
 post_url_continue = post_url_continue % pk_value
 else:
 post_url_continue = reverse("admin:%s_%s_change" %
 (opts.app_label, opts.module_name), args=(pk_value,),
 current_app=self.admin_site.name)
 }}}

 
https://github.com/burzak/django/commit/cd275d5918aea8ee6d8dc0cdb2c93f2409c87637

-- 
Ticket URL: 
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] #15768: The setUp() method FileStorageTests in tests/regressiontests/file_storage/tests.py uses tempfile.mktemp()

[Django]

#15768: The setUp() method FileStorageTests in
tests/regressiontests/file_storage/tests.py uses tempfile.mktemp()
-+-
   Reporter:  d1b|  Owner:  elbarto
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Uncategorized
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by elbarto):

 * has_patch:  0 => 1


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

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

Re: [Django] #9345: Various string consistency fixes

[Django]

#9345: Various string consistency fixes
-+---
   Reporter:  Semmel |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Uncategorized
Version:  1.0|   Severity:  Normal
 Resolution:  wontfix|   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+---
Changes (by Semmel):

 * easy:   => 0


Comment:

 "email" seems to fit it better. :) Any use for the few other fixes that
 were included in 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 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] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
---+--
   Reporter:  brutasse |  Owner:  brutasse
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Forms
Version:   |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+--

Comment (by brutasse):

 Ok, so according to the chat we had on IRC with Carl an Jannis,
 format_output and renderer / get_renderer should be deprecated since it's
 too hard to keep them along with the new API and they're not considered
 public. This is done in the latest version of the patch:

 https://github.com/brutasse/django/compare/15667-template-widgets

 If a MultiWidget defines a format_output() method, calling render() raises
 a DeprecationWarning and uses template-based rendering anyway. Same with
 the renderers:

 * providing renderer as a kwarg during RadioSelect instanciation raises
 DeprecationWarning
 * the RadioSelect class doesn't have a renderer attribute anymore
 * any call to get_renderer() raises a DeprecationWarning and returns
 RadioFieldRenderer
 * RadioSelect's render() will **always** use templates

 The admin's RelatedFieldWidgetWrapper now has its template attribute and
 get_context method.

 The template loader still needs to be worked on (Carl's comment 15 above).
 I'll give it a go tomorrow night, CEST.

-- 
Ticket URL: 
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] #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:  nobody
   Type:  New| Status:  new
  feature|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  1.2-beta   |   Keywords:  ChoiceField,
 Resolution: |  choices
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by julien):

 * easy:   => 0


Comment:

 #15950 is a dupe and has a patch with a different approach.

-- 
Ticket URL: 
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] #15950: Allow ChoiceField and friends to take a callable for choices kwarg

[Django]

#15950: Allow ChoiceField and friends to take a callable for choices kwarg
---+
   Reporter:  jdunck   |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Forms
Version:  1.3  |   Severity:  Normal
 Resolution:  duplicate|   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+
Changes (by julien):

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


Comment:

 This was actually already suggested in #13181.

-- 
Ticket URL: 
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] #15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality

[Django]

#15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality
-+-
   Reporter: |  Owner:  nobody
  lev.maximov@…  | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  USE_THOUSAND_SEPARATOR
   Triage Stage:  Accepted   |  prepopulated_fields
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-
Changes (by magopian):

 * needs_tests:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15946: Exceptions used for program logic db/utils.py load_backend

[Django]

#15946: Exceptions used for program logic db/utils.py load_backend
-+-
   Reporter: |  Owner:  nobody
  sgronblo@… | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Third-party database backends have names not starting with
 `django.db.backends`, so your solution does not work. Example here:
 http://code.google.com/p/ibm-db/wiki/ibm_db_django_README

-- 
Ticket URL: 
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] #15918: settings.THOUSAND_SEPARATOR is used only when the current locale does not provide a value

[Django]

#15918: settings.THOUSAND_SEPARATOR is used only when the current locale does 
not
provide a value
-+-
   Reporter:  lev|  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  THOUSAND_SEPARATOR
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * needs_docs:  1 => 0
 * component:  Internationalization => Documentation
 * needs_tests:  1 => 0


Comment:

 After checking with jezdez on IRC, I'm marking this as a documentation
 issue again.

 I'm attaching a patch based on lev's last comment, which is a good summary
 of the situation.

-- 
Ticket URL: 
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] #15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality

[Django]

#15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality
-+-
   Reporter: |  Owner:  nobody
  lev.maximov@…  | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  USE_THOUSAND_SEPARATOR
   Triage Stage:  Accepted   |  prepopulated_fields
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
 |  Easy pickings:  1
-+-

Comment (by magopian):

 see #14895 for a similar issue (localization of a pk)

-- 
Ticket URL: 
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] #10571: FakePayload Truncates Unicode Content

[Django]

#10571: FakePayload Truncates Unicode Content
-+-
   Reporter:  rwagner@…  |  Owner:  nobody
   Type: | Status:  reopened
  Uncategorized  |  Component:  Testing framework
  Milestone:  1.1|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by droberts@…):

 * easy:   => 0


Comment:

 I just encountered this same problem (Django 1.2.3), but it looks like
 it's still not fully solved in Django 1.3 from the above comment. It seems
 like the real problem here is that FakePayload only works when the content
 is a str and not when it's unicode, and yet it doesn't advertise this
 correctly. If it's passed a unicode, it happily accepts it, failing later
 when .read() is called. This seems like a classic duck-typing bug, but
 since it's very common to expect that functions will accept either str or
 unicode, it seems like the correct behavior here would be to fail hard
 when FakePayload.__init__ is passed a unicode object.

 In my particular case, I was using a StringIO as a the file-like object.
 StringIO.read() returns a str if it's been given strings and unicode if
 it's been given unicode. I seeded it with what to me looked like a string
 but turned out to be a unicode, and no one along the way checked to see
 that the output of f.read() (where f is the StringIO object) was returning
 unicode. A simple check in FakePayload would have saved me a couple of
 hours of debugging what seemed like very mysterious behavior.

-- 
Ticket URL: 
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] #15496: "Content-Transfer-Encoding: base64" not honored when uploading files

[Django]

#15496: "Content-Transfer-Encoding: base64" not honored when uploading files
-+-
   Reporter:  gene@… |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  HTTP handling
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  base64 file upload
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #15496: "Content-Transfer-Encoding: base64" not honored when uploading files

[Django]

#15496: "Content-Transfer-Encoding: base64" not honored when uploading files
+
   Reporter:  gene@…|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  HTTP handling
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  base64 file upload
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+
Changes (by claudep):

 * version:  1.2 => SVN
 * easy:   => 0
 * needs_tests:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15900: reverse() does not properly escape namespaced views

[Django]

#15900: reverse() does not properly escape namespaced views
+--
   Reporter:  teolicy   |  Owner:  dmclain
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  Core (Other)
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+--
Changes (by dmclain):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15900: reverse() does not properly escape namespaced views

[Django]

#15900: reverse() does not properly escape namespaced views
+--
   Reporter:  teolicy   |  Owner:  dmclain
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  Core (Other)
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
+--

Comment (by dmclain):

 > As mentioned by the reporter, the bug only occurs when a namespace is
 used, yet I fail to see how your patch specifically addresses that. Could
 you elaborate on your approach?
 [[BR]]
 When there is a namespaced url being resolved, the reverse() function
 builds a prefix composed of all the url pieces that correspond to the
 nested namespaces. These pieces are standard regular expressions, but
 rather than being normalized, they are blindly prepended onto the path.
 This results in errors if the regex does anything regex-y like capturing
 variables or having a character class in them.
 [[BR]]
 [[BR]]
 > I've had a quick look at this and I'm not sure if this patch addresses
 the core issue. dmclain, you mention that the resolver did not normalise
 prefixes, yet I see there already are passing tests for the following
 pattern at
 
source:django/trunk/tests/regressiontests/urlpatterns_reverse/extra_urls.py#L12:
 [[BR]]
 That test doesn't trigger the behavior this bug is talking about because
 it's not namespaced and so doesn't go down the prefix building code path.
  [[BR]]
 > Also, looking at your tests, the following passes:
 >
 > {{{
 > #!python
 > (r'^other[246]/', include(otherobj2.urls)),
 > }}}
 >
 > ... yet the tests unexpectedly fail if I swap the digits:
 >
 > {{{
 > #!python
 > (r'^other[426]/', include(otherobj2.urls)),
 > }}}

 That is the expected behavior. The method django uses to normalize a
 regular expression just takes the first option out of a character class.
 Similarly it uses a period when it's reversing the any character class
 which is represented by a period in regexs. See
 source:django/trunk/django/utils/regex_helper.py#L12
 [[BR]]
 [[BR]]
 > Finally, for completeness, it'd be good to test what is supposed to
 happen, for example, with "/other9/inner/".
 [[BR]]
 I assume you mean doing the url resolving forward instead of just testing
 reverse? I'll add a test for that.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15951: Document new backport policy.

[Django]

#15951: Document new backport policy.
-+-
   Reporter:  apollo13   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

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

[Django] #15951: Document new backport policy.

[Django]

#15951: Document new backport policy.
---+---
 Reporter:  apollo13   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
---+---
 The new backport policy (http://groups.google.com/group/django-
 developers/browse_thread/thread/3f856c6bccea172a#) should get documented.

-- 
Ticket URL: 
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] #15950: Allow ChoiceField and friends to take a callable for choices kwarg

[Django]

#15950: Allow ChoiceField and friends to take a callable for choices kwarg
---+
   Reporter:  jdunck   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  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
---+

Comment (by jdunck):

 Hmm, writing a generator to do a query only on the first execution of the
 generator is a little fiddly.  (If there's a nice way to write it, please
 give an example.)

 There's a common pattern of accepting callables - maybe we should add
 callable to model choices, too?

-- 
Ticket URL: 
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] #15949: documentation for view password_reset_done needs changing.

[Django]

#15949: documentation for view password_reset_done needs changing.
-+---
   Reporter:  cyclops@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
-+---

Comment (by cyclops@…):

 I agree that ''password_reset_done'' is a bad name. However, fixing that
 would require changing ''code'', whereas my suggestion only involved a
 documentation change. I wasn't clear on how much or what, should be put
 into a ticket, but it seemed like a pure text-only change would be
 simpler.

-- 
Ticket URL: 
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] #15588: "FileField no longer deletes files" unclear

[Django]

#15588: "FileField no longer deletes files" unclear
-+-
   Reporter:  philipn|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  1.3-beta   |   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by dmclain):

 * cc: dmclain (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13770: form BooleanField should clean the string u'false' as False.

[Django]

#13770: form BooleanField should clean the string u'false' as False.
-+
   Reporter:  jordanb|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Forms
Version:  1.1|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for checkin  |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+
Changes (by dmclain):

 * cc: dmclain (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15950: Allow ChoiceField and friends to take a callable for choices kwarg

[Django]

#15950: Allow ChoiceField and friends to take a callable for choices kwarg
---+
   Reporter:  jdunck   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  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
---+
Changes (by jezdez):

 * component:  Uncategorized => Forms
 * stage:  Unreviewed => Accepted


Comment:

 Yeah, seems reasonable, although I'd prefer something like what the model
 fields do, taking any iterable instead:
 
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py?rev=15982#L393

 Would that solve the issue for you, too?

-- 
Ticket URL: 
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] #11035: urlify.js with Serbian alphabet

[Django]

#11035: urlify.js with Serbian alphabet
-+-
   Reporter:  janos  |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  slug slugify urlify
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

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


Comment:

 Yet! We hope to land
 https://github.com/sebleier/django/tree/feature/q-unit soon.

-- 
Ticket URL: 
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] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
-+-
   Reporter: |  Owner:  jkocherhans
  Honza_Kral | Status:  assigned
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone: |   Keywords:  nfa-someday
Version:  SVN|  list_filter filterspec nfa-
 Resolution: |  changelist ep2008
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by jezdez):

 Thanks everyone for the work on this patch, I've just reviewed it and took
 the liberty to modify the API a bit more:

 - Reverted the Java-esque `SingleQueryParameterListFilter` to
 `SimpleListFilter` again, which has a `lookups` (instead of `get_choices`)
 method as the only difference to the other filter classes.
 - Renamed `get_output_choices` to `choices` since it really is the best
 description for its functionality
 - Cleaned up some unneeded implementation details (e.g.
 `ChangeList.apply_list_filters`)
 - Stopped slugifying the title for the parameter name since it'll most
 likely be a `ugettext_lazy` variable. Instead the `parameter_name` is now
 a required class attribute like the title.

-- 
Ticket URL: 
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] #15829: Provide item to sitemap template

[Django]

#15829: Provide item to sitemap template
---+--
   Reporter:  manfre   |  Owner:  manfre
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.sitemaps
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  sitemaps
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+--
Changes (by anonymous):

 * needs_tests:  1 => 0


Comment:

 Ready for checkin?

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

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

Re: [Django] #11035: urlify.js with Serbian alphabet

[Django]

#11035: urlify.js with Serbian alphabet
-+-
   Reporter:  janos  |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  slug slugify urlify
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by claudep):

 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0
 * stage:  Accepted => Ready for checkin


Comment:

 I don't think that js files are currently testable 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.

[Django] #15950: Allow ChoiceField and friends to take a callable for choices kwarg

[Django]

#15950: Allow ChoiceField and friends to take a callable for choices kwarg
-+-
 Reporter:  jdunck   |Owner:  nobody
 Type:  New feature  |   Status:  new
Milestone:   |Component:  Uncategorized
  Version:  1.3  | Severity:  Normal
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|
-+-
 Sometimes we'd like choices to be dynamic (often the result of an ORM
 query), but because models are declarative, this forces queries to run
 with Django partially loaded.

 It would be good to be able to make choices a callable so that these
 queries could be deferred until Django is fully loaded.

 I'm attaching a rough patch; if this passes design-decision, I can polish
 it up with tests.

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

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

Re: [Django] #15931: Patch for admin change form to dodge multi-db bug

[Django]

#15931: Patch for admin change form to dodge multi-db bug
-+-
   Reporter:  dchandek   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  1
   Triage Stage:  Design |Needs tests:  1
  decision needed|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by dchandek):

 Replying to [comment:2 kmtracey]:
 > You seem to have ignored all of the logic in the shortcut view that
 attempts to determine the correct site to redirect to, starting here:
 
http://code.djangoproject.com/browser/django/trunk/django/contrib/contenttypes/views.py#L28

 Yes, sorry, good catch.  In the case at hand I was dealing with a fully-
 qualified URL.  I suppose the admin view or template could check  for this
 as well, but hopefully a fix of the base bug will available soon.

-- 
Ticket URL: 
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] #15949: documentation for view password_reset_done needs changing.

[Django]

#15949: documentation for view password_reset_done needs changing.
-+---
   Reporter:  cyclops@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
-+---
Changes (by jonash):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Cleanup/optimization => Bug
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 (plus `password_reset_done` is a bad name)

-- 
Ticket URL: 
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] #15849: {% ifchanged %} not thread-safe

[Django]

#15849: {% ifchanged %} not thread-safe
+-
   Reporter:  akaihola  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
+-

Comment (by carljm):

 Replying to [comment:5 akaihola]:
 > I found an existing [http://code.djangoproject.com/changeset/8306#file3
 thread-safety test case] in the Django test suite. It's for bug #4948
 ("Saving !FileField files is not thread-safe"). Martin von Löwis also
 [http://code.djangoproject.com/ticket/4948#comment:14 described in a
 comment] how his
 [http://code.djangoproject.com/attachment/ticket/4948/t.py example script]
 demonstrated the bug.
 >
 > Do you think a similar approach could be used for testing template tags?

 In general, yes, but (not having dug into this in detail) I'm not sure
 threading is even needed to check this particular case. Seems like the
 test could just create an IfChangedNode and a couple contexts and make the
 appropriate render() calls in the right order to trigger the bug, with a
 comment indicating that this simulates an order of calls that could occur
 under threaded conditions.

-- 
Ticket URL: 
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] #13871: contrib.admin:list_editable - ForeignKey performance is O(m*n)

[Django]

#13871: contrib.admin:list_editable - ForeignKey performance is O(m*n)
-+-
   Reporter:  chadc  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:  list_editable,
 Resolution: |  admin, ForeignKey, admin efficiency
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by uriel.bertoche):

 * easy:   => 0


Comment:

 It also happens when you try to add a object that has a foreign key with
 too many possible values.
 Like, if I have a table users, with 700 entries, and a models that has
 users as a foreign key, when I try adding an entry for this models, it
 will make +700 sql queries to fill the select.

 Is there any fix for this 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 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] #15949: documentation for view password_reset_done needs changing.

[Django]

#15949: documentation for view password_reset_done needs changing.
--+---
 Reporter:  cyclops@… |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  Documentation
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  1
--+---
 
http://docs.djangoproject.com/en/1.3/topics/auth/#django.contrib.auth.views.password_reset_done

 The text reads:

 "The page shown after a user has reset their password."

 A better wording would be:

 "The page shown after a user has been emailed a link to reset their
 password. This view is called by default, if the view ''password_reset''
 was not supplied a ''post_reset_redirect'' URL.

 The exact same change applies to versions 1.2 and development branch.

-- 
Ticket URL: 
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] #15948: Regarding find_template_source()

[Django]

#15948: Regarding find_template_source()
--+-
 Reporter:  Kronuz|  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
--+-
 I still find myself in need of getting a template source, the current
 find_template returns a compiled template for the most part, and I would
 suggest keeping a working find_template_source for these edge cases as
 mine. Perhaps something like this is in place:

 {{{
 def find_template_source(name, dirs=None):
 if template_source_loaders is None:
 loaders = []
 for loader_name in settings.TEMPLATE_LOADERS:
 loader = find_template_loader(loader_name)
 if loader is not None:
 loaders.append(loader)
 template_source_loaders = tuple(loaders)
 def load_template_source(loaders):
 for loader in loaders:
 if hasattr(loader, 'loaders'):
 try:
 return load_template_source(loader.loaders)
 except TemplateDoesNotExist:
 pass
 else:
 try:
 source, display_name =
 loader.load_template_source(name, dirs)
 return (source, make_origin(display_name, loader,
 name, dirs))
 except TemplateDoesNotExist:
 pass
 raise TemplateDoesNotExist(name)
 return load_template_source(template_source_loaders)
 }}}

-- 
Ticket URL: 
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] #15918: settings.THOUSAND_SEPARATOR is used only when the current locale does not provide a value

[Django]

#15918: settings.THOUSAND_SEPARATOR is used only when the current locale does 
not
provide a value
-+-
   Reporter:  lev|  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  THOUSAND_SEPARATOR
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by lev):

 What is actually missing in the documentation is that out of 4 variables
 responsible for localized number rendering (`DECIMAL_SEPARATOR`,
 `THOUSAND_SEPARATOR`, `NUMBER_GROUPING`, `USE_THOUSAND_SEPARATOR`) only
 the last one is intended for being used in `settings.py` directly.

 The other three are supposed to be set in the corresponding `formats.py`
 files like in the example above.

 They ''can'' be set in `settings.py` but they will only be used in an
 unlikely case of the variable not set up in
 `django/conf/locale/*/formats.py` files.

 For example the very first locale, `ar`, has `DECIMAL_SEPARATOR` set, but
 it will not be used unless `NUMBER_GROUPING` (which is suspiciously
 commented out there) is set somewhere else (ie in `settings.py` or in
 `mysite/formats/ar/formats.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 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] #15918: settings.THOUSAND_SEPARATOR is used only when the current locale does not provide a value

[Django]

#15918: settings.THOUSAND_SEPARATOR is used only when the current locale does 
not
provide a value
-+-
   Reporter:  lev|  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  THOUSAND_SEPARATOR
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by lev):

 Andy, thanks for your reply. As `aaugustin` pointed out, my patch is not
 necessary in fact. Current django code is ok, it is only the documentation
 that is unclear.

 My current solution looks like this (in accordance with
 [http://docs.djangoproject.com/en/1.3/topics/i18n/localization/#format-
 localization docs]):


 {{{
 settings.py:

 FORMAT_MODULE_PATH = 'mysite.formats'
 USE_L10N = True
 USE_THOUSAND_SEPARATOR = True

 mysite/formats/ru/formats.py:

 DECIMAL_SEPARATOR = '.'

 mysite/formats/en/formats.py:

 THOUSAND_SEPARATOR = ' '

 (plus empty __init__.py in corresponding dirs of course)

 }}}

 This way I get a somewhat consistent behaviour of this feature for the
 locales I work with, which is exactly what I wanted.

-- 
Ticket URL: 
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] #15947: get_FIELD_display doesn't work when a given field is an IntegerField and is assigned a string value

[Django]

#15947: get_FIELD_display doesn't work when a given field is an IntegerField 
and is
assigned a string value
-+-
   Reporter:  phuihock   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
 |  Easy pickings:  0
-+-
Changes (by julien):

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


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

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

Re: [Django] #9015: Signal Connection Decorators

[Django]

#9015: Signal Connection Decorators
-+-
   Reporter:  zvoase |  Owner:  brosner
   Type:  New| Status:  reopened
  feature|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  signals
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by jezdez):

 * easy:   => 0


Comment:

 I've pushed a small update to my branch at
 https://github.com/jezdez/django/tree/feature%2Fsignal-decorator

-- 
Ticket URL: 
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] #15947: get_FIELD_display doesn't work when a given field is an IntegerField and is assigned a string value

[Django]

#15947: get_FIELD_display doesn't work when a given field is an IntegerField 
and is
assigned a string value
--+--
 Reporter:  phuihock  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Database layer (models, ORM)
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
--+--
 Given a model class:
 {{{
 class TestModel(models.Model):
 RATE_CHOICES = (
 (1, _('Poor')),
 (2, _('Neutral')),
 (3, _('Good')),
 )
 rate = models.IntegerField(choices=RATE_CHOICES, default=1)
 }}}

 get_rate_display fails to return the choice display value if the
 IntegerField is assigned a string value.
 {{{
 In [2]: from test.models import TestModel
 In [3]: a = TestModel()
 In [4]: a.get_rate_display()
 Out[4]: u'Poor'
 In [5]: a.rate = 2
 In [6]: a.get_rate_display()
 Out[6]: u'Neutral'
 In [7]: a.rate = '2'
 In [8]: a.get_rate_display()
 Out[8]: u'2'  # problem!
 }}}

 Since the keys of the field's flatchoices are integers, get_FIELD_display
 will fail to retrieve the corresponding display value, so it returns the
 value as it is.

 While this is obviously a user error, the subtlety of the problem is
 confusing at best. Ideally, get_FIELD_display should cast the value to the
 type the field represents before looking up the display value from the
 dictionary object.

 This is related to http://code.djangoproject.com/ticket/2136

-- 
Ticket URL: 
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] #15918: settings.THOUSAND_SEPARATOR is used only when the current locale does not provide a value

[Django]

#15918: settings.THOUSAND_SEPARATOR is used only when the current locale does 
not
provide a value
-+-
   Reporter:  lev|  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  THOUSAND_SEPARATOR
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by jezdez):

 * component:  Documentation => Internationalization


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15918: settings.THOUSAND_SEPARATOR is used only when the current locale does not provide a value

[Django]

#15918: settings.THOUSAND_SEPARATOR is used only when the current locale does 
not
provide a value
-+-
   Reporter:  lev|  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  THOUSAND_SEPARATOR
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

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


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

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

Re: [Django] #14262: Helper for "get_something as varname" template tag pattern

[Django]

#14262: Helper for "get_something as varname" template tag pattern
-+-
   Reporter:  carljm |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #15945: Thread locals note

[Django]

#15945: Thread locals note
-+-
   Reporter:  sorl   |  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  Documentation
  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  |
-+-
Changes (by jezdez):

 * stage:  Unreviewed => Design decision needed


Comment:

 Hm, in that case I defer to ubernostrum and/or russellm who edited that
 page in the past.

-- 
Ticket URL: 
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] #15918: settings.THOUSAND_SEPARATOR is used only when the current locale does not provide a value

[Django]

#15918: settings.THOUSAND_SEPARATOR is used only when the current locale does 
not
provide a value
-+-
   Reporter:  lev|  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  THOUSAND_SEPARATOR
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by andy):

 Lev, thank you for opening this ticket!

 Untill your patch got applied, one could monkey patch Django to achieve
 desired behaviour:

 {{{
 try:
 from django.utils.formats import _format_cache
 cache_key = ('THOUSAND_SEPARATOR', 'ru') # change 'ru' to your locale
 _format_cache[cache_key] = "'"
 except:
 pass # use default settings
 }}}

-- 
Ticket URL: 
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] #15945: Thread locals note

[Django]

#15945: Thread locals note
-+-
   Reporter:  sorl   |  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 There's no good reason for this page to be locked. I'm reopening so that
 someone with admin access to the Django wiki removes that lock.

-- 
Ticket URL: 
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] #15945: Thread locals note

[Django]

#15945: Thread locals note
-+-
   Reporter:  sorl   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by julien):

 Yes, it looks like it's locked. Apparently it's not the first time:
 #13207.

-- 
Ticket URL: 
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] #15945: Thread locals note

[Django]

#15945: Thread locals note
-+-
   Reporter:  sorl   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by sorl):

 Some pages are locked it seems or am I missing something obvious?

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

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

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

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  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
---+---

Comment (by julien):

 Or probably a better approach is to default `post_url_continue` to `None`:

 {{{
 #!python
 def response_add(self, request, obj, post_url_continue=None):
 ...
 if post_url_continue is None:
 post_url_continue = reverse('admin:%s_%s_change' %
 (opts.app_label, module_name),
 args=pk_value,
 current_app=self.admin_site.name)
 ...
 }}}

-- 
Ticket URL: 
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] #15933: mysql inspectdb loosing primary_key information

[Django]

#15933: mysql inspectdb loosing primary_key information
-+-
   Reporter:  andi   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
 |  Easy pickings:  0
-+-

Comment (by andi):

 I forgot to login. The previous comment is from me.

-- 
Ticket URL: 
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] #15933: mysql inspectdb loosing primary_key information

[Django]

#15933: mysql inspectdb loosing primary_key information
-+-
   Reporter:  andi   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
 |  Easy pickings:  0
-+-

Comment (by anonymous):

 I've been thinking about this patch over the weekend. The provided patch
 is ok for primary keys. If checking for uniqueness a multi-field unique
 key would mark all involved fields as unique. A single field-unique key is
 detected correct.

 I've written the following code to detect single/multi-field unique keys
 correctly:
 {{{
 def get_indexes(self, cursor, table_name):
 """
 Returns a dictionary of fieldname -> infodict for the given table,
 where each infodict is in the format:
 {'primary_key': boolean representing whether it's the primary
 key,
  'unique': boolean representing whether it's a unique index}
 """
 cursor.execute("SHOW INDEX FROM %s" %
 self.connection.ops.quote_name(table_name))
 indexes = {}
 uniques = {}
 for row in cursor.fetchall():
 if indexes.has_key(row[4]) and not
 indexes[row[4]]['primary_key']:
 indexes[row[4]]['primary_key'] = (row[2] == 'PRIMARY')
 else:
 indexes[row[4]] = {'primary_key': (row[2] == 'PRIMARY'),
 'unique': False}

 if row[2] != 'PRIMARY' and not bool(row[1]):
 if not uniques.has_key(row[2]):
 uniques[row[2]] = []
 uniques[row[2]] += [row[4],]
 unique_together=[]
 for key in uniques:
 fields = uniques[key]
 if len(fields) == 1:
 field = fields[0]
 indexes[field]['unique'] = True
 else:
 unique_together += [fields,]
 #TODO: do something with the unique_together list
 return indexes

 }}}

 I've hacked a couple of test cases together in a test-django-project to
 verify the unique and primary fields. Is there any central location within
 django where db related tests should be ?

 Also it seems that there is currently no way to pass the information of
 multi-field unique keys to the inspectdb management command?

-- 
Ticket URL: 
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] #15945: Thread locals note

[Django]

#15945: Thread locals note
-+-
   Reporter:  sorl   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by julien):

 Replying to [comment:2 sorl]:
 > Who manages the wiki? A comment on what to do with opinions on its
 contents would be helpful.

 Anybody can edit the wiki. If you think something needs to change in any
 of its pages, feel free to do so ;)

-- 
Ticket URL: 
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] #15945: Thread locals note

[Django]

#15945: Thread locals note
-+-
   Reporter:  sorl   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by jezdez):

 The wiki is managed by the community.

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

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

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

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  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
---+---

Comment (by julien):

 To clarify my comment above about #5925: it was specifically about the
 `post_url_continue` parameter in the `response_add` method's signature:

 {{{
 #!python
 def response_add(self, request, obj, post_url_continue='../%s/'):
 ...
 }}}

 Ideally `post_url_continue` should take the reversed URL for the change
 view instead of the hardcoded `'../%s/'`. Initially I thought that the
 `reverse_lazy()` introduced by #5925 may help, but the problem is that
 there's no way of finding out the new object's pk or even it's app label
 or model name from the method's signature. Maybe an approach would be to
 allow passing a callable as `post_url_continue`, for example:

 {{{
 #!python

 def post_url_continue(request, modeladmin, obj):
 opts = obj._meta
 return reverse('admin:%s_%s_changelist' %
(opts.app_label, opts.module_name),
current_app=modeladmin.admin_site.name)

 class ModelAdmin(BaseModelAdmin):

 ...

 def response_add(self, request, obj,
 post_url_continue=post_url_continue):
 ...
 if callable(post_url_continue):
 post_url_continue = post_url_continue(request, self, obj)
 ...
 }}}

 Such an approach could be generalised for the other redirection urls
 suggested in #8001.

-- 
Ticket URL: 
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] #15945: Thread locals note

[Django]

#15945: Thread locals note
-+-
   Reporter:  sorl   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by sorl):

 * cc: sorl (added)


Comment:

 Who manages the wiki? A comment on what to do with opinions on its
 contents would be helpful.

-- 
Ticket URL: 
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] #15946: Exceptions used for program logic db/utils.py load_backend

[Django]

#15946: Exceptions used for program logic db/utils.py load_backend
+--
 Reporter:  sgronblo@…  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Database layer (models, ORM)
  Version:  1.2 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
+--
 I noticed this problem when trying to figure out why one of my views
 wouldn't load. The problem there seems to be that it catches both
 ImportErrors and AttributeErrors in the same catch. I tried modifying the
 code to explode at when import_module calls __import__ instead but then
 Django stopped working.

 This is because of how db/utils.py's load_backend tries to determine if
 you have used a non-package-prefixed name when specifying your db backend.
 load_backend does this by blindly prefixing the provded backend name with
 django.db.backends and then importing it. If the import succeeds Django
 thinks you used the short name and if it fails Django thinks you specified
 the prefixed name.

 It would probably have been better to just check if the module name begins
 with django.db.backends or not instead of relying on import
 success/failure?

-- 
Ticket URL: 
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] #15945: Thread locals note

[Django]

#15945: Thread locals note
-+-
   Reporter:  sorl   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

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


Comment:

 The wiki isn't part of Django's official documentation.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15945: Thread locals note

[Django]

#15945: Thread locals note
--+---
 Reporter:  sorl  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  Documentation
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
--+---
 The page http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser
 inaccurately describes the solution as a (huge) security risk, read more:
 http://groups.google.com/group/django-
 users/browse_thread/thread/e7af359d7d183e04

-- 
Ticket URL: 
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] #12884: Allow a FormWizard to go backward through the form list

[Django]

#12884: Allow a FormWizard to go backward through the form list
-+-
   Reporter:  Anand  |  Owner:  nobody
  Kumria | Status:  new
   Type:  New|  Component:  contrib.formtools
  feature|   Severity:  Normal
  Milestone: |   Keywords:  form wizard patch
Version:  SVN|  backwards
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  1  |
-+-
Changes (by valyagolev):

 * cc: me@… (added)
 * easy:   => 0


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

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