Re: [Django] #25616: Add note regarding missing dependencies on LookupError for migrations

2016-01-04 Thread Django 
#25616: Add note regarding missing dependencies on LookupError for migrations
--+
 Reporter:  mcfletch  |Owner:  soon
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  master
 Severity:  Normal|   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 soon):

 * status:  new => assigned
 * owner:   => soon


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

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

Re: [Django] #24855: Allow the use of django.contrib.auth.login without credentials (authentication)

2016-01-04 Thread Django 
#24855: Allow the use of django.contrib.auth.login without credentials
(authentication)
--+
 Reporter:  poiati|Owner:  poiati
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  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 poiati):

 * needs_better_patch:  1 => 0


Comment:

 I applied the corrections in the 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/064.97df28f308be40225da16e1d432639e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26026: EmptyQuerySet isinstance check broken with not QuerySet datatypes

2016-01-04 Thread Django 
#26026: EmptyQuerySet isinstance check broken with not QuerySet datatypes
-+-
 Reporter:  vladimirbright   |Owner:
 |  andersonresende
 Type:  Bug  |   Status:  assigned
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:  1|UI/UX:  0
-+-
Changes (by charettes):

 * version:  1.9 => 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/072.eb350e3c224dcfba42b9be1ebeb45efd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25878: APPEND_SLASH doesn't work with DEBUG=False when template/404.html is erroneous

2016-01-04 Thread Django 
#25878: APPEND_SLASH doesn't work with DEBUG=False when template/404.html is
erroneous
-+-
 Reporter:  kuna |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  1.9
 Severity:  Release blocker  |   Resolution:
 Keywords:  slash,debug  | 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):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/5932 PR] to add the requirement to
 the 1.9 release notes and docs.

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

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

Re: [Django] #25616: Add note regarding missing dependencies on LookupError for migrations

2016-01-04 Thread Django 
#25616: Add note regarding missing dependencies on LookupError for migrations
--+
 Reporter:  mcfletch  |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   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):

 * owner:  tmilan81 =>
 * status:  assigned => new
 * has_patch:  1 => 0
 * needs_tests:  1 => 0
 * needs_better_patch:  1 => 0


Comment:

 Deassigning due to inactivity. Markus commented on the pull request, "I'd
 prefer overriding the `StateApps` class in `django.db.migrations.state` to
 catch the `LookupError` and reraise with an amended 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/066.081c5bb79e4166de497478b0edefc9c2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21549: Fixture loading warning when the file is not found should be an exception

