date:20151023

Re: [Django] #25603: it's not clear that geometry's but not target SRID is meant in the note of description of `GEOSGeometry.transform`

2015-10-23 Thread Django

#25603: it's not clear that geometry's but not target SRID is meant in the note 
of
description of `GEOSGeometry.transform`
---+--
 Reporter:  sir-sigurd |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by sir-sigurd):

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


Comment:

 PR -- https://github.com/django/django/pull/5473

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

[Django] #25603: it's not clear that geometry's but not target SRID is meant in the note of description of `GEOSGeometry.transform`

2015-10-23 Thread Django

#25603: it's not clear that geometry's but not target SRID is meant in the note 
of
description of `GEOSGeometry.transform`
---+
 Reporter:  sir-sigurd |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  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/053.54b84388432326a66c446a552067c737%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25598: Add support for SCRIPT_NAME in STATIC_URL and MEDIA_URL (was: support for SCRIPT_NAME for static tag and FileField.url)

2015-10-23 Thread Django

#25598: Add support for SCRIPT_NAME in STATIC_URL and MEDIA_URL
-+-
 Reporter:  DheerendraRathor |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  script_name, | Triage Stage:  Accepted
  static_url, media_url  |
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/074.d4fdbb3a30c801df5a6f8465186da89d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25602: Django breaks sphinx

2015-10-23 Thread Django

#25602: Django breaks sphinx
---+--
 Reporter:  amikrop|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:  invalid
 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):

 I think the issue with `FileDescriptor` will be fixed in Django 1.10
 (#21042).

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

Re: [Django] #25602: Django breaks sphinx

2015-10-23 Thread Django

#25602: Django breaks sphinx
---+--
 Reporter:  amikrop|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:  invalid
 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 amikrop):

 After all I managed to do it by monkeypatching FileDescriptor's
 {{{
  __get__
 }}}
 in conf.py. First, I needed to be in a Django project, not enough to just
 be in a "projectless" app. Second, it needed manual setting of environment
 variable DJANGO_SETTINGS_MODULE, which settings.configure() couldn't do.
 And third it needed the monkeypatch. These were the lines needed in
 conf.py:


 {{{
 sys.path.insert(0, os.path.abspath('..'))
 os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'

 import django
 django.setup()

 from django.db.models.fields.files import FileDescriptor
 FileDescriptor.__get__ = lambda self, *args, **kwargs: self
 }}}


 I mentioned it for future reference and it would be nice if it could all
 be documented together.

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

Re: [Django] #25602: Django breaks sphinx

2015-10-23 Thread Django

#25602: Django breaks sphinx
---+--
 Reporter:  amikrop|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:  invalid
 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 amikrop):

 django.setup() did not help no matter where I put it in conf.py
 I would appreciate further investigation/help.

 django.setup() after settings.configure(): https://dpaste.de/aekd

 django.setup() before settings.configure():
 https://bpaste.net/show/730b6345ee5e

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

Re: [Django] #17133: get_script_name goofs when there is Apache URL rewriting

2015-10-23 Thread Django

