date:20151022

Re: [Django] #25434: Missing documentation for request.site attribute

2015-10-22 Thread Django

#25434: Missing documentation for request.site attribute
-+-
 Reporter:  ngnpope  |Owner:  ngnpope
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * 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/065.4f60ebb0dbe89dcbf8d947591a4adf06%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25591: Cannot QuerySet.update DateRangeField using F() expressions

2015-10-22 Thread Django

Comment (by jarshwah):

I do think that `F()` objects make sense here, but they're going to have
to go through a custom TypeRange() expression. We could and should handle
this internally though. Users shouldn't need to know whether or not they
need to import `XRange` from `psycopg` or from `contrib.postgres` based on
whether or not they want to support F().

I'm not intimately familiar with the contrib.postgres module, so I'm not
sure if the psycopg2.extras.XRange types are usually imported by users or
not.

`RangeField` already has a `get_prep_value` which then wraps the values in
the underlying `psycopg` types. It could inspect the content of `value`
and then wrap inside a custom range_type_expression rather than
range_type.

This is just throwing ideas at a wall though. I'd be interested in what
Marc Tamlyn has to say.

Also, fwiw, your `DateRange` Func above does not need to define `template`
as that's exactly the default anyway.

--
Ticket URL:
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.fce17f35ebc372aafa732638efd1532a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25589: startapp command should support unicode name

2015-10-22 Thread Django

#25589: startapp command should support unicode name
-+-
 Reporter:  sih4sing5hong5   |Owner:  yoongkang
 Type:  New feature  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
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:"89359347c4e7be123dd99d13a43d75e8610ae1dc" 8935934]:
 {{{
 #!CommitTicketReference repository=""
 revision="89359347c4e7be123dd99d13a43d75e8610ae1dc"
 Refs #25589 -- Fixed admin_scripts test failure on Windows.

 Traceback (most recent call last):
   File "tests\admin_scripts\tests.py", line 646, in
 test_startapp_unicode_name
 content = f.read()
   File "lib\encodings\cp1252.py", line 23, in decode
 return codecs.charmap_decode(input,self.errors,decoding_table)[0]
 UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 46:
 character maps to 
 }}}

--
Ticket URL: 
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/072.92e65ee2f774b5fbb5bcb36d8af044a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25595: Invalid regexp in URLValidator can't handle file:// schemes

2015-10-22 Thread Django

#25595: Invalid regexp in URLValidator can't handle file:// schemes
--+
 Reporter:  marcinn   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.8
 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 timgraham):

 I had a similar skepticism. If we don't make a change, then let's clarify
 the documentation to prevent further tickets about this.

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

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

Re: [Django] #25597: Python 3 compatibility error in PostgreSQL array form fields

2015-10-22 Thread Django

#25597: Python 3 compatibility error in PostgreSQL array form fields
--+
 Reporter:  BertrandBordage   |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.8
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  master => 1.8
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/073.57e827f4903282b323bd26ab72c4b375%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25595: Invalid regexp in URLValidator can't handle file:// schemes

2015-10-22 Thread Django

#25595: Invalid regexp in URLValidator can't handle file:// schemes
--+
 Reporter:  marcinn   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 It's `URLValidator` not `URIValidator`, I think you might need your own
 custom validator for this. The current regex is already bloated, I'm not
 sure we should continue to complexify it...

--
Ticket URL: 
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.30454870fbb9bfd655e0f2085b8cac88%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25597: Python 3 compatibility error in PostgreSQL array form fields

2015-10-22 Thread Django

#25597: Python 3 compatibility error in PostgreSQL array form fields
--+
 Reporter:  BertrandBordage   |  Owner:
 Type:  Bug   | Status:  new
Component:  contrib.postgres  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 
[https://github.com/django/django/blob/master/django/contrib/postgres/forms/array.py
 django.contrib.postgres.forms.array] uses several times the old
 `Exception.message` attribute to get the error message instead of
 `str(Exception)`. This breaks compatibility with Python 3 at least when
 using `SplitArrayField`, but it should also lead to errors on other form
 fields from this module.

 Minimal example:

 {{{#!python
 from django.contrib.postgres.forms import SplitArrayField
 from django.forms import IntegerField

 SplitArrayField(IntegerField(max_value=100), size=2).clean([0, 101])
 }}}

 This leads to an `AttributeError: 'ValidationError' object has no
 attribute 'message'`

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/058.0ffc1fbdebce2d96f2b84a1c0e55cbfe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

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

2015-10-22 Thread Django

#13910: Add generator version of Template.render(Context)
-+
 Reporter:  rooney   |Owner:  Gagaro
 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
-+
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Marking as "Patch needs improvement" given
 [https://github.com/django/django/pull/4783#issuecomment-149877143 the
 latest comment about a regression in performance].

--
Ticket URL: 
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.b02767dd7674ff31c1bf23854fd56ecd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25592: Typo in name for strictly_above PostGISOperator

2015-10-22 Thread Django