2016-01-04 Thread Django 
#21549: Fixture loading warning when the file is not found should be an 
exception
-+-
 Reporter:  mpasternak   |Owner:  soon
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"d5b90c8e120687863c1d41cf92a4cdb11413ad7f" d5b90c8e]:
 {{{
 #!CommitTicketReference repository=""
 revision="d5b90c8e120687863c1d41cf92a4cdb11413ad7f"
 Fixed #21549 -- Made loaddata's 'fixture not found' warning an exception.

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

Re: [Django] #25165: Move JavaScript calls out of HTML to fix JavaScript "no-script-eval" warnings

2016-01-04 Thread Django 
#25165: Move JavaScript calls out of HTML to fix JavaScript "no-script-eval"
warnings
-+-
 Reporter:  timgraham|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  new
Component:  contrib.admin|  Version:  master
 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 timgraham):

 [https://github.com/django/django/pull/5921 PR] for the second regression
 (waiting to corporate the tests from a patch for the `stable/1.9.x` branch
 as noted there).

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

Re: [Django] #26036: URL dispatcher including forward slashes in parameter capture

2016-01-04 Thread Django 
#26036: URL dispatcher including forward slashes in parameter capture
-+-
 Reporter:  mriedelumab  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.8
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  url forward slash| Triage Stage:
  parameter  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by knbk):

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


Comment:

 In your URLconf you use the end-of-line character `$`, so the slash must
 be the last character of the url. Since the original url
 `password/myusername/favicon.ico` does not match, you are redirected to
 the same url with a trailing slash. The capturing group then must be
 anything between `password/` and the last `/`.

 In your CLI example, you omit the `$`, so the `/` does not have to be the
 last character, and the regex matches the original url. The capturing
 group then matches everything up to the last `/`, which is just
 `myusername` in this case.

 If you need to match more than just `\w`, you can define a more inclusive
 character set, i.e.:

 {{{
 url(r'^password/(?P[\w+-]+)/$', views.reset_password,
 name='password'),
 }}}

 I don't see any of the relevant code that has changed in 1.8.x releases,
 so I suspect that's the whole of the issue. If there is something else
 that points at a regression in a 1.8.x. release, please reopen.

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

Re: [Django] #25684: Runserver doesn't use `LOGGING` configuration

2016-01-04 Thread Django 
#25684: Runserver doesn't use `LOGGING` configuration
---+
 Reporter:  fcurella   |Owner:  fcurella
 Type:  New feature|   Status:  assigned
Component:  Error reporting|  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  runserver logging  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by carljm):

 The release notes should of course mention the change. I don't think we
 need detailed instructions for how to re-enable it for people who may have
 disabled the default logging config; it's enough to say (something like)
 "runserver now logs each request to the `django.server` logger instead of
 outputting it directly to console; if your logging config overrides
 Django's defaults, see the default logging config (link) for an example of
 how to configure runserver logging with color output."

 Disabling Django's default logging config is an advanced usage, anybody
 doing that should know enough about logging to configure things
 appropriately from there. (And really, a manual logging config that
 silently discards logging output from unknown loggers by default is kind
 of broken; someone with such a setup shouldn't be surprised to be missing
 some logging output.)

 Also, we're talking about a development convenience here, not something
 that breaks production code-paths, so the backwards-compatibility concern
 level is lower.

 I think the benefits of this change are major, in terms of added
 flexibility to filter and customize runserver logging output without
 needing to hack core Django code.

 And any possibility of replacing runserver remains quite remote AFAICS --
 there are a lot of hard questions there that remain unanswered, and I'm
 not aware of anyone actively working on answering them. I certainly don't
 think it's anywhere near imminent enough to provide justification for
 halting all improvements to runserver.

 So IMO this change is definitely worth moving forward.

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

Re: [Django] #26021: Standardize on hanging indent in documentation

2016-01-04 Thread Django 
#26021: Standardize on hanging indent in documentation
-+-
 Reporter:  timgraham|Owner:  anurag-ks
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  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 timgraham):

 It's not critical either way, but I find it easiest to always add the
 comma so you don't have to think about it. You never know if a function
 might gain new arguments too.

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

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

Re: [Django] #26021: Standardize on hanging indent in documentation

2016-01-04 Thread Django 
#26021: Standardize on hanging indent in documentation
-+-
 Reporter:  timgraham|Owner:  anurag-ks
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  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 chmarr):

 In utils.txt, (new) line 670, there's no trailing comma. It ''kinda''
 makes sense that there isn't one, since the function has exactly three
 arguments, but checking to see if that was intended.

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

Re: [Django] #25068: Metaclass conflict when doing createmigrations in ModelState.render

2016-01-04 Thread Django 
#25068: Metaclass conflict when doing createmigrations in ModelState.render
-+-
 Reporter:  kosz85   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  metaclass conflict   | Triage Stage:  Accepted
  createmigrations   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kosz85):

 Thats the same what metaclassmaker was doing ;) you just did it inline
 without naming function, great that it's fixed. Thx for your effort :)

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

Re: [Django] #25848: Django 1.9 breaks django_coverage_plugin, template coverage doesn't work

2016-01-04 Thread Django 
#25848: Django 1.9 breaks django_coverage_plugin, template coverage doesn't work
--+
 Reporter:  nedbatchelder |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  1.9
 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 sdeibel):

 FWIW I've run into this problem also in Wing IDE's support for debugging
 Django templates.  I was able to partially solve the problem by looking up
 the stack for the nearest frame in Template and using self.origin.name.
 However, when a block is overridden via 'extends' I've not been able to
 figure out how to get the correct file name.

 For example context.render_context[ExtendsNode.context_key][-1].name is
 still the wrong template.

 Is there any reason that the template name can't just be put into
 self.token?  Currently you have token.position but not token.filename and
 it seems position is pretty useless to have a position w/o the filename,
 as far as I can tell.

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