#17133: get_script_name goofs when there is Apache URL rewriting
-+-
 Reporter:  gjanee@… |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  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
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"10ace52a41fc3458fb7df51d11974b398f0fbde3" 10ace52a]:
 {{{
 #!CommitTicketReference repository=""
 revision="10ace52a41fc3458fb7df51d11974b398f0fbde3"
 Fixed #17133 -- Properly handled successive slashes in incoming requests

 Thanks gja...@ucop.edu 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/073.656654a689495411ee58ee4b5a047721%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17133: get_script_name goofs when there is Apache URL rewriting

2015-10-23 Thread Django

#17133: get_script_name goofs when there is Apache URL rewriting
-+-
 Reporter:  gjanee@… |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  master
 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):

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

Re: [Django] #25602: Django breaks sphinx

2015-10-23 Thread Django

#25602: Django breaks sphinx
---+--
 Reporter:  amikrop|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:  invalid
 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):

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


Comment:

 I'd guess you need to call `django.setup()` somewhere as described in the
 first question in the
 [https://docs.djangoproject.com/en/stable/ref/applications/#troubleshooting
 Applications Troubleshooting].

 Please see TicketClosingReasons/UseSupportChannels if you need further
 help.

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

Re: [Django] #25397: Warn of clash between generic view context variables and template context processor variables

2015-10-23 Thread Django

#25397: Warn of clash between generic view context variables and template 
context
processor variables
--+
 Reporter:  mathieuhinderyckx |Owner:  jbzdak
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.8
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"488538e55e8f32c00f43f66367a63a4e6a56e1c6" 488538e]:
 {{{
 #!CommitTicketReference repository=""
 revision="488538e55e8f32c00f43f66367a63a4e6a56e1c6"
 [1.9.x] Fixed #25397 -- Documented class-based view context variable clash
 with context processors.

 Backport of 494b7986a3e5996d857b085f188a630d1504d9ca 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/075.82ab42824707d46916514cf60550ddb5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25397: Warn of clash between generic view context variables and template context processor variables

2015-10-23 Thread Django

#25397: Warn of clash between generic view context variables and template 
context
processor variables
--+
 Reporter:  mathieuhinderyckx |Owner:  jbzdak
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.8
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"494b7986a3e5996d857b085f188a630d1504d9ca" 494b7986]:
 {{{
 #!CommitTicketReference repository=""
 revision="494b7986a3e5996d857b085f188a630d1504d9ca"
 Fixed #25397 -- Documented class-based view context variable clash with
 context processors.
 }}}

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

Re: [Django] #25397: Warn of clash between generic view context variables and template context processor variables

2015-10-23 Thread Django

#25397: Warn of clash between generic view context variables and template 
context
processor variables
--+
 Reporter:  mathieuhinderyckx |Owner:  jbzdak
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.8
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"d83454fbf2eb677fa54bcb5f7ab10d5007b6a147" d83454fb]:
 {{{
 #!CommitTicketReference repository=""
 revision="d83454fbf2eb677fa54bcb5f7ab10d5007b6a147"
 [1.8.x] Fixed #25397 -- Documented class-based view context variable clash
 with context processors.

 Backport of 494b7986a3e5996d857b085f188a630d1504d9ca 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/075.4735d78afc9aeaaec118c66f77e77b52%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16734: urlresolvers doesn't get a script prefix from manage.py

2015-10-23 Thread Django

#16734: urlresolvers doesn't get a script prefix from manage.py
-+-
 Reporter:  d00gs|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 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 claudep):

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

Re: [Django] #25602: Django breaks sphinx

2015-10-23 Thread Django

#25602: Django breaks sphinx
---+--
 Reporter:  amikrop|Owner:  nobody
 Type:  Bug|   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 amikrop):

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


Old description:

> I try to use sphinx-apidoc on my Django app, but when I run "make html" I
> get an error. I have tried everything I found as solutions, but with no
> luck.

New description:

 I try to use sphinx-apidoc on my Django app, but when I run "make html" I
 get an error. I have tried everything I found as solutions, but with no
 luck.

 conf.py https://bpaste.net/show/c10e9d3877bf

 traceback https://bpaste.net/show/d2451bcd91fd

 the app is this one https://github.com/amikrop/django-uaccounts/ and I put
 the docs directory right in the root

--

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

[Django] #25602: Django breaks sphinx

2015-10-23 Thread Django

#25602: Django breaks sphinx
---+
 Reporter:  amikrop|  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
---+
 I try to use sphinx-apidoc on my Django app, but when I run "make html" I
 get an error. I have tried everything I found as solutions, but with no
 luck.

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

Re: [Django] #25600: Template `if` tag behavior change with 1.8, OneToOneField, RelatedObjectDoesNotExist is True?

2015-10-23 Thread Django

#25600: Template `if` tag behavior change with 1.8, OneToOneField,
RelatedObjectDoesNotExist is True?
-+
 Reporter:  syphar   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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
 * stage:  Unreviewed => Accepted


Comment:

 Okay, making that setting a non-empty value is the piece I was missing to
 reproduce. Bisected the change to
 0dd05c9e66ebb5cb97136f84373f43582783e1a6. It's not immediately obvious to
 me what the resolution should be, but at least some documentation could be
 added if we decide not to change the behavior.

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

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

Re: [Django] #25600: Template `if` tag behavior change with 1.8, OneToOneField, RelatedObjectDoesNotExist is True?

2015-10-23 Thread Django

#25600: Template `if` tag behavior change with 1.8, OneToOneField,
RelatedObjectDoesNotExist is True?
-+--
 Reporter:  syphar   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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 syphar):

 I can still try do write a failing testcase if it helps

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

Re: [Django] #25600: Template `if` tag behavior change with 1.8, OneToOneField, RelatedObjectDoesNotExist is True?

2015-10-23 Thread Django

#25600: Template `if` tag behavior change with 1.8, OneToOneField,
RelatedObjectDoesNotExist is True?
-+--
 Reporter:  syphar   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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 syphar):

 wanted to play around a little to find the point where it stopped working
 (in our codebase).

 I starts happening when we set {{{TEMPLATE_STRING_IF_INVALID}}} to any
 value (with {{{%s}}} or without)

 Out of curiosity I tried if it's related to the old
 ({{{TEMPLATE_STRING_IF_INVALID}}} or the new ({{{string_if_invalid}}}
 option in the {{{TEMPLATES}}} config, but it happens always.

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

Re: [Django] #25599: __iexact filter matches strings of different length

2015-10-23 Thread Django

#25599: __iexact filter matches strings of different length
-+-
 Reporter:  ahalma   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  iexact, filter,  | Triage Stage:
  query, model   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ahalma):

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


Old description:

> I would expect that the `__iexact` filter for querying models only
> results in string matches that possibly differ in case, however, it also
> matches prefixes...
>
> {{{
> MyModel.objects.filter(name__iexact='king').all()
> [, , ]
> }}}
>
> This looks more like `__icontains` to me... I expected only [ KING>]

New description:

 I would expect that the __iexact filter for querying models only results
 in string matches that possibly differ in case, however, it also matches
 prefixes...

 {{{
 MyModel.objects.filter(name__iexact='king').all()
 [, , ]
 }}}

 This looks more like __icontains to me... I expected only []

--

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

Re: [Django] #25598: support for SCRIPT_NAME for static tag and FileField.url

2015-10-23 Thread Django

#25598: support for SCRIPT_NAME for static tag and FileField.url
-+-
 Reporter:  DheerendraRathor |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  script_name, | Triage Stage:
  static_url, media_url  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * component:  Uncategorized => contrib.staticfiles


Comment:

 I see. I guess the idea would be to use `get_script_prefix()` like
 `reverse()` does as I don't think we have access to `request` everywhere
 we need it. It seems like some public APIs like `get_static_url()` and
 `get_media_url()` would replace accessing the settings directly whenever
 building URLs. For backwards compatibility, possibly these functions could
 try to detect if the setting is already prefixed appropriately.

 Removing the prefix from the settings, however, means that the URLs are no
 longer correct when generated outside of a request/response cycle though
 (#16734). I'm not sure if it might create any practical problems, but we
 might think about addressing that issue first.

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

Re: [Django] #25600: Template `if` tag behavior change with 1.8, OneToOneField, RelatedObjectDoesNotExist is True?

2015-10-23 Thread Django

#25600: Template `if` tag behavior change with 1.8, OneToOneField,
RelatedObjectDoesNotExist is True?
-+--
 Reporter:  syphar   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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 timgraham):

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


Comment:

 I can't reproduce that -- I'm always seeing the else branch on master and
 stable/1.8.x. Maybe you could provide a failing test case for Django's
 test suite?

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

Re: [Django] #25598: support for SCRIPT_NAME for static tag and FileField.url

2015-10-23 Thread Django

Comment (by claudep):

I think that the idea basically makes sense. Ideally, a Django instance
shouldn't need to know at which subpath it is being deployed, as this can
be considered as purely sysadmin stuff. It would be a good separation of
concerns. For example, the Web administrator may change the
WSGIScriptAlias from /foo to /bar and the application should continue
working. Of course, this only applies when *_URL settings are not full
URIs.

In practice, it's very likely that many running instances are adapting
their *_URL settings to include the base script path, hence the behavior
change would be backwards incompatible. The question is whether the change
is worth the incompatibility.

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

Re: [Django] #25598: support for SCRIPT_NAME for static tag and FileField.url

2015-10-23 Thread Django

#25598: support for SCRIPT_NAME for static tag and FileField.url
-+-
 Reporter:  DheerendraRathor |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  script_name, | Triage Stage:
  static_url, media_url  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 What I meant was that I don't think Django should automatically use
 SCRIPT_NAME in generating those URLs. If you're running your site on a
 subpath, then you should set your STATIC_URL to
 'http://example.com/subpath/static/' or whatever. However, you might not
 even be hosting static and uploaded files on the same domain as your site
 (in fact, for user-uploaded files, you shouldn't do that
 [https://docs.djangoproject.com/en/stable/topics/security/#user-uploaded-
 content for security reasons]) in which case `SCRIPT_URL` is irrelevant in
 constructing the static/media URLs.

 How would the change make it easier to setup sites?

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

Re: [Django] #17133: get_script_name goofs when there is Apache URL rewriting

2015-10-23 Thread Django

#17133: get_script_name goofs when there is Apache URL rewriting
--+
 Reporter:  gjanee@…  |Owner:  nobody
 Type:  Cleanup/optimization  |   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 claudep):

 * version:  1.3 => master
 * needs_tests:  1 => 0


