[Django] #23810: Passing 'start' from django url gives error “start() takes exactly 2 arguments (1 given) ”

2014-11-12 Thread Django
#23810: Passing 'start' from django url gives error “start() takes exactly 2
arguments (1 given) ”
-+
 Reporter:  yogeshdmca   |  Owner:  yogesh
 Type:  Bug  | Status:  new
Component:  Core (URLs)  |Version:  1.6
 Severity:  Normal   |   Keywords:  django-url
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 unfortunately i am getting a unexpected error in Django. I have a this
 urls :


 {{{
 urlpatterns += patterns('ads.search',
 url(r'^getsubcategories/$', 'getsubcategories',
 name="getsubcategories"),
 url(r'^anuncios/([\w\-]+)/$', 'anuncios_search',
 name="anuncios_search"),
 )
 }}}

 When I am going to call url "anuncios_search" this will work for all
 search patterns accept "/anuncios/start/", please see below for working
 urls:

 examples:

 1) /anuncios/avc/ : this works.

 2) /anuncios/finds/: this works .

 3) /anuncios/start-day/: this works .

 4) /anuncios/starts/: this works .

 5) /anuncios/start/: this url throwing me error :


 {{{
 Internal Server Error: /anuncios/start/
 Traceback (most recent call last):
   File "/home/yogesh/ENV/munda/local/lib/python2.7/site-
 packages/django/core/handlers/base.py", line 114, in get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
 TypeError: start() takes exactly 2 arguments (1 given)
 [13/Nov/2014 05:36:57] "GET /anuncios/start/ HTTP/1.1" 500 11496
 }}}

 my views.py is :


 {{{
 def anuncios_search(request,search_text=None):
 """
 This method for home page search, for acept contactos category
 """
 if search_text:
 search_text_list = [i for i in search_text.split("-") if len(i)>2]
 else:
 search_text_list=[]

 ads =
 
Ad.objects.exclude(subcategory__category__adult=True,user__is_active=True).order_by('-active','-republishDate')
 if search_text_list:
 ads = ads.filter(
 reduce(lambda x, y: x | y, [Q(title__icontains=word) for word
 in search_text_list])|
 reduce(lambda x, y: x | y, [Q(description__icontains=word) for
 word in search_text_list])
 ).order_by('-active','-republishDate')

 current_filters=
 {'current_category':None,'ads':ads_paginator(request,ads)}
 current_filters['search_text'] = search_text and "
 ".join(search_text.split("-")) or None
 current_filters['search_text_list'] = search_text_list and
 search_text_list or None
 return render(request,'search/search.html',current_filters)
 }}}

 Please help me to resolve this bug.
 Thanks in advance

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.2a8a75f23de214ef45aafb236111733b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23809: Update Localflavor docs

2014-11-12 Thread Django
#23809: Update Localflavor docs
-+-
 Reporter:  shabda   |Owner:  shabda
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.7
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by shabda):

 * has_patch:  0 => 1


Comment:

 PR at: https://github.com/django/django/pull/3505

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.309d4a5e7516da9f091a6d448e9160bc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23809: Update Localflavor docs

2014-11-12 Thread Django
#23809: Update Localflavor docs
-+-
 Reporter:  shabda   |Owner:  shabda
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.7
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by shabda):

 * owner:  nobody => shabda
 * needs_better_patch:   => 0
 * status:  new => assigned
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.52282bd1f4e7eb4dd541280d7e565265%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #23809: Update Localflavor docs

2014-11-12 Thread Django
#23809: Update Localflavor docs
--+
 Reporter:  shabda|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 The localflavor docs hasn't been updated since Jul 29, 2013. It should be
 updated to refer to current state.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.affc3cb0c1a242c5c18bdfe764b65cf6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23806: settings.DISALLOWED_USER_AGENTS has no tests

2014-11-12 Thread Django
#23806: settings.DISALLOWED_USER_AGENTS has no tests
--+
 Reporter:  timgraham |Owner:  sww
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by sww):

 * owner:  nobody => sww
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.25427149e0c4cf3c83a50d9d3acd167f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #13956: Indefinite args for simpletags and inclusion tags