Re: [Django] #25971: BrokenLinkEmailsMiddleware shouldn't report 404s when URL = Referer + "/"

2016-01-04 Thread Django 
#25971: BrokenLinkEmailsMiddleware shouldn't report 404s when URL = Referer + 
"/"
--+
 Reporter:  jribbens  |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:  1 |UI/UX:  0
--+

Comment (by matason):

 Thanks jribbens, I'll see if I can come up with a pull request that fixes
 the issue!

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

Re: [Django] #26035: usertools block in admin console visible after logout

2016-01-04 Thread Django 
#26035: usertools block in admin console visible after logout
-+-
 Reporter:  scottpashley |Owner:
 |  scottpashley
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  admin, logout, ui| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by scottpashley):

 Replying to [comment:1 timgraham]:
 > Seems to be a regression in 46068d850d8debd3611ed6499d48b9907bf07ef6,
 however, the suggested fix doesn't work (unless I got misinterpreted what
 you meant).
 > {{{#!diff
 > diff --git a/django/contrib/admin/sites.py
 b/django/contrib/admin/sites.py
 > index af40880..2dc0d99 100644
 > --- a/django/contrib/admin/sites.py
 > +++ b/django/contrib/admin/sites.py
 > @@ -159,7 +159,7 @@ class AdminSite(object):
 >  Returns True if the given HttpRequest has permission to view
 >  *at least one* page in the admin site.
 >  """
 > -return request.user.is_active and request.user.is_staff
 > +return request.user.is_authenticated() and
 request.user.is_active and request.user.is_staff
 >
 >  def check_dependencies(self):
 >  """
 > }}}



 Apologies, it would be in the html template :


 {{{#!diff
 diff --git a/django/contrib/admin/templates/admin/base.html
 b/django/contrib/admin/templates/admin/base.html
 index 70e137c..47e4cad 100644
 --- a/django/contrib/admin/templates/admin/base.html
 +++ b/django/contrib/admin/templates/admin/base.html
 @@ -24,7 +24,7 @@
  {% block branding %}{% endblock %}
  
  {% block usertools %}
 -{% if has_permission %}
 +{% if has_permission and user.is_authenticated %}
  
  {% block welcome-msg %}
  {% trans 'Welcome,' %}
 }}}

 Scott

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

[Django] #26036: URL dispatcher including forward slashes in parameter capture

2016-01-04 Thread Django 
#26036: URL dispatcher including forward slashes in parameter capture
-+-
 Reporter:  mriedelumab  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (URLs)  |Version:  1.8
 Severity:  Normal   |   Keywords:  url forward slash parameter
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Given the following URL object:

 {{{
 url(r'^password/(?P\S+)/$', views.reset_password,
 name='password'),
 }}}

 and the following URL:

 {{{
 password/myusername/favicon.ico/
 }}}

 Django seems to be capturing {{{username}}} as
 {{{myusername/favicon.ico}}} instead of {{{myusername}}}.

 When tested in Python's CLI, the parameter capture works properly:

 {{{
 >>> url = re.compile(r'^password/(?P\S+)/', re.U)
 >>> match = url.match('password/myusername/favicon.ico')
 >>> match.group('username')
 'myusername'
 >>> url = re.compile(r'^password/(?P\S+)/', re.L)
 >>> match = url.match('password/myusername/favicon.ico')
 >>> match.group('username')
 'myusername'
 }}}

 I would expect if the regexp was the issue, I would see
 {{{mysuername/favicon.ico}}} in the Python output, also.

 I'm using Python 2.7.5 on RHEL 7 with a Virtual Environment for Django
 1.8.8. This also happens in 1.8.7. No changes were made to this
 application's {{{url.py}}} file since July, and this issue only popped up
 since updating to Django 1.8.7 from an earlier version of Django 1.8 (not
 sure which minor version).

 For now, I'm using a {{{\w+}}} regular expression instead of a {{{\S+}}} -
 but that's only a temporary fix. Sometimes I do need to match on special
 characters other than underscore (e.g., dash, plus sign, etc.)

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

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