Comment:

 PR [https://github.com/django/django/pull/5468 #5468]

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

Re: [Django] #25598: support for SCRIPT_NAME for static tag and FileField.url

2015-10-23 Thread Django

#25598: support for SCRIPT_NAME for static tag and FileField.url
-+-
 Reporter:  DheerendraRathor |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  script_name, | Triage Stage:
  static_url, media_url  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by DheerendraRathor):

 This is not a patch. This is just an idea I got about the patch for `{%
 static %}` only. The patch will (probably) involve `FileSystemStorage` and
 `StaticFileSystemStorage` classes.

 The main idea behind this feature was that Django will auto detect
 script_name header and  use that accordingly for creating static and media
 urls. This will reduce human efforts for setting up sites in future. This
 patch will also take time to develop so it can be added in Django2.0
 timeline.

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

Re: [Django] #25599: __iexact filter matches strings of different length

2015-10-23 Thread Django

#25599: __iexact filter matches strings of different length
-+-
 Reporter:  ahalma   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  iexact, filter,  | Triage Stage:
  query, model   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> I would expect that the __iexact filter for querying models only results
> in string matches that possibly differ in case, however, it also matches
> prefixes...
>
> {{{
> MyModel.objects.filter(name__iexact='king').all()
> [, , ]
> }}}
>
> This looks more like __icontains to me... I expected only [ KING>]