2014-11-12 Thread Django
#13956: Indefinite args for simpletags and inclusion tags
-+-
 Reporter:  melinath |Owner:  julien
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  simple_tag,  | Triage Stage:  Ready for
  simpletag, varargs |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by collinanderson):

 Hi! Thanks for the patch. Could you open a separate ticket for this and
 maybe link the two together because they're related?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.cd9050e25486892c73c5bb1f22b76e6f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23802: Typos in 1.7 release notes

2014-11-12 Thread Django
#23802: Typos in 1.7 release notes
---+--
 Reporter:  aruseni|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by wraus):

 I'm guessing the first sentence is "results"- you have "any clashing
 fields (...) results", which is incorrect, and should read "any clashing
 fields (...) result". Not sure what the issue is in the third sentence.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.1a5b9cda50a3722a71c6b0abf55dd80c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #2445: [patch] allow callable values for limit_choices_to

2014-11-12 Thread Django
#2445: [patch] allow callable values for limit_choices_to
-+-
 Reporter:  michael@…|Owner:  Tim
 Type:  New feature  |  Graham 
Component:  Core (Other) |   Status:  closed
 Severity:  Normal   |  Version:  master
 Keywords:  sprint2013   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Baptiste Mispelon ):

 In [changeset:"606c57a132a1e1e680853c014efc41110ee75a80"]:
 {{{
 #!CommitTicketReference repository=""
 revision="606c57a132a1e1e680853c014efc41110ee75a80"
 [1.7.x] Fixed #23795 -- Fixed a regression in custom form fields

 Custom form fields having a `queryset` attribute but no
 `limit_choices_to` could no longer be used in ModelForms.

 Refs #2445.

 Thanks to artscoop for the report.

 Backport of bfb11b95626f39e2f5e18d97d7761c6f93dcc1a9 from master.

 Conflicts:
 django/forms/fields.py
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/079.83bfcdea89578ede4cf09cd0722ca789%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23795: Django form fields : limit_choices_to should not be mandatory with queryset

2014-11-12 Thread Django
#23795: Django form fields : limit_choices_to should not be mandatory with 
queryset
-+-
 Reporter:  artscoop |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.7
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  formfield,   | Triage Stage:  Ready for
  queryset, limit_choices_to |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Baptiste Mispelon ):

 In [changeset:"606c57a132a1e1e680853c014efc41110ee75a80"]:
 {{{
 #!CommitTicketReference repository=""
 revision="606c57a132a1e1e680853c014efc41110ee75a80"
 [1.7.x] Fixed #23795 -- Fixed a regression in custom form fields

 Custom form fields having a `queryset` attribute but no
 `limit_choices_to` could no longer be used in ModelForms.

 Refs #2445.

 Thanks to artscoop for the report.

 Backport of bfb11b95626f39e2f5e18d97d7761c6f93dcc1a9 from master.

 Conflicts:
 django/forms/fields.py
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.d8d12b8ed443f7ab9563c424a4949615%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #2445: [patch] allow callable values for limit_choices_to

2014-11-12 Thread Django
#2445: [patch] allow callable values for limit_choices_to
-+-
 Reporter:  michael@…|Owner:  Tim
 Type:  New feature  |  Graham 
Component:  Core (Other) |   Status:  closed
 Severity:  Normal   |  Version:  master
 Keywords:  sprint2013   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Baptiste Mispelon ):

 In [changeset:"bfb11b95626f39e2f5e18d97d7761c6f93dcc1a9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="bfb11b95626f39e2f5e18d97d7761c6f93dcc1a9"
 Fixed #23795 -- Fixed a regression in custom form fields

 Custom form fields having a `queryset` attribute but no
 `limit_choices_to` could no longer be used in ModelForms.

 Refs #2445.

 Thanks to artscoop for the report.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/079.bed270dd7177791b2d5f5a500f88b027%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23795: Django form fields : limit_choices_to should not be mandatory with queryset

2014-11-12 Thread Django
#23795: Django form fields : limit_choices_to should not be mandatory with 
queryset
-+-
 Reporter:  artscoop |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.7
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  formfield,   | Triage Stage:  Ready for
  queryset, limit_choices_to |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Baptiste Mispelon ):

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


Comment:

 In [changeset:"bfb11b95626f39e2f5e18d97d7761c6f93dcc1a9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="bfb11b95626f39e2f5e18d97d7761c6f93dcc1a9"
 Fixed #23795 -- Fixed a regression in custom form fields

 Custom form fields having a `queryset` attribute but no
 `limit_choices_to` could no longer be used in ModelForms.

 Refs #2445.

 Thanks to artscoop for the report.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.8b21e0a48d3aa281c88c5d1f36c6c185%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #23808: manage.py runserver creates django_migrations without concent

2014-11-12 Thread Django
#23808: manage.py runserver creates django_migrations without concent
+
 Reporter:  jorgecarleitao  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.7
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 When you run `./manage.py runserver` on a database without
 `django_migrations` table, the command issues a `CREATE` to create the
 table.

 While this seems natural for users trying to run the server the first
 time, I would not expect a database interaction (specially a `CREATE`
 statement) from a `runserver`. The user is not being informed that the
 database is being changed.

 At least, this should be mentioned in the documentation, but IMO it is odd
 that a `runserver` is issuing `CREATE` statements.

 Of course, this is a consequence of not running `manage.py migrate`
 before.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/057.9b0a9509cf94ca114dcfabfcb035c67d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23761: Mysql validator crashes with None db_type return. - Backport of master fix to 1.7

2014-11-12 Thread Django
#23761: Mysql validator crashes with None db_type return. - Backport of master 
fix
to 1.7
-+-
 Reporter:  adepue   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  1.7
  checks)|   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  mysql db_type|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

 * owner:  nobody => timgraham
 * status:  new => assigned
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.e30793fec5b5ab70f1c0e5318e16649a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23774: Documentation on ordering by ForeignKey fields is misleading

2014-11-12 Thread Django
#23774: Documentation on ordering by ForeignKey fields is misleading
--+
 Reporter:  wolever   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"3e0d7de8a6380c5747717cf32166864a22f258d5"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3e0d7de8a6380c5747717cf32166864a22f258d5"
 [1.7.x] Fixed #23774 -- Clarified QuerySet.order_by() and related models.

 Backport of 11b7680d0e from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.fde04cf755002fcd94a9b9fa7170bacf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23774: Documentation on ordering by ForeignKey fields is misleading

2014-11-12 Thread Django
#23774: Documentation on ordering by ForeignKey fields is misleading
--+
 Reporter:  wolever   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"b078ccf8bfcd105873f13141403a6057e430463d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b078ccf8bfcd105873f13141403a6057e430463d"
 [1.6.x] Fixed #23774 -- Clarified QuerySet.order_by() and related models.

 Backport of 11b7680d0e from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.69e4c38010d24b8910a92619e3dd55ba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23774: Documentation on ordering by ForeignKey fields is misleading

2014-11-12 Thread Django
#23774: Documentation on ordering by ForeignKey fields is misleading
--+
 Reporter:  wolever   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"11b7680d0e640a7d4b1c942f74e9197b6ec924b1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="11b7680d0e640a7d4b1c942f74e9197b6ec924b1"
 Fixed #23774 -- Clarified QuerySet.order_by() and related models.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.df5a7307e2a85ddc5c88e3198af5819c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23795: Django form fields : limit_choices_to should not be mandatory with queryset

2014-11-12 Thread Django
#23795: Django form fields : limit_choices_to should not be mandatory with 
queryset
-+-
 Reporter:  artscoop |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  formfield,   | Triage Stage:  Ready for
  queryset, limit_choices_to |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0f435d9796e8732a0c3266548cf8008b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23781: Add a GeoJSON serializer

2014-11-12 Thread Django
#23781: Add a GeoJSON serializer
-+
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

 * needs_better_patch:  1 => 0


Comment:

 Fixed. Sorry, the first patch was definitely not ready.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.90a8cb81ff25624f1f2f51e51679f901%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23795: Django form fields : limit_choices_to should not be mandatory with queryset

2014-11-12 Thread Django
#23795: Django form fields : limit_choices_to should not be mandatory with 
queryset
-+-
 Reporter:  artscoop |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  formfield,   | Triage Stage:  Accepted
  queryset, limit_choices_to |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by bmispelon):

 * severity:  Normal => Release blocker
 * needs_tests:  1 => 0


Comment:

 PR with tests and docs: https://github.com/django/django/pull/3503

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.74fd49d6c707783b3d4f9748c15a720f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #23807: Postgres backend throws error when coercing psycopg2 version string to int when version contains non-numeric characters

2014-11-12 Thread Django
#23807: Postgres backend throws error when coercing psycopg2 version string to 
int
when version contains non-numeric characters
--+
 Reporter:  ryanbagwell   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The postgres backend that ships with Django expects the version string of
 psycopg2 to contain numeric characters. It then tries to coerce the string
 to a tuple, i.e. (2, 5, 4,) for '2.5.4'. This throws an error when using
 the development branch, which has a version string of '2.6.dev0' (you
 can't coerce "dev0" to a string.

 The problem method is located here:

 
https://github.com/django/django/blob/master/django/db/backends/postgresql_psycopg2/base.py#L202

 {{{
 @cached_property
 def psycopg2_version(self):
 version = psycopg2.__version__.split(' ', 1)[0]
 return tuple(int(v) for v in version.split('.'))
 }}}


 This was a problem for me due to a bug in psycopg2 that was fixed in the
 dev branch but not in the most recent release.

 I don't know how best to address it. Do other applications expect the
 version tuple to consist entirely of integers?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.b52a9db8137bd0bb11eed6ec7e8aaab6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23775: Document --bisect and --pair runtests options

2014-11-12 Thread Django
#23775: Document --bisect and --pair runtests options
---+
 Reporter:  wrwrwr |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f9213a85c312d5590158a3bef6896468f11d7a69"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f9213a85c312d5590158a3bef6896468f11d7a69"
 Fixed #23775 -- Added docs for --bisect and --pair runtests options.

 Thanks Baptiste Mispelon for review.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.eafff984332b87a598867b575f6b9fb8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #23806: settings.DISALLOWED_USER_AGENTS has no tests

2014-11-12 Thread Django
#23806: settings.DISALLOWED_USER_AGENTS has no tests
+--
   Reporter:  timgraham |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Core (Other)  |Version:  master
   Severity:  Normal|   Keywords:  afraid-to-commit
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+--
 A test for
 
[https://github.com/django/django/blob/aa77e90aa91f90c9be5fb8e492b033875545bee4/django/middleware/common.py#L50-L59
 the functionality in CommonMiddleware] should be added to
 `tests/middleware/tests.py`.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.e4edf67875977490fcc1924b222fcad3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #23805: query `first` method clears cached queryset for prefetch_related

2014-11-12 Thread Django
#23805: query `first` method clears cached queryset for prefetch_related
--+-
 Reporter:  alecklandgraf |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:  first query
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 When a cached queryset is iterated through with `prefetch_related`, if
 `.first()` is called during the iteration, a new DB query is fired off.
 This is potentially due to the LIMIT 1 `[:1]` or the `order_by` added to
 the queryset with the `first` method.

 https://github.com/django/django/blob/master/django/db/models/query.py#L518

 ex.
 {{{
 from django.db import connection
 connection.queries = []

 pizzas = Pizza.objects.all().prefetch_related('toppings')
 print len(connection.queries)  # 2

 for pizza in pizzas:
 first_topping = pizza.toppings.first()

 print len(connection.queries)  # 2 + number of pizzas
 }}}

 This fixes in my code at least:
 {{{
 from django.db import connection
 connection.queries = []

 pizzas = Pizza.objects.all().prefetch_related('toppings')
 print len(connection.queries)  # 2

 for pizza in pizzas:
 try:
 first_topping = pizza.toppings.all()[0]
 except IndexError:
 first_topping = None

 print len(connection.queries)  # 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/056.ad1f70f04eaac67d22f7f3ed32d487b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #15718: Django unquotes urls and not able to distinguish %2F and /

2014-11-12 Thread Django
#15718: Django unquotes urls and not able to distinguish %2F and /
-+-
 Reporter:  fed239   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  urls, url resolver,  | Triage Stage:
  unquote, %2F   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by gst):

 Replying to [comment:6 gst]:
 > I've ran into the exact same issue :/
 >
 > The main problem I see is that, as far as I understand actually, django
 compares the url in its url-decoded form against each possible regex
 pattern. So the problems we are encountering with '/' encoded url value
 (%2F). Though I could be wrong 'cause I've not went to check django code.

 The other possible work around, is to url-encode twice the different parts
 of the url (so that '/' would be compared as '%2F' when compared to all
 the url regex patterns and then no more problem also) that you want to
 reach and then to decode them once in the view.
 Though it seems rather special.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.9e71b98cad63ae752c25132ccb6b3bc9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23730: Incorrect reliance on SimpleCookie roundtripping

2014-11-12 Thread Django
#23730: Incorrect reliance on SimpleCookie roundtripping
---+-
 Reporter:  timgraham  |Owner:  timgraham
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"42b5e4feeacf7cfa57867bf9fd5a6046de8c1cd3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="42b5e4feeacf7cfa57867bf9fd5a6046de8c1cd3"
 Fixed #23730 -- Moved support for SimpleCookie HIGHEST_PROTOCOL pickling
 to http.cookie.

 This fix is necessary for Python 3.5 compatibility (refs #23763).

 Thanks Berker Peksag for review.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ac33be38138b906a0e69daa76d283195%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23763: Python 3.5 compatibility

2014-11-12 Thread Django
#23763: Python 3.5 compatibility
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"42b5e4feeacf7cfa57867bf9fd5a6046de8c1cd3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="42b5e4feeacf7cfa57867bf9fd5a6046de8c1cd3"
 Fixed #23730 -- Moved support for SimpleCookie HIGHEST_PROTOCOL pickling
 to http.cookie.

 This fix is necessary for Python 3.5 compatibility (refs #23763).

 Thanks Berker Peksag for review.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.d0e8b2826fcd56de0d95b0294fea6dfc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23730: Incorrect reliance on SimpleCookie roundtripping

2014-11-12 Thread Django
#23730: Incorrect reliance on SimpleCookie roundtripping
---+-
 Reporter:  timgraham  |Owner:  timgraham
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by timgraham):

 * version:  1.6 => master
 * severity:  Release blocker => Normal


Comment:

 It doesn't look like the Python fix will be backported, so this isn't so
 urgent. It will be necessary for Python 3.5 compatibility (#23763).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ac6147b07832107da34499482065b9a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23804: Add a RasterField to GeoDjango

2014-11-12 Thread Django
#23804: Add a RasterField to GeoDjango
-+
 Reporter:  yellowcap|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

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


Comment:

 (Daniel is author of https://github.com/geodesign/django-raster/)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.41769261dd4e5ab65a0b22a3206f854a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #15718: Django unquotes urls and not able to distinguish %2F and /

2014-11-12 Thread Django
#15718: Django unquotes urls and not able to distinguish %2F and /
-+-
 Reporter:  fed239   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  urls, url resolver,  | Triage Stage:
  unquote, %2F   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Any patch with tests is worth a review. But of course, we cannot promise
 it will be accepted.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.1a513b939905a48d40e48c872098677c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #15718: Django unquotes urls and not able to distinguish %2F and /

2014-11-12 Thread Django
#15718: Django unquotes urls and not able to distinguish %2F and /
-+-
 Reporter:  fed239   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  urls, url resolver,  | Triage Stage:
  unquote, %2F   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by gst):

 Replying to [comment:6 gst]:
 >
 > Wouldn't there be a possibility to tell django to compare some url regex
 pattern against the original url value in its non-decoded form ??

 that would be a feature request, what about if I try to make a patch about
 it ? would it have chances to be at least reviewed ?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.d756fb83d5db4852a0ad7178b87e8824%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #23804: Add a RasterField to GeoDjango

2014-11-12 Thread Django
#23804: Add a RasterField to GeoDjango
-+-
 Reporter:  yellowcap|  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  GIS  |Version:  master
 Severity:  Normal   |   Keywords:  raster gdal
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Raster integrations is becoming stronger for database back-ends such as
 PostGIS, so an integration of raster data into Django would open new
 possibilities for online mapping. Handling raster data in online
 environments is currently hard to accomplish and integration into a web
 framework would make this easier in many cases.

 Adding a RasterField makes sense as a first step to handling raster data
 input and output. Spatial querying and other operations could then be
 built on top of 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.0e131b2efb312d818b445e60fcc03665%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #15053: Make templates more reusable by Improving template loading algorithm to avoid extending infinite recursion

2014-11-12 Thread Django
#15053: Make templates more reusable by Improving template loading algorithm to
avoid extending infinite recursion
-+
 Reporter:  pmartin  |Owner:  unaizalakain
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by rm_):

 @prestontimmons thanks a lot for your work! Would be nice to have all this
 high level description in the commit is it is not lost.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e07a401951fbd0d971e562857af9b503%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #15718: Django unquotes urls and not able to distinguish %2F and /

2014-11-12 Thread Django
#15718: Django unquotes urls and not able to distinguish %2F and /
-+-
 Reporter:  fed239   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  urls, url resolver,  | Triage Stage:
  unquote, %2F   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by gst):

 * ui_ux:   => 0


Comment:

 I've ran into the exact same issue :/

 The main problem I see is that, as far as I understand actually, django
 compares the url in its url-decoded form against each possible regex
 pattern. So the problems we are encountering with '/' encoded url value
 (%2F). Though I could be wrong 'cause I've not went to check django code.
 If I'm not wrong about this:

 Wouldn't there be a possibility to tell django to compare some url regex
 pattern against the original url value in its non-decoded form ??

 regards,

 gst.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.69f2642ddae16a76ffe12a65f17e9828%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23799: squashmigrations --no-optimize still optimizes

2014-11-12 Thread Django
#23799: squashmigrations --no-optimize still optimizes
+
 Reporter:  Tilka   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+
Changes (by timgraham):

 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.b33c51d156cf2d8273927e0e605e7b30%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23795: Django form fields : limit_choices_to should not be mandatory with queryset

2014-11-12 Thread Django
#23795: Django form fields : limit_choices_to should not be mandatory with 
queryset
-+-
 Reporter:  artscoop |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  formfield,   | Triage Stage:  Accepted
  queryset, limit_choices_to |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.3cf7c09fdc2c285fb1fce90e26b5086a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23781: Add a GeoJSON serializer

2014-11-12 Thread Django
#23781: Add a GeoJSON serializer
-+
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

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


Comment:

 Tests are not passing.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.cdf69366339c72192b41b2ba228f43cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23776: HStoreField example doesn't work

2014-11-12 Thread Django
#23776: HStoreField example doesn't work
-+-
 Reporter:  vedgar   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  postgres hstore  | Triage Stage:
  register   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.cf69844e03fb7ed06c479eae1f4a3411%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23776: HStoreField example doesn't work

2014-11-12 Thread Django
#23776: HStoreField example doesn't work
-+-
 Reporter:  vedgar   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  postgres hstore  |  Unreviewed
  register   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by vedgar):

 Hm, I changed pass to raise and it worked. Since that didn't make any
 sense, I changed it back and it still works. I updated django to latest
 before that, so maybe it was fixed. But it's possible that I made a
 mistake earlier - sorry for bothering you.

 (Just out of curiosity: when makemigrations says "No changes detected", or
 migrate says "No migrations to apply", is it still possible that something
 happened to my app? For instance, hstore was registered or something like
 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.2028e7d84d60102f875050f686bf3316%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #23803: DateField returns datetime if SQLite field is created as TIMESTAMP

2014-11-12 Thread Django
#23803: DateField returns datetime if SQLite field is created as TIMESTAMP
--+
 Reporter:  me21  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.6
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I have SQLite database where certain column in table is created as
 //TIMESTAMP//. The database is created not by Django, but by SymmetricDS,
 a DB replication software. The database is replicated from Microsoft SQL
 Server 2005, where it has //datetime// type.
 In my Django application, the model has DateField for that column. The
 returned value has //datetime// type, not //date//.

 If I use the same model with Microsoft SQL Server 2005 (using django-
 pyodbc-azure package), the returned value has //date// type, even though
 the underlying column has //datetime// type.

 I believe that DateField should return //date// always, regardless of DB
 backend. Please consider altering the behaviour.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.c03695993bd08062d2eedbedf21beb2f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


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

2014-11-12 Thread Django
#15574: IndexError: list index out of range caused by inline formsets
+
 Reporter:  poswald |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  inline formset  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by asfaltboy):

 Replying to [comment:30 Avraham Seror ]:
 > Well, for those stuck in 1.4 in the meantime this is the workaround I'm
 using:
 >
 > the problem with my previous snippet was that I was removing too much, I
 considered using a regex but that would be overkill.
 > in my case I'm removing everything so now I'm simply doing as below
 instead of a loop:
 >  request.POST['templatepage_set-TOTAL_FORMS'] = '0'
 >
 > in any case, is this fix in 1.6?

 For anyone who's still wondering; the above mentioned fix in master seems
 to have been included in 1.7.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.682968f5155790388dc09b0942c03188%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix

2014-11-12 Thread Django
#23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix
-+-
 Reporter:  richardhowardsparx   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  bump_prefix  |  Needs documentation:  0
  subquery alias |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * stage:  Unreviewed => Accepted


Comment:

 The breakage is non-intentional. Before Django used conflicting aliases
 for nested subqueries that could result to problems in some cases.

 We could just extend the alphabet, start from Z and then continue from AA
 after that. Some limit for recursion depth might make sense, but 5 is
 definitely too low.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.bdaa8e2f9bf0fa2efbcc1eddb749b328%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22967: Model._do_update not always consistent with the precise meaning of returned value

2014-11-12 Thread Django
#22967: Model._do_update not always consistent with the precise meaning of 
returned
value
-+-
 Reporter:  knaperek |Owner:  knaperek
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  select_on_save   |  checkin
  concurrency race-condition |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"c56c42b5c01ed774cfa8e044cd372a984608536c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="c56c42b5c01ed774cfa8e044cd372a984608536c"
 Fixed #22967 -- Made Model._do_update consistent

 Made _do_update behave more strictly according to its docs,
 including a corner case when specific concurent updates are
 executed and select_on_save is set.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.27ed25eae72a13417c418d817b68aa93%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23802: Typos in 1.7 release notes

2014-11-12 Thread Django
#23802: Typos in 1.7 release notes
---+--
 Reporter:  aruseni|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 I don't see a typo in the first sentence. I see the extra space before the
 period in the second. I believe the issue in the third is that the second
 "backends" should be "backend" -- can you confirm?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2a81aac701470c5f11b020db3596f33b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23778: Running tests outside the test runner needs clarification

2014-11-12 Thread Django
#23778: Running tests outside the test runner needs clarification
--+
 Reporter:  Starou|Owner:  Starou
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  tests run_tests   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Starou):

 Replying to [comment:4 prestontimmons]:
 > This example is okay. I have a couple thoughts, though:
 >
 > I assume the most common case for this is creating a test runner for
 reusable apps. In that case, messing with `PYTHONPATH` is often
 unnecessary since you can either `pip install --editable` or `python
 setup.py develop` to put your packages on the path. Is it worth mentioning
 this?

 Hi Preston,

 The PYTHONPATH in the PR snippet is about resolving
 `DJANGO_SETTINGS_MODULE` by adding the path of the test project, not the
 reusable app dev sources path (which is assumed). But maybe this is not
 clear enough ?

 >
 > The example hard-codes the app label in `runner.run_tests(['my_app'])`.
 Even with reusable apps it's nice to have the option of passing a path to
 a test case, like `./runtests.py myapp.tests.SomeCase.test`. Should the
 example take that into consideration?
 >
 > I usually do something like:
 >
 > {{{
 > runner.runtests(sys.argv[1:] or ["myapp"])
 > }}}

 Good point.
 I wanted the snippet as simple as possible (how to convert a `manage.py
 test` shell invocation into Python code). In that regard, I would replace
 `sys.argv[1:] or ['myapp']` by `sys.argv[1:]` and update the runtests.py
 invocation example with some optional arguments ''à la Django''
 
(`[path.to.modulename|path.to.modulename.TestCase|path.to.modulename.TestCase.test_method]`).
 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.f76393a4571841054dbe654a18556868%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.