Re: [Django] #26035: usertools block in admin console visible after logout

2016-01-04 Thread Django 
#26035: usertools block in admin console visible after logout
-+-
 Reporter:  scottpashley |Owner:
 |  scottpashley
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  admin, logout, ui| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
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:

 Seems to be a regression in 46068d850d8debd3611ed6499d48b9907bf07ef6,
 however, the suggested fix doesn't work (unless I got misinterpreted what
 you meant).
 {{{#!diff
 diff --git a/django/contrib/admin/sites.py b/django/contrib/admin/sites.py
 index af40880..2dc0d99 100644
 --- a/django/contrib/admin/sites.py
 +++ b/django/contrib/admin/sites.py
 @@ -159,7 +159,7 @@ class AdminSite(object):
  Returns True if the given HttpRequest has permission to view
  *at least one* page in the admin site.
  """
 -return request.user.is_active and request.user.is_staff
 +return request.user.is_authenticated() and request.user.is_active
 and request.user.is_staff

  def check_dependencies(self):
  """
 }}}

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

[Django] #26035: usertools block in admin console visible after logout

2016-01-04 Thread Django 
#26035: usertools block in admin console visible after logout
---+---
 Reporter:  scottpashley   |  Owner:  scottpashley
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  master
 Severity:  Normal |   Keywords:  admin, logout, ui
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  1
---+---
 When a user logs out of the admin interface, they get directed to a page
 (/admin/logout/) which acknowledges that the user is logged out of the
 system.

 In the top right hand corner of the screen, the welcome string is still
 visible (without the username), as are the "view site" and "log out"
 links. This block should no longer be visible as the user is now logged
 out at this point.

 This is happening because the block is visible as long as {{{
 has_permission }}} returns True.

 I suggest that we also check that the user is authenticated using {{{
 user.is_authenticated }}} in addition to the current check.

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

Re: [Django] #26026: EmptyQuerySet isinstance check broken with not QuerySet datatypes

2016-01-04 Thread Django 
#26026: EmptyQuerySet isinstance check broken with not QuerySet datatypes
-+-
 Reporter:  vladimirbright   |Owner:
 |  andersonresende
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   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 andersonresende):

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


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

Re: [Django] #25848: Django 1.9 breaks django_coverage_plugin, template coverage doesn't work

2016-01-04 Thread Django 
#25848: Django 1.9 breaks django_coverage_plugin, template coverage doesn't work
--+
 Reporter:  nedbatchelder |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  1.9
 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 nedbatchelder):

 We missed the possibility of getting into 1.9.1.  Preston, what should I
 expect from you?  I'm not trying to nag, I know what it's like to be on
 the other side of that question! :)

 Is 1.9.2 do-able?

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

Re: [Django] #26011: allow_reuse_address = 1 on WSGIServer can cause random test failures in LiveServerTestCase on Windows

2016-01-04 Thread Django 
#26011: allow_reuse_address = 1 on WSGIServer can cause random test failures in
LiveServerTestCase on Windows
---+
 Reporter:  knbk   |Owner:  knbk
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by knbk):

 I think this patch exposes an existing bug. The current code expects the
 error when a socket is in use to be an `socket.error` instance, but
 apparently it raises an `OSError` in some circumstances. According to the
 Py3 docs, an `OSError` should automatically be "upgraded" to the
 appropriate error type, but that doesn't seem to happen here. For our case
 it should be sufficient to catch an `OSError` as well (we still need to
 catch `socket.error` on Py2), and check the error code. I'm not sure why
 the `OSError` constructor does not return a `socket.error`, this might be
 a bug in Python. I'll investigate this later.

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

Re: [Django] #26009: contenttypes_tests fail when run in isolation

