Re: [Django] #5515: Custom Permission Denied Pages

[Django]

#5515: Custom Permission Denied Pages
+---
  Reporter:  Piotr Lewandowski   | 
Owner: 
Status:  reopened   | 
Milestone: 
 Component:  Contrib apps   |   
Version:  SVN
Resolution: |  
Keywords: 
 Stage:  Design decision needed | 
Has_patch:  1  
Needs_docs:  0  |   
Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by russellm):

 The reason there has been no movement in 10 months is that nobody has been
 driving the issue. If you want it, you have to advocate for it.  Also, 10
 months spans almost exactly the 1.2 development cycle. At the very least,
 8 of those 10 months can be explained by the fact that nobody proposed
 this for inclusion in 1.2, so it never got on anybody's todo list.

 The ticket is currently marked as Design Decision Needed, and there are
 comments from multiple core developers that question whether this ticket
 is the right way to go; the most recent comment from Luke indicated
 several specific issues that need to be addressed.

 If you want this, you need to drive the discussion to make it happen.
 Luckily, we're about to start the 1.3 development process, so your timing
 is perfect. What you need to do is get your thoughts together and make a
 proposal on django-developers, and then drive the discussion (which may
 involve making counter proposals or writing alternate prototype patches)
 until such time as you get a core developer to sign off on the design.

 The ideal time to start this discussion will be in a little over a week --
 several of the core team will be at DjangoCon.eu, so attention will be
 elsewhere for a little bit -- but that gives you a week to get your
 thoughts together, address the issues that Luke raised, and make a
 compelling case for the change you want to see.

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

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

Re: [Django] #13511: RegexValidator pattern is optional and should be required

[Django]

#13511: RegexValidator pattern is optional and should be required
-+--
  Reporter:  davidfischer| Owner:  davidfischer 
Status:  assigned| Milestone:   
 Component:  Core framework  |   Version:  SVN  
Resolution:  |  Keywords:  validators,regexvalidator
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by davidfischer):

  * status:  new => assigned
  * has_patch:  0 => 1

Comment:

 I switched the `regex` parameter to required to match the
 [http://docs.djangoproject.com/en/1.2/ref/validators/#regexvalidator
 documentation]. While running the unit tests (forms & validation), I
 noticed that `URLValidator` relied on the fact that the `regex` parameter
 was optional by having a `regex` instance variable. I corrected that.
 However, this brings up a potential backwards compatibility issue.

 The issue with this patch is that anybody who subclassed `RegexValidator`
 and relied on `regex` to be optional will have to update their code.
 However, it should be pretty obvious what went wrong and they probably
 should not have done that in the first place. I'm not sure how strict to
 be on maintaining backwards compatibility, but I think that breaking it in
 this small way will result in the cleanest code.

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

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

Re: [Django] #13582: multiple files uploaded with same name are not iterable

[Django]

#13582: multiple files uploaded with same name are not iterable
---+
  Reporter:  anonymous | Owner:  nobody 
Status:  closed| Milestone: 
 Component:  File uploads/storage  |   Version: 
Resolution:  invalid   |  Keywords:  multiple files POST
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 `__getitem__` only returns the last value for multi-valued keys. See:
 http://docs.djangoproject.com/en/dev/ref/request-
 response/#django.http.QueryDict.__getitem__

 To get a list of all the values, you want to use
 `request.FILES.getlist('image')`. See:
 http://docs.djangoproject.com/en/dev/ref/request-
 response/#django.http.QueryDict.getlist

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

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

Re: [Django] #4027: ability to make a copies of model instances

[Django]

#4027: ability to make a copies of model instances
---+
  Reporter:  Marek Kubica  | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:|  Keywords:  db, copy
 Stage:  Design decision needed| Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by forest):

 * cc: forest (added)

Comment:

 Hi Luke,

 My patch does not rely on setting self.id to None.

 I will try to bring this ticket up on the mailing list.  Perhaps it can be
 fixed in 1.3.

 Thanks,
 Forest

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

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