#25592: Typo in name for strictly_above PostGISOperator
-+-
 Reporter:  yellowcap|Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"244b7c930f6518024b75a8f87e9bf399cfc79f2f" 244b7c93]:
 {{{
 #!CommitTicketReference repository=""
 revision="244b7c930f6518024b75a8f87e9bf399cfc79f2f"
 [1.8.x] Fixed #25592 -- Fixed misnamed strictly_above PostGIS lookup

 Fixes a regression from 2bd1bbc42. Thanks Daniel Wiesmann for the report
 and Tim Graham for the review.
 Backport of c08f85fd54 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/067.c64dc7ce448f44b0fa785223c0d0c7e4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25592: Typo in name for strictly_above PostGISOperator

2015-10-22 Thread Django

#25592: Typo in name for strictly_above PostGISOperator
-+-
 Reporter:  yellowcap|Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"e241444ef50add7ef6f9c176f84a9bd85060fc18" e241444]:
 {{{
 #!CommitTicketReference repository=""
 revision="e241444ef50add7ef6f9c176f84a9bd85060fc18"
 [1.9.x] Fixed #25592 -- Fixed misnamed strictly_above PostGIS lookup

 Fixes a regression from 2bd1bbc42. Thanks Daniel Wiesmann for the report
 and Tim Graham for the review.
 Backport of c08f85fd54 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/067.5e07d119a99afbec0ecdf9cecfeec6d3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25592: Typo in name for strictly_above PostGISOperator

2015-10-22 Thread Django

#25592: Typo in name for strictly_above PostGISOperator
-+-
 Reporter:  yellowcap|Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"c08f85fd547a3030cca7ac227e3378d70033e517" c08f85fd]:
 {{{
 #!CommitTicketReference repository=""
 revision="c08f85fd547a3030cca7ac227e3378d70033e517"
 Fixed #25592 -- Fixed misnamed strictly_above PostGIS lookup

 Fixes a regression from 2bd1bbc42. Thanks Daniel Wiesmann for the report
 and Tim Graham for the 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.4f6687a1715a5c9c8ffcb38918f2a3f8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25434: Missing documentation for request.site attribute

2015-10-22 Thread Django

#25434: Missing documentation for request.site attribute
---+
 Reporter:  ngnpope|Owner:  ngnpope
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.7
 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):

 * needs_better_patch:  1 => 0


Comment:

 [https://github.com/django/django/pull/5465 Updated PR]

--
Ticket URL: 
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.09761f3c8c9b4c9b10e35e9fed7dbfa7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24622: Response "context" and "templates" not available in the Test Client when using Jinja2 - Django 1.8

2015-10-22 Thread Django

#24622: Response "context" and "templates" not available in the Test Client when
using Jinja2 - Django 1.8
-+
 Reporter:  rivantis |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  jinja2, test client  | 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:"840e97ab018ef0901fe4731d7502a7e2baf6546b" 840e97a]:
 {{{
 #!CommitTicketReference repository=""
 revision="840e97ab018ef0901fe4731d7502a7e2baf6546b"
 [1.8.x] Refs #24622 -- Documented alternatives to some test response
 attributes when using alternative template engines.

 Backport of 2b9eed41fa26537d1af4f818c6e4296ce3305b01 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/066.9d7bb87814db2200d4ef0f4ac0df027c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24622: Response "context" and "templates" not available in the Test Client when using Jinja2 - Django 1.8

2015-10-22 Thread Django

#24622: Response "context" and "templates" not available in the Test Client when
using Jinja2 - Django 1.8
-+
 Reporter:  rivantis |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  jinja2, test client  | 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:"2b9eed41fa26537d1af4f818c6e4296ce3305b01" 2b9eed4]:
 {{{
 #!CommitTicketReference repository=""
 revision="2b9eed41fa26537d1af4f818c6e4296ce3305b01"
 Refs #24622 -- Documented alternatives to some test response attributes
 when using alternative template engines.
 }}}

--
Ticket URL: 
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.f9f0bb7460024417a7b46d5374d7c9b6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24622: Response "context" and "templates" not available in the Test Client when using Jinja2 - Django 1.8

2015-10-22 Thread Django

#24622: Response "context" and "templates" not available in the Test Client when
using Jinja2 - Django 1.8
-+
 Reporter:  rivantis |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  jinja2, test client  | 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:"c367abb11be9f6758e87df3c178a77af4c5ba1bc" c367abb1]:
 {{{
 #!CommitTicketReference repository=""
 revision="c367abb11be9f6758e87df3c178a77af4c5ba1bc"
 [1.9.x] Refs #24622 -- Documented alternatives to some test response
 attributes when using alternative template engines.

 Backport of 2b9eed41fa26537d1af4f818c6e4296ce3305b01 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/066.91bb7c2a4686862edcc487f854b7e2b7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25519: "View Site" in admin shows wrong URL if site is not hosted at root

2015-10-22 Thread Django

#25519: "View Site" in admin shows wrong URL if site is not hosted at root
--+
 Reporter:  DheerendraRathor  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.admin |  Version:  1.8
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"59e85f09c6c8171d5b24290d455e351063d81f5a" 59e85f0]:
 {{{
 #!CommitTicketReference repository=""
 revision="59e85f09c6c8171d5b24290d455e351063d81f5a"
 Fixed #25519 -- Made the admin "View site" link point to sites running on
 a subpath.

 Used request.META['SCRIPT_NAME'] as the site_url if it hasn't been
 customized from the default value of '/'.
 }}}

--
Ticket URL: 
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/074.1ffc30cb67f63cc76b2662bcb97ca856%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #8467: For ManyToMany manager, we should convert objects being added or removed to the pk type if they are not.

2015-10-22 Thread Django

#8467: For ManyToMany manager, we should convert objects being added or removed 
to
the pk type if they are not.
-+-
 Reporter:  Wonlay   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Duplicate entry, | Triage Stage:  Accepted
  add, remove, ManyToManyField   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 What's the use case for this functionality? Do we do similar type coercion
 elsewhere?

--
Ticket URL: 
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.263cdd43c9961d12f484823526949bc4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21936: Allow delete to provide a success message through a mixin.

2015-10-22 Thread Django

#21936: Allow delete to provide a success message through a mixin.
+
 Reporter:  david.fischer.ch@…  |Owner:  auvipy
 Type:  New feature |   Status:  assigned
Component:  contrib.messages|  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  mixin   | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by auvipy):

 I will  new PR

--
Ticket URL: 
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/084.54a61444e215b89771553f2cbe7c25c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25591: Cannot QuerySet.update DateRangeField using F() expressions

2015-10-22 Thread Django

#25591: Cannot QuerySet.update DateRangeField using F() expressions
---+--
 Reporter:  synotna|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by timgraham):

 Someone with a deeper understanding of expressions can probably offer an
 opinion about whether or not we should try to make `F()` "jack of all
 trades" or if we should promote using more specific functions like you
 mentioned. Some related tickets about query date ranges: #22288, #16487.

--
Ticket URL: 
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.0d63825944a0c5a7507d91a47ffb0ee4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25589: startapp command should support unicode name

2015-10-22 Thread Django

#25589: startapp command should support unicode name
-+-
 Reporter:  sih4sing5hong5   |Owner:  yoongkang
 Type:  New feature  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"3f300efede9f9670f4c413ff85ad731def15992b" 3f300efe]:
 {{{
 #!CommitTicketReference repository=""
 revision="3f300efede9f9670f4c413ff85ad731def15992b"
 Fixed #25589 -- Allowed startapp/project to create apps with Unicode
 characters in the name.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/072.7a1d182649bae12fa71b4497ffb85c59%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25595: Invalid regexp in URLValidator can't handle file:// schemes

2015-10-22 Thread Django

#25595: Invalid regexp in URLValidator can't handle file:// schemes
--+
 Reporter:  marcinn   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * component:  Uncategorized => Core (Other)
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Can this be fixed without special casing the file scheme in the
 validation?

--
Ticket URL: 
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.af93d870ffe40060778ebed249a8b353%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25596: Can't change user's password in admin when using custom User model (was: Can't change user's password in DjangoAdmin when using custom User model)

2015-10-22 Thread Django

#25596: Can't change user's password in admin when using custom User model
-+
 Reporter:  user0007 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.9b1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * version:  1.9a1 => 1.9b1
 * type:  Uncategorized => Bug
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Regression due to 50aa1a790ca66c2a93e0a52e00c53375b269ff49. Looks like
 hardcoded "auth" should be `user._meta.app_label` as you suggested.

--
Ticket URL: 
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.6a71d03a0ab70446378bea6dd237c928%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25596: Can't change user's password in DjangoAdmin when using custom User model (was: Can't change user's password in DjangoAdmin)

2015-10-22 Thread Django

#25596: Can't change user's password in DjangoAdmin when using custom User model
---+--
 Reporter:  user0007   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  1.9a1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by user0007):

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


Old description:

> Django 1.9b1
>
> I'm using custom User model which is defined as:
>
> {{{
> AUTH_USER_MODEL = 'users.User'
>
> INSTALLED_APPS = [
> 'django.contrib.admin',
> 'django.contrib.auth',
> ...
> 'apps.users',
> ]
> }}}
>
> When I tried to change user's password (using
> /admin/users/user/ID/password/) I've got an error:
>
> {{{Traceback:
>
> File "/src/django/django/core/handlers/base.py" in get_response
>   149. response =
> self.process_exception_by_middleware(e, request)
>
> File "/src/django/django/core/handlers/base.py" in get_response
>   147. response = wrapped_callback(request,
> *callback_args, **callback_kwargs)
>
> File "/src/django/django/utils/decorators.py" in _wrapped_view
>   149. response = view_func(request, *args, **kwargs)
>
> File "/src/django/django/views/decorators/cache.py" in _wrapped_view_func
>   57. response = view_func(request, *args, **kwargs)
>
> File "/src/django/django/contrib/admin/sites.py" in inner
>   244. return view(request, *args, **kwargs)
>
> File "/src/django/django/utils/decorators.py" in _wrapper
>   67. return bound_func(*args, **kwargs)
>
> File "/src/django/django/views/decorators/debug.py" in
> sensitive_post_parameters_wrapper
>   76. return view(request, *args, **kwargs)
>
> File "/src/django/django/utils/decorators.py" in bound_func
>   63. return func.__get__(self, type(self))(*args2,
> **kwargs2)
>
> File "/src/django/django/contrib/auth/admin.py" in user_change_password
>   155. args=(user.pk,),
>
> File "/src/django/django/core/urlresolvers.py" in reverse
>   600. return
> force_text(iri_to_uri(resolver._reverse_with_prefix(view, prefix, *args,
> **kwargs)))
>
> File "/src/django/django/core/urlresolvers.py" in _reverse_with_prefix
>   508.  (lookup_view_s, args, kwargs,
> len(patterns), patterns))
>
> Exception Type: NoReverseMatch at /panel/users/user/8/password/
> Exception Value: Reverse for 'auth_user_change' with arguments '(8,)' and
> keyword arguments '{}' not found. 0 pattern(s) tried: []
> }}}

New description:

 Django 1.9b1

 I'm using custom User model which is defined as:

 {{{
 AUTH_USER_MODEL = 'users.User'

 INSTALLED_APPS = [
 'django.contrib.admin',
 'django.contrib.auth',
 ...
 'apps.users',
 ]
 }}}

 When I tried to change user's password (using
 /admin/users/user/ID/password/) I've got an error:

 Traceback:

 {{{

 File "/src/django/django/core/handlers/base.py" in get_response
   149. response =
 self.process_exception_by_middleware(e, request)

 File "/src/django/django/core/handlers/base.py" in get_response
   147. response = wrapped_callback(request,
 *callback_args, **callback_kwargs)

 File "/src/django/django/utils/decorators.py" in _wrapped_view
   149. response = view_func(request, *args, **kwargs)

 File "/src/django/django/views/decorators/cache.py" in _wrapped_view_func
   57. response = view_func(request, *args, **kwargs)

 File "/src/django/django/contrib/admin/sites.py" in inner
   244. return view(request, *args, **kwargs)

 File "/src/django/django/utils/decorators.py" in _wrapper
   67. return bound_func(*args, **kwargs)

 File "/src/django/django/views/decorators/debug.py" in
 sensitive_post_parameters_wrapper
   76. return view(request, *args, **kwargs)

 File "/src/django/django/utils/decorators.py" in bound_func
   63. return func.__get__(self, type(self))(*args2,
 **kwargs2)

 File "/src/django/django/contrib/auth/admin.py" in user_change_password
   155. args=(user.pk,),

 File "/src/django/django/core/urlresolvers.py" in reverse
   600. return
 force_text(iri_to_uri(resolver._reverse_with_prefix(view, prefix, *args,
 **kwargs)))

 File "/src/django/django/core/urlresolvers.py" in _reverse_with_prefix
   508.  (lookup_view_s, args, kwargs,
 len(patterns), patterns))

 Exception Type: NoReverseM

[Django] #25596: Can't change user's password in DjangoAdmin

2015-10-22 Thread Django

#25596: Can't change user's password in DjangoAdmin
---+
 Reporter:  user0007   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  1.9a1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Django 1.9b1

 I'm using custom User model which is defined as:

 {{{
 AUTH_USER_MODEL = 'users.User'

 INSTALLED_APPS = [
 'django.contrib.admin',
 'django.contrib.auth',
 ...
 'apps.users',
 ]
 }}}

 When I tried to change user's password (using
 /admin/users/user/ID/password/) I've got an error:

 {{{Traceback:

 File "/src/django/django/core/handlers/base.py" in get_response
   149. response =
 self.process_exception_by_middleware(e, request)

 File "/src/django/django/core/handlers/base.py" in get_response
   147. response = wrapped_callback(request,
 *callback_args, **callback_kwargs)

 File "/src/django/django/utils/decorators.py" in _wrapped_view
   149. response = view_func(request, *args, **kwargs)

 File "/src/django/django/views/decorators/cache.py" in _wrapped_view_func
   57. response = view_func(request, *args, **kwargs)

 File "/src/django/django/contrib/admin/sites.py" in inner
   244. return view(request, *args, **kwargs)

 File "/src/django/django/utils/decorators.py" in _wrapper
   67. return bound_func(*args, **kwargs)

 File "/src/django/django/views/decorators/debug.py" in
 sensitive_post_parameters_wrapper
   76. return view(request, *args, **kwargs)

 File "/src/django/django/utils/decorators.py" in bound_func
   63. return func.__get__(self, type(self))(*args2,
 **kwargs2)

 File "/src/django/django/contrib/auth/admin.py" in user_change_password
   155. args=(user.pk,),

 File "/src/django/django/core/urlresolvers.py" in reverse
   600. return
 force_text(iri_to_uri(resolver._reverse_with_prefix(view, prefix, *args,
 **kwargs)))

 File "/src/django/django/core/urlresolvers.py" in _reverse_with_prefix
   508.  (lookup_view_s, args, kwargs,
 len(patterns), patterns))

 Exception Type: NoReverseMatch at /panel/users/user/8/password/
 Exception Value: Reverse for 'auth_user_change' with arguments '(8,)' and
 keyword arguments '{}' not found. 0 pattern(s) tried: []
 }}}

--
Ticket URL: 
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/051.7341dd513f68589a2cf7fab2f8ba2092%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25589: startapp command should support unicode name

2015-10-22 Thread Django

#25589: startapp command should support unicode name
-+-
 Reporter:  sih4sing5hong5   |Owner:  yoongkang
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1
 * 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/072.33cbc89bedb00038af25cc562157afe8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25589: startapp command should support unicode name

2015-10-22 Thread Django

#25589: startapp command should support unicode name
-+-
 Reporter:  sih4sing5hong5   |Owner:  yoongkang
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yoongkang):

 * owner:  nobody => yoongkang
 * 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/072.56c9a35907a9f9c7393c6ebb5112e13b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24591: Copy ModelState.fields and ModelState.managers instead of cloning.

2015-10-22 Thread Django

#24591: Copy ModelState.fields and ModelState.managers instead of cloning.
-+-
 Reporter:  knbk |Owner:  knbk
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 It's an ongoing project to improve the speed of migrations. Django 1.9 has
 more improvements, please test it if you are able. Feel free to create a
 ticket with details and profiling output to help us out. Unfortunately, I
 don't think Django 1.8 is likely to get more improvements at this point.

--
Ticket URL: 
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/062.40c120b53e171876bd799c4e67c312ed%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25584: Getting Invalid syntax error while installing Django 1.9a1 and 1.9b1

2015-10-22 Thread Django

#25584: Getting Invalid syntax error while installing Django 1.9a1 and 1.9b1
-+-
 Reporter:  BlackHacker  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.9a1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
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:"02f3084f4ee1ec4319439b99bd4cde9e27201778" 02f3084f]:
 {{{
 #!CommitTicketReference repository=""
 revision="02f3084f4ee1ec4319439b99bd4cde9e27201778"
 [1.9.x] Fixed #25584 -- Documented a pip error when installing Django 1.9.

 Backport of ee66d8dd7df8326c453fd04c2bdeb5225df934be 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/069.d25e91a27aaf20cec7ac2882da1cea6a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25584: Getting Invalid syntax error while installing Django 1.9a1 and 1.9b1

2015-10-22 Thread Django

#25584: Getting Invalid syntax error while installing Django 1.9a1 and 1.9b1
-+-
 Reporter:  BlackHacker  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.9a1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
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:"ee66d8dd7df8326c453fd04c2bdeb5225df934be" ee66d8d]:
 {{{
 #!CommitTicketReference repository=""
 revision="ee66d8dd7df8326c453fd04c2bdeb5225df934be"
 Fixed #25584 -- Documented a pip error when installing Django 1.9.
 }}}

--
Ticket URL: 
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/069.002a8c43300bd5626f0b03ef1fdd0afa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22288: F() expression not compatible with __range field look up

2015-10-22 Thread Django

#22288: F() expression not compatible with __range field look up
-+-
 Reporter:  liushaohua86@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-
Description changed by timgraham:

Old description:

> class TestModel(models.Model):
> a = models.SmallIntegerField()
> b = models.SmallIntegerField()
>
> TestModel.objects.filter(a__range=(F('b')-1, F('b')+1)
>
> TypeError: int() argument must be a string or a number, not
> 'ExpressionNode'

New description:

 {{{
 class TestModel(models.Model):
 a = models.SmallIntegerField()
 b = models.SmallIntegerField()

 TestModel.objects.filter(a__range=(F('b')-1, F('b')+1)

 TypeError: int() argument must be a string or a number, not
 'ExpressionNode'
 }}}

--

--
Ticket URL: 
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/080.0110a5804891d812664908fe221390d4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24591: Copy ModelState.fields and ModelState.managers instead of cloning.

2015-10-22 Thread Django

Comment (by dalore):

I know this has been marked fixed but how is this fixed? I followed
another ticket to here in which was about the migrations being slow, well
this is what I get after upgrading Django from 1.6 to 1.8 when running
test (To see if everything works):

Running migrations:
Rendering model states...
DONE (1410.571s)

Then it goes on and runs each migration taking 1 - 60 per migrations. How
is 20+ minutes acceptable? This is the time it takes before it even starts
applying the new initial migrations.

This is an old project that started in the early django days, even Andrew
Godwin himself worked on this project for a bit.

--
Ticket URL:
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/062.417ae6ae980eff3edb6b57dfe36e948b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25573: Add simple way to use SplitDateTimeField on ModelForms

2015-10-22 Thread Django

#25573: Add simple way to use SplitDateTimeField on ModelForms
-+-
 Reporter:  seddonym |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  1.9a1
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by seddonym):

 Oh, great feature - yes, this will do the trick.

--
Ticket URL: 
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.e0cc5630c08d9ade6df679c79a86bd31%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25593: Remove scheme validation from URLValidator or provide all IANA acceptable schemes as defaults

2015-10-22 Thread Django

#25593: Remove scheme validation from URLValidator or provide all IANA 
acceptable
schemes as defaults
-+-
 Reporter:  marcinn  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Old description:

> == The problem ==
>
> There are defined only four schemes as default:  http,https,ftp,ftps.
> But URL can have many many more valid schemes.
> HTTP and FTP as good defaults are invalid - they are too limited.
>
> There is no simple way to extend these schemes nor disable scheme
> validation.
> We must extend URLField and redeclare `default_validators` class
> property, which is too complex for that simple case.
>
> == Possible solutions ==
>
>- disable scheme validation and enable it only when user defines
> `allowed_schemes` directly in URLField (backward incompatible)
>- provide `allowed_schemes` as an optional argument for  URLField
> `init()`
>- provide all valid schemes as default set (based on
> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml)
>
> == Preffered solution ==
>
> Probide all (IANA) valid schemes as default together with possibility to
> change them by URLField `init()`.

New description:

 == The problem ==

 There are defined only four schemes as default:  http,https,ftp,ftps.
 But URL can have many many more valid schemes.
 HTTP and FTP as good defaults are invalid - they are too limited.

 There is no simple way to extend these schemes nor disable scheme
 validation.
 We must extend URLField and redeclare `default_validators` class property,
 which is too complex for that simple case.

 == Possible solutions ==

- disable scheme validation and enable it only when user defines
 `allowed_schemes` directly in URLField (backward incompatible)
- provide `allowed_schemes` as an optional argument for  URLField
 `init()`
- provide all valid schemes as default set (based on
 https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml)

 == Prefered solution ==

 Provide all (IANA) valid schemes as default together with possibility to
 change them by URLField `init()`.

--

Comment:

 I think we can rule out any backwards incompatible solutions such as
 removing the validation or changing the default to all valid schemes. I
 don't see a sufficient justification for breaking all sites relying on the
 current behavior. You'll need to argue your rationale on the
 DevelopersMailingList and get a consensus if you want that.

 It seems to me that there are too many customization points on validators
 to add a new model field argument for all of them (such as
 `allowed_schemes` as you proposed). For example, there have also been
 requests to customize the validator's regular expressions. It doesn't seem
 clean to add a model field argument for each one of those validator
 attributes.

 I'd like to try for a more general solution to allow customizing the
 `default_validators` as I described in #25594. I believe that would meet
 the use case of 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 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.89267a1cf67345b4e389690439b953b0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25594: Difficult to customize model field default_validators and have them used on both model and form fields

2015-10-22 Thread Django

#25594: Difficult to customize model field default_validators and have them 
used on
both model and form fields
-+-
 Reporter:  marcinn  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Thinking out loud, too: provide a `NO_DEFAULT_VALIDATORS` constant/class,
 when added to the `validators` list prevent using the field's default
 validators.

--
Ticket URL: 
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.d445d83df53d8dd6af068449131fde5b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25592: Typo in name for strictly_above PostGISOperator

2015-10-22 Thread Django

#25592: Typo in name for strictly_above PostGISOperator
-+-
 Reporter:  yellowcap|Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  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


Comment:

 [https://github.com/django/django/pull/5464 PR] from Claude.

--
Ticket URL: 
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.12d4b479d9e8d45c7b94505bb74a5334%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25594: Difficult to customize model field default_validators and have them used on both model and form fields (was: ModelForm`s URLField does not use model`s URLField validator)

2015-10-22 Thread Django

#25594: Difficult to customize model field default_validators and have them 
used on
both model and form fields
-+-
 Reporter:  marcinn  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * component:  Forms => Database layer (models, ORM)
 * needs_tests:   => 0
 * version:  1.8 => master
 * needs_docs:   => 0
 * type:  Bug => New feature
 * stage:  Unreviewed => Accepted


Comment:

 This problem exists for more than just `URLField` so I'm going to retitle
 the ticket to reflect that. Using the use case from #25593 of customizing
 a `URLValidator`'s accepted schemes, my idea would be to allow something
 like:

 `URLField(validators=[URLValidator(schemes=[])])`

 and have that validator be used in place of the default validator on both
 the model and form field. Thinking out loud: would it be acceptable to
 replace any `default_validators` with values from `validators` if the
 value from `validators` is a subclass of a value in `default_validators`?
 I guess for something like `RegexValidator` you may want to have multiple
 regular expressions so we probably need a different way to say "use this
 validator to replace the default validators". Maybe a `default_validators`
 argument to model fields? This change seems tricky and likely needs a
 discussion on the DevelopersMailingList to nail down the API details, but
 I agree it'd be a worthwhile improvement.

--
Ticket URL: 
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.40d0ac6710b2b0d432b53a72208b2caa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25571: When number argument is not an integer ungettext_lazy's return value evaluates to False

2015-10-22 Thread Django

#25571: When number argument is not an integer ungettext_lazy's return value
evaluates to False
-+-
 Reporter:  teddy_beer_maniac|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.8
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"8b5acda8214c2b8fd73298e106d99627c5815d97" 8b5acda]:
 {{{
 #!CommitTicketReference repository=""
 revision="8b5acda8214c2b8fd73298e106d99627c5815d97"
 Fixed #25571 -- Fixed boolean evaluation of ungettext_lazy
 }}}

--
Ticket URL: 
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/075.cbdbcde8262e28e25f736df3956019dd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25584: Getting Invalid syntax error while installing Django 1.9a1 and 1.9b1

2015-10-22 Thread Django

#25584: Getting Invalid syntax error while installing Django 1.9a1 and 1.9b1
-+-
 Reporter:  BlackHacker  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.9a1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * 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/069.8c7c2922ca027068512f1cef77e16cd7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25595: Invalid regexp in URLValidator can't handle file:// schemes

2015-10-22 Thread Django

#25595: Invalid regexp in URLValidator can't handle file:// schemes
---+
 Reporter:  marcinn|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Regexp does not allow to use `file` scheme in URLValidator.

 == Steps to reproduce ==

 {{{
 from django.core.validators import URLValidator
 URLValidator(schemes=['file'])('file:///tmp/somefile')
 }}}

 == Expected result ==

 No exception should be raised.

 == Current result ==

 {{{
 ValidationError: [u'Enter a valid URL.']
 }}}

--
Ticket URL: 
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/050.94330024a4ca4808487affcb60150891%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25592: Typo in name for strictly_above PostGISOperator

2015-10-22 Thread Django

#25592: Typo in name for strictly_above PostGISOperator
-+
 Reporter:  yellowcap|Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Release blocker  |   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 dursk):

 * 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 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.51de9938fba2ee1a346b956fc1c83db4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21936: Allow delete to provide a success message through a mixin.

2015-10-22 Thread Django

#21936: Allow delete to provide a success message through a mixin.
+
 Reporter:  david.fischer.ch@…  |Owner:  auvipy
 Type:  New feature |   Status:  assigned
Component:  contrib.messages|  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  mixin   | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by timgraham):

 We are waiting for someone to update the pull request as described in
 comment 13.

--
Ticket URL: 
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/084.900b6c8e2dfd666c1897f7c9f974c4b5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25592: Typo in name for strictly_above PostGISOperator

2015-10-22 Thread Django

#25592: Typo in name for strictly_above PostGISOperator
-+
 Reporter:  yellowcap|Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Release blocker  |   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 dursk):

 Fixed, here's the PR: https://github.com/django/django/pull/5463

--
Ticket URL: 
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.05d9f19ab295b5add30eafa909e31df2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21936: Allow delete to provide a success message through a mixin.

2015-10-22 Thread Django

#21936: Allow delete to provide a success message through a mixin.
+
 Reporter:  david.fischer.ch@…  |Owner:  auvipy
 Type:  New feature |   Status:  assigned
Component:  contrib.messages|  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  mixin   | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by JoseTomasTocino):

 Is there any status update on this?

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

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

Re: [Django] #25592: Typo in name for strictly_above PostGISOperator

2015-10-22 Thread Django

#25592: Typo in name for strictly_above PostGISOperator
-+
 Reporter:  yellowcap|Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

 * owner:  nobody => claudep
 * 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.eb70c76d5e5611625e2c5885fe9e60c3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25594: ModelForm`s URLField does not use model`s URLField validator

2015-10-22 Thread Django

#25594: ModelForm`s URLField does not use model`s URLField validator
+
 Reporter:  marcinn |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.8
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 There is incosistency between model's URLField and modelform's URLField
 validation.
 Form's URLField does not use model's field validation.

 Form and model fields have declared class properties with own validators,
 whose defaults to `validators.URLValidator()`.  But when you customize
 validator for model field, the form is still using own (and bad in this
 context) instance. As a result validation differs for form and model. And
 this is an incosistency between modelforms and 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/050.d8554d98ac970b137184baa85c1d9621%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25593: Remove scheme validation from URLValidator or provide all IANA acceptable schemes as defaults

2015-10-22 Thread Django

#25593: Remove scheme validation from URLValidator or provide all IANA 
acceptable
schemes as defaults
--+
 Reporter:  marcinn   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 == The problem ==

 There are defined only four schemes as default:  http,https,ftp,ftps.
 But URL can have many many more valid schemes.
 HTTP and FTP as good defaults are invalid - they are too limited.

 There is no simple way to extend these schemes nor disable scheme
 validation.
 We must extend URLField and redeclare `default_validators` class property,
 which is too complex for that simple case.

 == Possible solutions ==

- disable scheme validation and enable it only when user defines
 `allowed_schemes` directly in URLField (backward incompatible)
- provide `allowed_schemes` as an optional argument for  URLField
 `init()`
- provide all valid schemes as default set (based on
 https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml)

 == Preffered solution ==

 Probide all (IANA) valid schemes as default together with possibility to
 change them by URLField `init()`.

--
Ticket URL: 
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/050.23315cb842da3a16478a817945ccda6f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25590: Allow fields to set join class

2015-10-22 Thread Django

#25590: Allow fields to set join class
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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/066.061160499c0d43ec568d7d2da44f5aad%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25592: Typo in name for strictly_above PostGISOperator

2015-10-22 Thread Django

#25592: Typo in name for strictly_above PostGISOperator
-+
 Reporter:  yellowcap|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  master => 1.8
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Regression in Django 1.8 from 2bd1bbc42430f9815d16b779735b77c35ea4cde7.

--
Ticket URL: 
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.0b010c6d605055272c937dff7fb5f5b2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25592: Typo in name for strictly_above PostGISOperator

2015-10-22 Thread Django

#25592: Typo in name for strictly_above PostGISOperator
+
 Reporter:  yellowcap   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  GIS |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 The key to match the `strictly_above` GIS lookup to the PostGISOperator
 currently reads `stricly_above`.

 
https://github.com/django/django/blob/67732a9b183d2e84c85147b04fdf9499f4395ac6/django/contrib/gis/db/backends/postgis/operations.py#L76

--
Ticket URL: 
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.ebf5c0c5f5e5f30d24333bca0b6a2469%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25591: Cannot QuerySet.update DateRangeField using F() expressions

2015-10-22 Thread Django

#25591: Cannot QuerySet.update DateRangeField using F() expressions
---+--
 Reporter:  synotna|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by synotna):

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


Comment:

 For what it's worth, a workaround is creating a daterange Func expression,
 i.e.

 {{{
 class DateRange(Func):
 function = 'daterange'
 template = '%(function)s(%(expressions)s)'
 }}}


 {{{
 >>> MyModel.objects.update(period=DateRange('date_from', 'date_to'))
 101
 }}}

--
Ticket URL: 
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.15810d178c6c22db41c1993483226271%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25591: Cannot QuerySet.update DateRangeField using F() expressions

2015-10-22 Thread Django

#25591: Cannot QuerySet.update DateRangeField using F() expressions
---+
 Reporter:  synotna|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 It is not currently possible to QuerySet.update a DateRangeField using F()
 expressions - should it be?

 {{{
 class MyModel(models.Model):
 date_from = models.DateField()
 date_to = models.DateField()
 period = DateRangeField(null=True)
 }}}


 {{{
 MyModel.objects.update(period=(F('date_from'), F('date_to')))

 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/tech/.pyenv/versions/partner-
 backend-2015-08-11/lib/python3.4/site-
 packages/django/db/models/manager.py", line 127, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/home/tech/.pyenv/versions/partner-
 backend-2015-08-11/lib/python3.4/site-packages/django/db/models/query.py",
 line 563, in update
 rows = query.get_compiler(self.db).execute_sql(CURSOR)
   File "/home/tech/.pyenv/versions/partner-
 backend-2015-08-11/lib/python3.4/site-
 packages/django/db/models/sql/compiler.py", line 1062, in execute_sql
 cursor = super(SQLUpdateCompiler, self).execute_sql(result_type)
   File "/home/tech/.pyenv/versions/partner-
 backend-2015-08-11/lib/python3.4/site-
 packages/django/db/models/sql/compiler.py", line 840, in execute_sql
 cursor.execute(sql, params)
   File "/home/tech/.pyenv/versions/partner-
 backend-2015-08-11/lib/python3.4/site-
 packages/django/db/backends/utils.py", line 79, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/home/tech/.pyenv/versions/partner-
 backend-2015-08-11/lib/python3.4/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File "/home/tech/.pyenv/versions/partner-
 backend-2015-08-11/lib/python3.4/site-packages/django/db/utils.py", line
 97, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/tech/.pyenv/versions/partner-
 backend-2015-08-11/lib/python3.4/site-packages/django/utils/six.py", line
 658, in reraise
 raise value.with_traceback(tb)
   File "/home/tech/.pyenv/versions/partner-
 backend-2015-08-11/lib/python3.4/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File "/home/tech/.pyenv/versions/partner-
 backend-2015-08-11/lib/python3.4/site-packages/psycopg2/_range.py", line
 235, in getquoted
 a = adapt(r.lower)
 django.db.utils.ProgrammingError: can't adapt type 'F'
 }}}

 Currently (F('date_from'), F('date_to')) is turned into psycopg2's
 DateRange(F(date_from), F(date_to), '[)'), which obviously will not work
 as it cannot handle F() expressions

 I imagine Django needs its own DateRange that can handle them?

--
Ticket URL: 
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/050.08fac030103aafcf2adabf7bd0615977%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25589: startapp command should support unicode name

2015-10-22 Thread Django

#25589: startapp command should support unicode name
--+
 Reporter:  sih4sing5hong5|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Internationalization
 * needs_tests:   => 0
 * version:  1.8 => master
 * needs_docs:   => 0
 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


Comment:

 I think we should indeed follow Python policy. See also
 [https://www.python.org/dev/peps/pep-3131/ PEP 3131].
 Could you investigate about existing validators for such identifiers?

--
Ticket URL: 
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/072.1a7ebffcbed569863fcbfe204f48445f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25590: Allow fields to set join class

2015-10-22 Thread Django

#25590: Allow fields to set join class
-+-
   Reporter:  akaariai   |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 If fields can set the class generating SQL for the join condition, that
 would allow a way to inject complex raw SQL into ORM queries. The class
 generating the join condition is currently hardcoded to
 django.db.models.sql.datastructures.Join.

 My use case is to do a join, where for each main object I need to fetch
 the currently active, or the next active related object. Think of hotel
 room reservations, where you want to have a list that shows the current
 occupant of the room. But with a twist where if there is no current
 occupant, then the next occupant of the room will be shown.

 I can do this manually using PostgreSQL with the following query:
 {{{
 select *
  from room left join lateral (
 select *
   from room_reservation
  where room.room_id = room_reservation.room_id and
from_date = (
 select min(from_date)
   from room_reservation inner_rr
  where inner_rr.room_id = room_reservation.room_id
and (inner_rr.to_date > now() or inner_rr.to_date
 is null)
 )
 ) as current_or_next_room_reservation on true;
 }}}

 Now, 1) I need a complex query inside the join, and 2) I need a lateral
 join. Both of these are currently out of reach for Django.

 If the join field could return a different class to be used instead of the
 Django's currently hard coded Join class, then 3rd party field
 implementations could generate exactly the SQL I want.

 I believe the changes needed for custom join classes to be actually fairly
 minor. I don't believe we want to make this public API, so we'd add just a
 couple of minor changes to internals.

--
Ticket URL: 
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/051.d914ce60848efc58a8e8e4748acb557b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

53 matches

Mail list logo