2016-01-04 Thread Django 
#26009: contenttypes_tests fail when run in isolation
---+
 Reporter:  knbk   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"775291d4c767cd17dc5bbd2e8a605fd4fdfd8aed" 775291d]:
 {{{
 #!CommitTicketReference repository=""
 revision="775291d4c767cd17dc5bbd2e8a605fd4fdfd8aed"
 [1.9.x] Fixed #26009 -- Fixed contenttypes_tests isolation.

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

Re: [Django] #26009: contenttypes_tests fail when run in isolation

2016-01-04 Thread Django 
#26009: contenttypes_tests fail when run in isolation
---+
 Reporter:  knbk   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"2c6c873e3fca6c0c54c2335e131f7742fcf2cf26" 2c6c873e]:
 {{{
 #!CommitTicketReference repository=""
 revision="2c6c873e3fca6c0c54c2335e131f7742fcf2cf26"
 Fixed #26009 -- Fixed contenttypes_tests isolation.
 }}}

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

Re: [Django] #25838: ./manage.py shell creates unnecessary nested exceptions

2016-01-04 Thread Django 
#25838: ./manage.py shell creates unnecessary nested exceptions
-+-
 Reporter:  bmispelon|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I'm not sure if the `shell` command can be tested, currently it doesn't
 have any tests. Maybe it would be feasible after #25680 is fixed, but the
 risk of this regression seems low, especially because this command doesn't
 receive much innovation.

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

Re: [Django] #26020: Standardize restructed text header convention in docs

2016-01-04 Thread Django 
#26020: Standardize restructed text header convention in docs
--+
 Reporter:  timgraham |Owner:  elif
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 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 timgraham):

 Yes, please fix the other headings if you are able.

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

Re: [Django] #26034: Altering CharFields to have both db_index=True and unique=True crashes on postgresql

2016-01-04 Thread Django 
#26034: Altering CharFields to have both db_index=True and unique=True crashes 
on
postgresql
-+
 Reporter:  kaedroho |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  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 charettes):

 i wonder if this could be related to #25694.

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

Re: [Django] #25995: Add more sophisticated serialization support to JSONField (was: Support serialization to `django.contrib.postgres.fields.jsonb.py`)

2016-01-04 Thread Django 
#25995: Add more sophisticated serialization support to JSONField
--+--
 Reporter:  jimgraham |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.9
 Severity:  Normal|   Resolution:  wontfix
 Keywords:  JSONB | 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:   => wontfix


Comment:

 [https://github.com/django/django/pull/5928 Doc patch]. I avoided
 recommending a particular third-party field since we avoid that as it's
 difficult to curate a list of packages that doesn't go stale.

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

Re: [Django] #26034: Altering CharFields to have both db_index=True and unique=True crashes on postgresql

2016-01-04 Thread Django 
#26034: Altering CharFields to have both db_index=True and unique=True crashes 
on
postgresql
-+
 Reporter:  kaedroho |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  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 charettes):

 * component:  Database layer (models, ORM) => Migrations


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

Re: [Django] #26032: Where does `manage.py` belong: to Application or to Project?

2016-01-04 Thread Django 
#26032: Where does `manage.py` belong: to Application or to Project?
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 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 Tim Graham ):

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


Comment:

 In [changeset:"0a72ad3952c0a2e335ed8518d31647e6536ee3fe" 0a72ad3]:
 {{{
 #!CommitTicketReference repository=""
 revision="0a72ad3952c0a2e335ed8518d31647e6536ee3fe"
 [1.9.x] Fixed #26032 -- Moved "project root directory" to a separate
 paragraph.

 Backport of b07f91600d61a2f8d58adb4c92d36dd0b2b34fe7 from master
 }}}

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

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

Re: [Django] #26032: Where does `manage.py` belong: to Application or to Project?

2016-01-04 Thread Django 
#26032: Where does `manage.py` belong: to Application or to Project?
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 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
-+-

Comment (by Tim Graham ):

 In [changeset:"b07f91600d61a2f8d58adb4c92d36dd0b2b34fe7" b07f916]:
 {{{
 #!CommitTicketReference repository=""
 revision="b07f91600d61a2f8d58adb4c92d36dd0b2b34fe7"
 Fixed #26032 -- Moved "project root directory" to a separate paragraph.
 }}}

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