Re: [Django] #11665: django.test.TestCase should flush constraints

[Django]

#11665: django.test.TestCase should flush constraints
+---
  Reporter:  Glenn  | Owner: 
Status:  new| Milestone: 
 Component:  Testing framework  |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by forest):

 * cc: for...@alittletooquiet.net (removed)
 * cc: forest (added)

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

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

Re: [Django] #12979: TestCase disables savepoint_commit, savepoint_rollback

[Django]

#12979: TestCase disables savepoint_commit, savepoint_rollback
+---
  Reporter:  forest | Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by forest):

 * cc: forest (added)

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

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

Re: [Django] #11557: get_latest_by should support multiple columns via tuple like ordering

[Django]

#11557: get_latest_by should support multiple columns via tuple like ordering
---+
  Reporter:  forest| Owner:  nobody 
   
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.0
   
Resolution:|  Keywords:  
get_latest_by ordering
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by forest):

 * cc: forest (added)

Comment:

 Is my patch acceptable?  It'd be great to see this in 1.3.

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

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

Re: [Django] #13582: multiple files uploaded with same name are not iterable

[Django]

#13582: multiple files uploaded with same name are not iterable
---+
  Reporter:  anonymous | Owner:  nobody 
Status:  new   | Milestone: 
 Component:  File uploads/storage  |   Version: 
Resolution:|  Keywords:  multiple files POST
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

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

Comment:

 FYI I am using Django 1.2

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

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

[Django] #13582: multiple files uploaded with same name are not iterable

[Django]

#13582: multiple files uploaded with same name are not iterable
--+-
 Reporter:  anonymous |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  File uploads/storage  | Version:
 Keywords:  multiple files POST   |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I am uploading a sound file with multiple images files associated using
 curl like this:

 {{{
 curl -X POST http://localhost:8000/analysis/test_post/ -F "fi...@6.3gp" -v
 -F "ima...@d1e98eee-f5af-41b1-9974-9d209816f2d3.jpg" -F "ima...@gyoza.jpg"
 }}}

 and here is what I get if I put a breakpoint and play with an ipython
 shell:
 {{{
 In [1]: request.FILES
 Out[1]: ,
 ],
  u'file': []}>

 In [2]: request.FILES.keys()
 Out[2]: [u'image', u'file']

 In [3]: request.FILES.values()
 Out[3]:[,
 ]

 In [4]: request.FILES['image']
 Out[4]: 
 }}}

 As you can see I only have one file when I query the dictionnary-like
 {{{request.POST}}} object hence I cannot iterate over it which is what I
 want to do.

 Note that this ticket is similar to #12446 but I am using curl to do the
 upload as specified in their manual (at
 http://www.cs.sunysb.edu/documentation/curl/index.html):
 {{{
 To send two files in one post you can do it in two ways:
 1. Send multiple files in a single "field" with a single field name:
 curl -F "pictur...@dog.gif,cat.gif"
 2. Send two fields with two field names:
 curl -F "docpictu...@dog.gif" -F "catpictu...@cat.gif"
 }}}
 Both fail.

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

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

Re: [Django] #12979: TestCase disables savepoint_commit, savepoint_rollback

[Django]

#12979: TestCase disables savepoint_commit, savepoint_rollback
+---
  Reporter:  forest | Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by forest):

 No, #12087 deals with TransactionTestCase whereas this ticket is specific
 to TestCase.

 Russell, does my patch look okay?

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

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

Re: [Django] #5515: Custom Permission Denied Pages

[Django]

#5515: Custom Permission Denied Pages
+---
  Reporter:  Piotr Lewandowski   | 
Owner: 
Status:  reopened   | 
Milestone: 
 Component:  Contrib apps   |   
Version:  SVN
Resolution: |  
Keywords: 
 Stage:  Design decision needed | 
Has_patch:  1  
Needs_docs:  0  |   
Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by paulc):

 * cc: pa...@mozilla.com (added)