New description:

 I would expect that the `__iexact` filter for querying models only results
 in string matches that possibly differ in case, however, it also matches
 prefixes...

 {{{
 MyModel.objects.filter(name__iexact='king').all()
 [, , ]
 }}}

 This looks more like `__icontains` to me... I expected only []

--

Comment (by timgraham):

 What database are you using?

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

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

Re: [Django] #25598: support for SCRIPT_NAME for static tag and FileField.url

2015-10-23 Thread Django

#25598: support for SCRIPT_NAME for static tag and FileField.url
-+-
 Reporter:  DheerendraRathor |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  script_name, | Triage Stage:
  static_url, media_url  |  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


Comment:

 This change doesn't seem correct to me (for one, it seems like it could
 break existing sites). Why not include the appropriate prefix in your
 `STATIC_URL` and `MEDIA_URL` settings?

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

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

Re: [Django] #23745: Migrations migrate is slow

2015-10-23 Thread Django

#23745: Migrations migrate is slow
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 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 timgraham):

 New in Django 1.9, you can disable migrations on a per app basis using the
 [https://docs.djangoproject.com/en/1.9/ref/settings/#std:setting-
 MIGRATION_MODULES MIGRATION_MODULES] setting by setting the app label to
 `None` (#24919).

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

Re: [Django] #25601: makemigrations create unnecessary migrations

2015-10-23 Thread Django

#25601: makemigrations create unnecessary migrations
---+--
 Reporter:  vstoykov   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Migrations |  Version:  1.8
 Severity:  Normal |   Resolution:  invalid
 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):

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


Comment:

 This is by design, see #22837 and the last paragraph in
 [https://docs.djangoproject.com/en/stable/topics/migrations/#the-commands
 The Commands] section in the documentation.

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

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

Re: [Django] #25582: Add a way to build URLs with query strings

2015-10-23 Thread Django

#25582: Add a way to build URLs with query strings
-+
 Reporter:  guettli  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (URLs)  |  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 guettli):

 @spookylukey for me this ticket is solved by this:

 {{{
 def reverse(*args, **kwargs):
 get = kwargs.pop('get', {})
 url = orig_reverse(*args, **kwargs)
 if get:
 url += '?' + urllib.urlencode(get)
 return url
 }}}

 It is not difficult. The question is if it will be handy in django core.

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

Re: [Django] #23163: makemigrations currently detecting changes in help text on auth.User

2015-10-23 Thread Django

#23163: makemigrations currently detecting changes in help text on auth.User
--+
 Reporter:  dpn   |Owner:  andrewgodwin
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.7-rc-2
 Severity:  Normal|   Resolution:  fixed
 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
 * component:  Database layer (models, ORM) => contrib.auth
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug


Old description:

> Steps to reproduce:
>
> 1. check out stable/1.7.x from github
> 2. run makemigrations
>
> The migration it wants to create is below:
>
> ```
> # -*- coding: utf-8 -*-
> from __future__ import unicode_literals
>
> from django.db import models, migrations
>

> class Migration(migrations.Migration):
>
> dependencies = [
> ('auth', '0001_initial'),
> ]
>
> operations = [
> migrations.AlterField(
> model_name='user',
> name='groups',
> field=models.ManyToManyField(help_text='The groups this user
> belongs to. A user will get all permissions granted to each of his/her
> group.', to=b'auth.Group', verbose_name='groups', blank=True),
> ),
> migrations.AlterField(
> model_name='user',
> name='user_permissions',
> field=models.ManyToManyField(help_text='Specific permissions
> for this user.', to=b'auth.Permission', verbose_name='user permissions',
> blank=True),
> ),
> ]
> ```

New description:

 Steps to reproduce:

 1. check out stable/1.7.x from github
 2. run makemigrations

 The migration it wants to create is below:
 {{{
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import models, migrations


 class Migration(migrations.Migration):

 dependencies = [
 ('auth', '0001_initial'),
 ]

 operations = [
 migrations.AlterField(
 model_name='user',
 name='groups',
 field=models.ManyToManyField(help_text='The groups this user
 belongs to. A user will get all permissions granted to each of his/her
 group.', to=b'auth.Group', verbose_name='groups', blank=True),
 ),
 migrations.AlterField(
 model_name='user',
 name='user_permissions',
 field=models.ManyToManyField(help_text='Specific permissions
 for this user.', to=b'auth.Permission', verbose_name='user permissions',
 blank=True),
 ),
 ]
 }}}

--

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

Re: [Django] #25582: Add a way to build URLs with query strings

2015-10-23 Thread Django

#25582: Add a way to build URLs with query strings
-+
 Reporter:  guettli  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (URLs)  |  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 spookylukey):

 As per my comment on #10941:

 I think this whole area is solved by

 1) For Python code: urlobject  https://github.com/zacharyvoase/urlobject/
 and furl  https://github.com/gruns/furl
 2) For template code: django-spurl - https://github.com/j4mie/django-
 spurl

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

Re: [Django] #10941: Add a templatetag to generate querystrings

2015-10-23 Thread Django

Comment (by spookylukey):

I think this whole area is solved by django-spurl -
https://github.com/j4mie/django-spurl

It builds on urlobject which can be used for Python code:
https://github.com/zacharyvoase/urlobject/

There is also furl for Python code: https://github.com/gruns/furl

I don't think we need to duplicate any of these within Django. Having a
template tag to do 1/10 of what spurl does is just an invitation to
include more and more of spurl's functionality. It might be useful to
have some links to spurl in the documentation.

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

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

[Django] #25601: makemigrations create unnecessary migrations

2015-10-23 Thread Django

#25601: makemigrations create unnecessary migrations
---+
Reporter: vstoykov | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations |Version: 1.8
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
When verbose name of model or field is changed or some validator
added/removed this creates unnecessary migrations. These attributes are
not related to database at all and this will create extra migrations which
then need to rebuild the state every time when migrations are run on
validations are processed.

This is extra overhead that potentially can slow all tasks related to
migrations, and also extra noise in version control and also is very
annoying. This state (verbose name, validators and potentially other
attributes) is not needed for datamigrations also.

I saw people to complain about speed of the new migrations framework and I
think that this can help at least a little.

This is not tested it's jut my hypothesis.

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

Re: [Django] #23745: Migrations migrate is slow

2015-10-23 Thread Django

#23745: Migrations migrate is slow
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 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 vstoykov):

 I found a snippet for disabling migrations
 https://gist.github.com/NotSqrt/5f3c76cd15e40ef62d09 and assembled it in
 my settings.py to easy turn off them when I want.

 {{{
 if os.getenv('DISABLE_MIGRATIONS'):

 class DisableMigrations(object):

 def __contains__(self, item):
 return True

 def __getitem__(self, item):
 return "notmigrations"


 MIGRATION_MODULES = DisableMigrations()
 }}}

 This is dirty hack put in settings.py but do the job. For Django 1.9 even
 can be simplified by {{{return None}}} instead of {{{return
 "notmigrations"}}}

 Probably some switch to test command {{{--no-migrations}}} or something
 that will do something like that can be useful.

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

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