Re: [Django] #25928: Documentation on THOUSAND_SEPARATOR and NUMBER_GROUPING is still misleading

2016-01-04 Thread Django 
#25928: Documentation on THOUSAND_SEPARATOR and NUMBER_GROUPING is still 
misleading
---+
 Reporter:  F30|Owner:  Wingie
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  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 F30):

 Replying to [comment:3 Wingie]:
 > can you take a look and see if the clarifications are correct?
 >
 > https://github.com/Wingie/django/tree/ticket_25928

 Looks good to me, it precisely describes the current behavior.
 You could get rid of the ":setting:`USE_L10N` is set to ``True``, and"
 part in the second paragraph though, as the previous paragraph already
 states that `USE_L10N` must always be `True`. I find that repetition
 rather confusing.

 One could also ask if a behavior which requires such verbose explanations
 is really sensible, but that's out of scope for this bug report.

 Thanks for the fix,
 Felix

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

Re: [Django] #25947: Query's str() method fails when 'default' database is empty

2016-01-04 Thread Django 
#25947: Query's str() method fails when 'default' database is empty
-+-
 Reporter:  liboz|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (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 liboz):

 I looked into this a bit and Django seems to crash when running
 `quote_name_unless_alias` in `django.db.models.sql.compiler` because it
 uses DatabaseOperations' `quote_name` function. Could changing the
 DatabaseOperations for `django.db.backends.dummy` to have a `quote_name`
 function like that of sqlite?

 I'm thinking of something like:
 {{{
 def quote_name(self, name):
 if name.startswith('"') and name.endswith('"'):
 return name  # Quoting once is enough.
 return '"%s"' % 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/063.cb35ae9c780f457767e4cd8590b53e88%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26011: allow_reuse_address = 1 on WSGIServer can cause random test failures in LiveServerTestCase on Windows

2016-01-04 Thread Django 
#26011: allow_reuse_address = 1 on WSGIServer can cause random test failures in
LiveServerTestCase on Windows
---+
 Reporter:  knbk   |Owner:  knbk
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by timgraham):

 Could [http://djangoci.com/job/master-%E1%BC%A5o%E1%BC%A5ascii-
 path/database=mysql,label=trusty,python=python3.5/338/ these Jenkins
 failures] be 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/062.7369f002a8877f15626ec90b05cacbc4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26032: Where does `manage.py` belong: to Application or to Project?

2016-01-04 Thread Django 
#26032: Where does `manage.py` belong: to Application or to Project?
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 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 guettli):

 Hmmm chicken-egg problem. I like the dictionary style:

 A: ... definition of A

 B: ... definition of B.

 I think forward references are ok.

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

Re: [Django] #26034: Altering CharFields to have both db_index=True and unique=True crashes on postgresql

2016-01-04 Thread Django 
#26034: Altering CharFields to have both db_index=True and unique=True crashes 
on
postgresql
-+-
 Reporter:  kaedroho |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 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:  1.9 => 1.8
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Docs say, "Note that when `unique` is `True`, you don’t need to specify
 `db_index`, because unique implies the creation of an index." Nonetheless,
 we should handle this case gracefully.

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

[Django] #26034: Altering CharFields to have both db_index=True and unique=True crashes on postgresql

2016-01-04 Thread Django 
#26034: Altering CharFields to have both db_index=True and unique=True crashes 
on
postgresql
--+
 Reporter:  kaedroho  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hi Everyone,

 If you have a CharField with db_index=True and alter it to have both
 "db_index=True" and "unique=True" the migration for this will not run on
 PostgreSQL.

 Instead, you will get the following error:

 django.db.utils.ProgrammingError: relation
 "app_mymodel_my_field_3922656f_like" already exists

 This bug apears to have been introduced in Django 1.8.7/1.9.1. Git bisect
 leads to this commit:
 
https://github.com/django/django/commit/722fae4b5159b2810e252e3385936f86f04eb09b

 I have created a test project that should hopefully help diagnosis:
 https://github.com/kaedroho/djangobugtest2/

 Thanks,

 Karl

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

Re: [Django] #26032: Where does `manage.py` belong: to Application or to Project?

2016-01-04 Thread Django 
#26032: Where does `manage.py` belong: to Application or to Project?
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 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:

 We could move it as you suggest, but I thought it makes sense to introduce
 what an application is before discussing them (such as where they are
 located) in much detail. Does anyone else find the current version
 unclear?

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

[Django] #26033: Add argon2 password hasher

2016-01-04 Thread Django 
#26033: Add argon2 password hasher
+
   Reporter:  timgraham |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  contrib.auth  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 argon2 is the winner of the [https://password-hashing.net Password Hashing
 Competition] and there was no objections
 [https://groups.google.com/d/topic/django-
 developers/NTfqP4eNVyA/discussion on the mailing list] to adding it.

 [https://github.com/django/django/pull/5876 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/052.23c4bc46ba3dbe5663641d701e040010%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21454: Ignoring certain fields on INSERT and UPDATE queries

2016-01-04 Thread Django 
#21454: Ignoring certain fields on INSERT and UPDATE queries
-+-
 Reporter:  mpessas  |Owner:  owais
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by owais):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #26028: Improve instructions for overriding Django templates (was: Improve instructions for overloading Django templates)

2016-01-04 Thread Django 
#26028: Improve instructions for overriding Django templates
---+
 Reporter:  pydanny|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.9
 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
---+
Description changed by timgraham:

Old description:

> For dj-stripe, I get asked how to do this a lot. Rather than include
> instructions on how to do this in that third-party package, shouldn't
> this be improved in the core documentation?
>
> Reference discussion: https://github.com/pydanny/dj-
> stripe/pull/254#issuecomment-168515982
>
> Existing instructions on template overloading:
>
> * Somewhere in the tutorials
> *
> https://docs.djangoproject.com/en/1.9/ref/templates/api/#django.template.loaders.app_directories.Loader
> (arguably obtuse)

New description:

 For dj-stripe, I get asked how to do this a lot. Rather than include
 instructions on how to do this in that third-party package, shouldn't this
 be improved in the core documentation?

 Reference discussion: https://github.com/pydanny/dj-
 stripe/pull/254#issuecomment-168515982

 Existing instructions on template overriding:

 * In the tutorial: https://docs.djangoproject.com/en/1.9/intro/tutorial07
 /#customizing-your-application-s-templates
 *
 
https://docs.djangoproject.com/en/1.9/ref/templates/api/#django.template.loaders.app_directories.Loader
 (arguably obtuse)

--

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

Re: [Django] #26028: Improve instructions for overloading Django templates

2016-01-04 Thread Django 
#26028: Improve instructions for overloading Django templates
---+
 Reporter:  pydanny|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.9
 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):

 * type:  Uncategorized => New feature
 * 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/065.e54334384f175f3456a9f0de23610d11%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26024: ConditionalGetMiddleware's ETag is broken