Comment:

 Hey everyone,

 There seems to have been no movement on this in the past 10 months. We
 have two major projects at Mozilla using Django (addons.mozilla.org and
 support.mozilla.com). These 403 handlers with templates would come in
 handy. So here are my questions:

 1) What's keeping this patch from landing? IMO, it makes sense to add 403
 handlers treated similarly to 404 and 500 ones.

 2) Is there anything I can do to help? We're running Django trunk (because
 we love all the new features you guys added), so I'd be interested to have
 it work with 1.2

 3) If this can't be landed anytime soon, what would you do as a workaround
 if you wanted a 403.html template (also to work with Jinja since we're
 using that).


 Thanks a lot and hope to hear from you soon.


 PS: Django is awesome.

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

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

Re: [Django] #12751: order_by after select_related returns empty queryset

[Django]

#12751: order_by after select_related returns empty queryset
---+
  Reporter:  ozguri...@gmail.com   | Owner:  nobody 
 
Status:  closed| Milestone:  1.2
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:  worksforme|  Keywords:  order_by, 
select_related
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by jashugan):

 To clarify the above:

 The database schema allowed for null values for the user_id column, and
 all the products in the database had null values.  When I changed set the
 user field for one of the records, it began appearing in the
 select_related queries.  I don't think this is a problem with Django, just
 something to watch out for when your database schema doesn't match your
 model definition.

 {{{
 #!python
 In [1]: import store.models as store_m

 In [2]: store_m.Product.objects.select_related()
 Out[2]: []

 In [3]: store_m.Product.objects.select_related().count()
 Out[3]: 128008

 In [4]: import django.contrib.auth.models as auth_m

 In [5]: prod = store_m.Product.objects.all()[0]

 In [6]: prod.created_by = auth_m.User.objects.get(username='jashugan')

 In [7]: prod.save()

 In [8]: prod_m.Product.objects.select_related()
 Out[8]: []
 }}}

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

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

Re: [Django] #12751: order_by after select_related returns empty queryset

[Django]

#12751: order_by after select_related returns empty queryset
---+
  Reporter:  ozguri...@gmail.com   | Owner:  nobody 
 
Status:  closed| Milestone:  1.2
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:  worksforme|  Keywords:  order_by, 
select_related
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by jashugan):

 I had the same symptoms as this problem. I believe the problem was related
 to a foreign key in the model having the not null constraint, like so:

 {{{
 #!python
 from django.db import models
 import django.contrib.auth.models as auth_m

 class Product(models.Model):
   # by default null is False
   user = models.ForeignKey(auth_m.User)
 }}}

 The database schema, however, had all null values for the user field. The
 query wasn't able to follow the null values for any of the fields, so it
 returned no records.

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

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

[Django] #13581: improve naming of defa ult coordinates for GeoModelAdmin¶

[Django]

#13581: improve naming of default coordinates for GeoModelAdmin¶
---+
 Reporter:  tylere |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords:  GeoModelAdmin  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The GeoModelAdmin class currently has properties of default_lon and
 default_lat.  While these are reasonable names when using an unprojected
 coordinate system, they are misleading if a subclass with another
 projection is used (such as the spherical mercator projection used by the
 class OSMGeoAdmin).  This may lead to confused users, for example:
 http://code.djangoproject.com/ticket/11094.

 I would suggest changing the default coordinate names to default_x and
 default_y.

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

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

Re: [Django] #607: Admin option to show/hide fields

[Django]

#607: Admin option to show/hide fields
---+
  Reporter:  wilson| Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:
Resolution:  wontfix   |  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by carljm):

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

Comment:

 Please don't just reopen tickets closed by a core developer; bring it up
 on the django-developers mailing list instead.

 This is quite possible to build in a generic and reusable way external to
 Django, using a ModelForm and/or a ModelAdmin subclass and the forms.Media
 framework, so there is no need for Django to include it (and if Django
 ever did include it, it would be because it first got very popular as an
 external project).

 "How" questions should go to #django, django-users, etc.

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

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