[Django] #25600: Template `if` tag behavior change with 1.8, OneToOneField, RelatedObjectDoesNotExist is True?

2015-10-23 Thread Django

#25600: Template `if` tag behavior change with 1.8, OneToOneField,
RelatedObjectDoesNotExist is True?
-+
 Reporter:  syphar   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.8
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 We discovered a strange behavior change when upgrading from Django 1.7 to
 1.8.

 Let's assume we have a {{{OneToOneField}}} like here:

 {{{#!python
 class Customer(models.Model):
 name = models.CharField(max_length=100)


 class Project(models.Model):
 customer = models.OneToOneField(Customer)
 title = models.CharField(max_length=100)
 }}}

 the template gets the {{{Customer}}} instance, without a project, in the
 context.

 {{{
 {% if customer.project %}
 {# on 1.8 we get here #}
 {% else %}
 {# on 1.7 we get here #}
 {% endif %}
 }}}

 when debugging and trying to access {{{customer.project}}} in a django
 shell, we get a {{{RelatedObjectDoesNotExist}}} in both versions, so this
 does not seem to have changed.

 So to us it looks like the behavior of the {{{if}}} tag in templates
 changed.

 I'm happy to provide more info as needed, or test stuff. Or even write a
 PR / Fix if someone points me to possible places where this could have
 been changed / broken.

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

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

Re: [Django] #25599: __iexact filter matches strings of different length

2015-10-23 Thread Django

#25599: __iexact filter matches strings of different length
-+-
 Reporter:  ahalma   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  iexact, filter,  | Triage Stage:
  query, model   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ahalma):

 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * 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.3d7db41eb7d4d2549eddd74531379058%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25599: __iexact filter matches strings of different length

2015-10-23 Thread Django

#25599: __iexact filter matches strings of different length
-+-
 Reporter:  ahalma   |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Database layer   |Version:  1.8
  (models, ORM)  |   Keywords:  iexact, filter, query,
 Severity:  Normal   |  model
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 I would expect that the __iexact filter for querying models only results
 in string matches that possibly differ in case, however, it also matches
 prefixes...

 {{{
 MyModel.objects.filter(name__iexact='king').all()
 [, , ]
 }}}

 This looks more like __icontains to me... I expected only []

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

Re: [Django] #25582: Add a way to build URLs with query strings

2015-10-23 Thread Django

#25582: Add a way to build URLs with query strings
-+
 Reporter:  guettli  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (URLs)  |  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 DheerendraRathor):

 Changing anything in `{% url %}` might create a mess. IMHO creating a new
 tag which accept a dictionary or list of tuples will practically serve the
 purpose.

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

[Django] #25598: support for SCRIPT_NAME for static tag and FileField.url

2015-10-23 Thread Django

#25598: support for SCRIPT_NAME for static tag and FileField.url
--+
 Reporter:|  Owner:  nobody
  DheerendraRathor|
 Type:  New   | Status:  new
  feature |
Component:|Version:  master
  Uncategorized   |
 Severity:  Normal|   Keywords:  script_name, static_url, media_url
 Triage Stage:|  Has patch:  0
  Unreviewed  |
Easy pickings:  0 |  UI/UX:  0
--+
 By default, `static` tag just appends `STATIC_URL` in the path. When
 running on subpath it results in incorrect static url.

 This problem can be solved with appending `SCRIPT_NAME` in to `SCRIPT_URL`
 in `settings.py`

 This can be easily added into default django `static` tag and
 `django.contrib.staticfiles` tag as following:


 {{{
 def render(self, context):
 url = self.url(context)
 # Updating url here with request.META['SCRIPT_NAME']
 if self.varname is None:
 return url
 context[self.varname] = url
 return ''
 }}}

 On more research I found that `FileSystemStorage` and `StaticFilesStorage`
 ignores `script_name` as well.
 We might have to do a lot of changes but I think it's worth the efforts.

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

Re: [Django] #25564: Django Admin's "View on Site" ignores model's custom manager

2015-10-23 Thread Django

#25564: Django Admin's "View on Site" ignores model's custom manager
-+-
 Reporter:  yuriiz   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.8
  contrib.contenttypes   |
 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 yuriiz):

 I confirm, looks 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/064.b04dfc5648eecfcf27fffa90be84b3a3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

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

2015-10-23 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.

42 matches

Mail list logo