2016-01-04 Thread Django 
#26024: ConditionalGetMiddleware's ETag is broken
-+-
 Reporter:  samifahed|Owner:  samifahed
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.9
 Severity:  Release blocker  |   Resolution:
 Keywords:  Etags| 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):

 * severity:  Normal => Release blocker
 * 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/067.ac27ba697e34af76148e8e4badaa9fde%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26030: Password change, not validate if is current user.

2016-01-04 Thread Django 
#26030: Password change, not validate if is current user.
--+--
 Reporter:  RodolfoSilva  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:  worksforme
 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:   => worksforme
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 What error do you encounter? I think we'll need a sample project to
 reproduce it as I have no trouble and we have tests for this case. Thanks!

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

Re: [Django] #26031: cache.get_or_set isn't available in 1.8

2016-01-04 Thread Django 
#26031: cache.get_or_set isn't available in 1.8
-+-
 Reporter:  gautamk  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  cache, wrong-| Triage Stage:
  documentation  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I don't see a mention of "get_or_set" on the page you linked or in the
 "stable/1.8.x" branch.

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

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

Re: [Django] #23251: Use a temporary folder to store uploaded files during tests

2016-01-04 Thread Django 
#23251: Use a temporary folder to store uploaded files during tests
-+
 Reporter:  shai |Owner:  sasha0
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  file storage upload  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by aaugustin):

 I created #26029 to track the concept of multiple file storage backends,
 which may indeed make this easier to implement.

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