Re: [Django] #1028: High-level feed framework should make more feed elements available

[Django]

#1028: High-level feed framework should make more feed elements available
+---
  Reporter:  ubernostrum| Owner:  taojian
Status:  new| Milestone: 
 Component:  RSS framework  |   Version:  1.2-alpha  
Resolution: |  Keywords:  feature_request
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  1  |  
+---
Changes (by anonymous):

  * version:  SVN => 1.2-alpha

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

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

Re: [Django] #607: Admin option to show/hide fields

[Django]

#607: Admin option to show/hide fields
---+
  Reporter:  wilson| Owner:  nobody
Status:  reopened  | Milestone:
 Component:  django.contrib.admin  |   Version:
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

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

Comment:

 Hi - I'm reopening this because the rationale for closing it was that it
 would be possible to do with newforms... As far as I can tell this isn't
 straightforward with the current admin, although I'd be happy to stand
 corrected.

 I can think of a number of use-cases for this, and am about to start very
 inexpertly hacking the admin page javascript for want of a better
 solution.

 B

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

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

Re: [Django] #13580: Change form.name_of_field.errors to form.errors in doc

[Django]

#13580: Change form.name_of_field.errors  to form.errors in doc
+---
  Reporter:  buddelki...@gmail.com  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

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

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

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

[Django] #13580: Change form.name_of_field.errors to form.errors in doc

[Django]

#13580: Change form.name_of_field.errors  to form.errors in doc
---+
 Reporter:  buddelki...@gmail.com  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I think at http://docs.djangoproject.com/en/dev/topics/forms/#customizing-
 the-form-template

 {{{
 Using {{ form.name_of_field.errors }}  displays a list of form errors,
 rendered as an unordered list.
 }}}

 needs to be changed to

 {{{
 Using {{ form.errors }}  displays a list of form errors, rendered as an
 unordered list.
 }}}

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

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

[Django] #13579: None gets ignored by __in filter

[Django]

#13579: None gets ignored by __in filter
--+-
 Reporter:  outofculture  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 {{{
 from django.db import models

 class A(models.Model):
   b = models.ForeignKey(B, null=True)

 class B(models.Model):
   pass

 for _ in range(0,10):
   A.objects.create()

 b = B.objects.create()
 A.objects.create(b=b)

 A.objects.filter(b=None).count()  # => 10
 A.objects.filter(b__in=[None,]).count() # => 0 (should be 10)
 A.objects.filter(b__in=[None,b]).count() # => 1 (should be 11)
 A.objects.filter(b__in=[b,None]).count() # => 1 (should be 11)
 }}}

 I haven't tested with the above code exactly, but this is the failing
 behavior I'm seeing.

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

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

[Django] #13578: Hack to prevent project files (passwords, etc.) from being served by some Apache (RFE)

[Django]

#13578: Hack to prevent project files (passwords, etc.) from being served by 
some
Apache (RFE)
-+--
 Reporter:  JonathanHayward  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Documentation| Version:  1.1   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 For
 http://docs.djangoproject.com/en/dev/intro/tutorial01/#creating-a-project
 , users are strongly advised to store project files outside the
 directories served up by a server.

 I'm not sure whether this should be advised in the documentation, but for
 Apache, if AllowOverride is enabled as it often is, a .htaccess file that
 contains a syntax error will cause an error page to be displayed on
 attempted access. If such a .htaccess file is included, there is an extra
 layer of protection. (This could be advised in the documentation or
 include in startproject).

 Jonathan, http://JonathansCorner.com

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

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

Re: [Django] #7028: Better raw_id_fields feedback in newform-admins branch

[Django]

#7028: Better raw_id_fields feedback in newform-admins branch
---+
  Reporter:  Marcob   | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  django.contrib.admin  |   Version:  SVN

Resolution:|  Keywords:  
raw-id-fields nfa-someday design_ux
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  1  

Needs_better_patch:  1 |  
---+
Comment (by mrts):

 `getAdminMediaPrefix()` is unneccessary in 1.2. See #11967 and [13002].
 Use `if (window.__admin_media_prefix__ != undefined) { ...` etc.

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

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

Re: [Django] #13562: values() cannot follow reverse one-to-one relationship

[Django]

#13562: values() cannot follow reverse one-to-one relationship
+---
  Reporter:  bendavis78 | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Alex):

 Bah you're totally right about that, sorry for my confusion :)

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

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

Re: [Django] #13562: values() cannot follow reverse one-to-one relationship

[Django]

#13562: values() cannot follow reverse one-to-one relationship
+---
  Reporter:  bendavis78 | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by bendavis78):

 Alex, I'm a bit confused why you're asking about nullable foreign keys --
 If Place had, eg, {{{owner = ForeignKey(Owner,null=True,blank=True)}}},
 and if we did {{{Place.objects.values('owner')}}},  we'd get {{{
 [{'owner': None}, {'owner': 1}] }}}.  The reverse of that, of course,
 wouldn't make sense, since it's a many-to-one relationship.

 Regardless, I would argue that in no case should .values() alter the
 number of rows returned in the result set.  We expect the same of
 .select_related(), so I don't see why .values() should behave differently.

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

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

[Django] #13577: New Polish L10N formats file

[Django]

#13577: New Polish L10N formats file
--+-
 Reporter:  ludwik|   Owner:  zgoda 
   Status:  new   |   Milestone:
Component:  Translations  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Updated Polish formats.py file, taking advantage of new L10N features in
 Djnago 1.2.

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

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

Re: [Django] #5390: Add signals to ManyRelatedManager

[Django]

#5390: Add signals to ManyRelatedManager
--+-
  Reporter:  Ludovico Magnocavallo   | Owner:  
rvdrijst   
Status:  closed   | Milestone:  1.2 
   
 Component:  Database layer (models, ORM) |   Version:  SVN 
   
Resolution:  fixed|  Keywords:  
manytomanyfield feature signals
 Stage:  Design decision needed   | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  1|  
--+-
Comment (by frans):

 good point. Sorry for the confusion, I should have done my homework
 better.

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

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

[Django] #13576: Found a bug of checking permission rules in django.contrib.admin.actions.delete_selected

[Django]

#13576: Found a bug of checking permission rules in
django.contrib.admin.actions.delete_selected
--+-
 Reporter:  peli...@gmail.com |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:  permissions actions   |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 In case of custom ModelAdmin.has_delete_permission method implementation
 we can use "obj=None" argument to make decision. But
 django.contrib.admin.actions.delete_selected method by some reason does
 not check permission rules for each of its queryset object.

 Simple patch is added to this ticket.

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

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

Re: [Django] #11319: ForeignKey filters use the wrong field to prepare values for database

[Django]

#11319: ForeignKey filters use the wrong field to prepare values for database
---+
  Reporter:  russellm  | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 #13574 reported the same issue as #13343 and contained a patch with tests
 fixing the particular m2m case.

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

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

Re: [Django] #13574: ManyToManyFields using through won't respect to_field parameter in ForeignKey fields

[Django]

#13574: ManyToManyFields using through won't respect to_field parameter in
ForeignKey fields
---+
  Reporter:  aitorciki | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Comment:

 Duplicate of #13343 that was closed in favor of #11319. I will add a note
 there pointing to this ticket.

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

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

Re: [Django] #5390: Add signals to ManyRelatedManager

[Django]

#5390: Add signals to ManyRelatedManager
--+-
  Reporter:  Ludovico Magnocavallo   | Owner:  
rvdrijst   
Status:  closed   | Milestone:  1.2 
   
 Component:  Database layer (models, ORM) |   Version:  SVN 
   
Resolution:  fixed|  Keywords:  
manytomanyfield feature signals
 Stage:  Design decision needed   | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  1|  