Re: [Django] #26029: Provide an API to configure arbitrary file storage backends

2016-01-04 Thread Django 
#26029: Provide an API to configure arbitrary file storage backends
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  File uploads/storage  |  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 sasha0):

 Configurable file storage backends was already proposed to introduce in
 terms of task #23251.

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

Re: [Django] #25748: Glossary: Project vs App

2016-01-04 Thread Django 
#25748: Glossary: Project vs App
--+
 Reporter:  guettli   |Owner:  nobody
 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:  0 |UI/UX:  0
--+

Comment (by guettli):

 Follow up: #26032

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

[Django] #26032: Where does `manage.py` belong: to Application or to Project?

2016-01-04 Thread Django 
#26032: Where does `manage.py` belong: to Application or to Project?
--+
 Reporter:  guettli   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 First: Thanks to Tim Graham for fixing the "app vs project" issue
 (https://code.djangoproject.com/ticket/25748)

 Here is the current part about "application":

 {{{
 The term **application** describes a Python package that provides some set
 of
 features. Applications :doc:`may be reused ` in
 various
 projects. A project's root directory (the one that contains ``manage.py``)
 is
 usually the container for all of a project's applications which aren't
 installed separately.
 }}}

 Where does "manage.py" belong?  to Application or to Project?

 My personal point of view is that it belongs to "project", since there can
 only be one script with this name.

 I think the above part in the docs needs to be improved. Maybe just move
 the sentence to the previous part.

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

Re: [Django] #26031: cache.get_or_set isn't available in 1.8

2016-01-04 Thread Django 
#26031: cache.get_or_set isn't available in 1.8
-+-
 Reporter:  gautamk  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  cache, wrong-| Triage Stage:
  documentation  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by gautamk:

Old description:

> The documentation wrongly suggest that cache.get_or_set is available in
> django 1.8,
>
> https://docs.djangoproject.com/en/1.8/topics/cache/#django.core.cache.caches
>
> but when I check the source under the 1.8.8 tag I couldn't find the
> method definition.
>
> https://github.com/django/django/blob/1.8.8/django/core/cache/backends/base.py

New description:

 The documentation wrongly suggests that cache.get_or_set is available in
 django 1.8,

 https://docs.djangoproject.com/en/1.8/topics/cache/#django.core.cache.caches

 but when I check the source under the 1.8.8 tag I couldn't find the method
 definition.

 https://github.com/django/django/blob/1.8.8/django/core/cache/backends/base.py

--

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

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

Re: [Django] #26031: cache.get_or_set isn't available in 1.8

2016-01-04 Thread Django 
#26031: cache.get_or_set isn't available in 1.8
-+-
 Reporter:  gautamk  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  cache, wrong-| Triage Stage:
  documentation  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by gautamk):

 * keywords:  cache, wrong documentation => cache, wrong-documentation
 * needs_better_patch:   => 0
 * 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/065.6a54cf7af57a0a44a63f4f3220dd2baf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26031: cache.get_or_set isn't available in 1.8

2016-01-04 Thread Django 
#26031: cache.get_or_set isn't available in 1.8
---+
 Reporter:  gautamk|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.8
 Severity:  Normal |   Keywords:  cache, wrong documentation
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 The documentation wrongly suggest that cache.get_or_set is available in
 django 1.8,

 https://docs.djangoproject.com/en/1.8/topics/cache/#django.core.cache.caches

 but when I check the source under the 1.8.8 tag I couldn't find the method
 definition.

 https://github.com/django/django/blob/1.8.8/django/core/cache/backends/base.py

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

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