--+-
Comment (by russellm):

 No, you shouldn't reopen the ticket. This "problem" is an orthogonal
 change/optimization reported as #6707. The extent to which this is a
 "problem" was discussed in #13022.

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

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

Re: [Django] #5390: Add signals to ManyRelatedManager

[Django]

#5390: Add signals to ManyRelatedManager
--+-
  Reporter:  Ludovico Magnocavallo   | Owner:  
rvdrijst   
Status:  closed   | Milestone:  1.2 
   
 Component:  Database layer (models, ORM) |   Version:  SVN 
   
Resolution:  fixed|  Keywords:  
manytomanyfield feature signals
 Stage:  Design decision needed   | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  1|  
--+-
Comment (by frans):

 I certainly don't want to be a killjoy but it looks like r12223 still uses
 the following for set()
 {{{
 #!python
 manager.clear()
 manager.add(*value)
 }}}
 instead of
 {{{
 #!python
 previous=set(manager.all())
 new=set(value)
 if not new:
   manager.clear()
 else:
   added=new-previous
   removed=previous-new
 if added :
   manager.add(*added)
 if removed :
   manager.remove(*removed)
 }}}
 which may lead, unless I'm missing something, to the problems listed in
 [comment:40:ticket:5390 my initial comment] and [comment:52:ticket:5390
 Xiaket's]

 If this is right, should we reopen the ticket?

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

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

Re: [Django] #13560: SplitDateTimeField(localize=True) fails as value gets converted to string

[Django]

#13560: SplitDateTimeField(localize=True) fails as value gets converted to 
string
+---
  Reporter:  David Danier   | Owner:  
nobody  
Status:  new| Milestone:
  
 Component:  Forms  |   Version:  
1.2 
Resolution: |  Keywords:  
localization, SplitDateTimeField, regression
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

  * 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13575: nb/nn locale not a valid python locale

[Django]

#13575: nb/nn locale not a valid python locale
---+
  Reporter:  oyvind| Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  Internationalization  |   Version:  SVN
  
Resolution:  worksforme|  Keywords:  locale python nb 
nn norwegian nynorsk
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by jezdez):

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

Comment:

 Can't reproduce this, probably missing locales in the OS.

 http://gist.github.com/407493

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

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

Re: [Django] #13575: nb/nn locale not a valid python locale

[Django]

#13575: nb/nn locale not a valid python locale
---+
  Reporter:  oyvind| Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Internationalization  |   Version:  SVN
  
Resolution:|  Keywords:  locale python nb 
nn norwegian nynorsk
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by oyvind):

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

Comment:

 Correction:

 The reason for this is that neither "nb" or "nn" is in
 locale.locale_alias.

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

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

[Django] #13575: nb/nn locale not a valid python locale

[Django]

#13575: nb/nn locale not a valid python locale
---+
 Reporter:  oyvind |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Internationalization   | Version:  SVN   
 Keywords:  locale python nb nn norwegian nynorsk  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 If this code is run in the django shell:

 {{{
 #!python

 from django.utils.translation.trans_real import get_language_from_request

 g = get_language_from_request
 from django.http import HttpRequest

 r = HttpRequest()
 r.COOKIES = {}
 r.META = {'HTTP_ACCEPT_LANGUAGE': 'nb,nn;q=0.7,en;q=0.3'}

 g(r)

 }}}

 The returned language code is "en".

 The reason for this is that neither "no" or "nn" is in
 locale.locale_alias.

 Attaching temporary fix.

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

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

[Django] #13574: ManyToManyFields using through won't respect to_field parameter in ForeignKey fields

[Django]

#13574: ManyToManyFields using through won't respect to_field parameter in
ForeignKey fields
--+-
 Reporter:  aitorciki |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 When a ManyToManyField is set to use an existing model with ''through'',
 Django will fail to generate the correct SQL if a ForeignKey in this model
 is using ''to_field'' to relate to a field other than the primary key of
 the target table. That happens because m2m handling code is always
 assuming that the relation if with the target table primary key.

 For models like the following:

 {{{
 class Author(models.Model):
 name = models.CharField(max_length=50, unique=True)

 class Book(models.Model):
 title = models.CharField(max_length=50, unique=True)
 authors = models.ManyToManyField(Author, through='BookToAuthor')

 class BookToAuthor(models.Model):
 author = models.ForeignKey(Author, db_column='author_name',
 to_field='name')
 book = models.ForeignKey(Book, db_column='book_title',
 to_field='title')
 }}}

 The generated SQL for an book object (id = 1) access to authors attribute
 is

 {{{
 SELECT `author`.`id`, `author`.`name` FROM `author` INNER JOIN
 `booktoauthor` ON (`author`.`id` = `booktoauthor`.`author_name`) WHERE
 `booktoauthor`.`book_title` = 1
 }}}

 while the expected one is

 {{{
 SELECT `author`.`id`, `author`.`name` FROM `author` INNER JOIN
 `booktoauthor` ON (`author`.`name` = `booktoauthor`.`author_name`) INNER
 JOIN `book` ON (`booktoauthor`.`book_title` = `book`.`title`) WHERE
 `book`.`id` = 1
 }}}

 I attach a patch that uses the relation field_name attribute instead of
 assuming that the primary key is to be used.

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

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

[Django] #13573: Cached template loader can return incorrect template

[Django]

#13573: Cached template loader can return incorrect template
-+--
 Reporter:  lamby|   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Template system  | Version:  1.2   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 The cached.Loader's `find_template` method constructs a cache key based
 solely on the requested template name and does not include the
 `template_dirs`. This results in `find_template` returning the incorrect
 template where a  template with the same `template_name` was previously
 loaded and cached from a different set of `template_dirs`. That is to say,
 the function is overly non-injective.

 For example, the following snippets return the __same__ `Template`. when
 they should return a different template for `templates/foo/file.html` and
 `templates/bar/file.html` respectfully:

 {{{
 #!python
 from django.template import loader
 a = loader.find_template('file.html', ('templates/foo',))
 b = loader.find_template('file.html', ('templates/bar',))
 }}}

 Patch attached.

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

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

Re: [Django] #13560: SplitDateTimeField(localize=True) fails as value gets converted to string

[Django]

#13560: SplitDateTimeField(localize=True) fails as value gets converted to 
string
+---
  Reporter:  David Danier   | Owner:  
nobody  
Status:  new| Milestone:
  
 Component:  Forms  |   Version:  
1.2 
Resolution: |  Keywords:  
localization, SplitDateTimeField, regression
 Stage:  Accepted   | Has_patch:  0 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

  * component:  Uncategorized => Forms
  * 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11686: Support for gettext's contexts

[Django]

#11686: Support for gettext's contexts
---+
  Reporter:  mitar | Owner:  nobody
Status:  closed| Milestone:
 Component:  Internationalization  |   Version:  1.1   
Resolution:  wontfix   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by bronger):

 * cc: bron...@physik.rwth-aachen.de (added)

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

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

Re: [Django] #811: [patch] IPv6 address field support

[Django]

#811: [patch] IPv6 address field support
-+--
  Reporter:  mattimust...@gmail.com  | Owner:  adrian
Status:  reopened| Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Johann Queuniet ):

  * 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13560: SplitDateTimeField(localize=True) fails as value gets converted to string

[Django]

#13560: SplitDateTimeField(localize=True) fails as value gets converted to 
string
+---
  Reporter:  David Danier   | Owner:  
nobody  
Status:  new| Milestone:
  
 Component:  Uncategorized  |   Version:  
1.2 
Resolution: |  Keywords:  
localization, SplitDateTimeField, regression
 Stage:  Unreviewed | Has_patch:  0 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by just an idea):

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

Comment:

 perhaps it would be best to move localization into the widget at all,
 because l10n should not change the state of the internal values (inside
 field or boundfield), but only it's representation in the frontend
 (widget).

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

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