[Django] #28779: PasswordChangeView and PasswordChangeDoneView do not use a custom REDIRECT_FIELD_NAME

2017-11-06 Thread Django
#28779: PasswordChangeView and PasswordChangeDoneView do not use a custom
REDIRECT_FIELD_NAME
---+
   Reporter:  Meiyer   |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Core (URLs)  |Version:  1.11
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 When a custom `REDIRECT_FIELD_NAME` is defined (for example, for the
 `LoginView` in urls.py), the two views `PasswordChangeView` and
 `PasswordChangeDoneView` will still use the built-in name ''`next`''. This
 is due to the decorator `django.contrib.auth.decorators.login_required`
 which uses the name from `django.contrib.auth.REDIRECT_FIELD_NAME` and is
 not customizable.

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


Re: [Django] #28514: Clarify docs regarding idempotence of RelatedManager.add()

2017-11-06 Thread Django
#28514: Clarify docs regarding idempotence of RelatedManager.add()
-+-
 Reporter:  Дилян Палаузов   |Owner:  Jezeniel
 Type:   |  Zapanta
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Jezeniel Zapanta):

 Replying to [comment:13 Дилян Палаузов]:
 > Regarding the PR at https://github.com/django/django/pull/9314 , as
 noted in my last comment above, .add() doesn't work as documented, if two
 threads call it with partially overlapping set of objects.

 What is the next step? Should I change the documentation that to handle
 concurrency problems you should handle IntegrityError? or wait for
 [https://code.djangoproject.com/ticket/28668 #28668] to be Implemented?

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


Re: [Django] #27395: Allow generating '

2017-11-06 Thread Django
#27395: Allow generating 'https://github.com/barseghyanartur/django-qartez

 It uses this usage pattern:

 {{{
 class ArticleSitemap(RelAlternateHreflangSitemap):
 # If you want to serve the links on HTTPS.
 protocol = 'https'

 def alternate_hreflangs(self, obj):
return [('en-us', obj.alternative_object_url),]

 def items(self):
return FooItem._default_manager.all()
 }}}

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


Re: [Django] #27395: Allow generating '

2017-11-06 Thread Django
#27395: Allow generating 'https://code.djangoproject.com/ticket/27395#comment:8>
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.60ff4e3c2a9faa4f049fdb8172d7ea2b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27395: Allow generating '

2017-11-06 Thread Django
#27395: Allow generating 'https://code.djangoproject.com/ticket/27395#comment:9>
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.1bafba54c03cf47cfc4b4808a7bceda9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28777: Clarify the docs for admin's @register's arguments (was: The register decorator description is badly worded - needs clarification)

2017-11-06 Thread Django
#28777: Clarify the docs for admin's @register's arguments
--+
 Reporter:  Matt Swan |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:  register decorator| 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):

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


Comment:

 Does this [https://github.com/django/django/pull/9331 PR] clarify?

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


Re: [Django] #28776: a/an/and typos in docs and comments

2017-11-06 Thread Django
#28776: a/an/and typos in docs and comments
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"e68baf386219ab64539ba5cef628811be03fdb84" e68baf3]:
 {{{
 #!CommitTicketReference repository=""
 revision="e68baf386219ab64539ba5cef628811be03fdb84"
 [2.0.x] Fixed #28776 -- Fixed a/an/and typos in docs and comments.

 Backport of 6c0042430e3618ce5c276d195d92a6b884daa3a3 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/072.2ad3db98413f9c9359ea25ce119a45b5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28776: a/an/and typos in docs and comments (was: Grammar a/an/and)

2017-11-06 Thread Django
#28776: a/an/and typos in docs and comments
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  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 Tim Graham):

 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Ready for checkin


Old description:

> {{{
> diff --git a/django/contrib/contenttypes/views.py
> b/django/contrib/contenttypes/views.py
> --- a/django/contrib/contenttypes/views.py
> +++ b/django/contrib/contenttypes/views.py
> @@ -50,7 +50,7 @@ def shortcut(request, content_type_id, object_id):
>
>  opts = obj._meta
>
> -# First, look for an many-to-many relationship to Site.
> +# First, look for a many-to-many relationship to Site.
>  for field in opts.many_to_many:
>  if field.remote_field.model is Site:
>  try:
> diff --git a/django/contrib/staticfiles/finders.py
> b/django/contrib/staticfiles/finders.py
> --- a/django/contrib/staticfiles/finders.py
> +++ b/django/contrib/staticfiles/finders.py
> @@ -204,7 +204,7 @@ class BaseStorageFinder(BaseFinder):
>  raise ImproperlyConfigured("The staticfiles storage finder
> %r "
> "doesn't have a storage class "
> "assigned." % self.__class__)
> -# Make sure we have an storage instance here.
> +# Make sure we have a storage instance here.
>  if not isinstance(self.storage, (Storage, LazyObject)):
>  self.storage = self.storage()
>  super().__init__(*args, **kwargs)
> diff --git a/django/core/files/uploadedfile.py
> b/django/core/files/uploadedfile.py
> --- a/django/core/files/uploadedfile.py
> +++ b/django/core/files/uploadedfile.py
> @@ -15,7 +15,7 @@ __all__ = ('UploadedFile', 'TemporaryUploadedFile',
> 'InMemoryUploadedFile',
>
>  class UploadedFile(File):
>  """
> -A abstract uploaded file (``TemporaryUploadedFile`` and
> +An abstract uploaded file (``TemporaryUploadedFile`` and
>  ``InMemoryUploadedFile`` are the built-in concrete subclasses).
>
>  An ``UploadedFile`` object behaves somewhat like a file object and
> diff --git a/django/core/mail/backends/filebased.py
> b/django/core/mail/backends/filebased.py
> --- a/django/core/mail/backends/filebased.py
> +++ b/django/core/mail/backends/filebased.py
> @@ -21,7 +21,7 @@ class EmailBackend(ConsoleEmailBackend):
>  if not isinstance(self.file_path, str):
>  raise ImproperlyConfigured('Path for saving emails is
> invalid: %r' % self.file_path)
>  self.file_path = os.path.abspath(self.file_path)
> -# Make sure that self.file_path is an directory if it exists.
> +# Make sure that self.file_path is a directory if it exists.
>  if os.path.exists(self.file_path) and not
> os.path.isdir(self.file_path):
>  raise ImproperlyConfigured(
>  'Path for saving email messages exists, but is not a
> directory: %s' % self.file_path
> diff --git a/django/core/management/commands/loaddata.py
> b/django/core/management/commands/loaddata.py
> --- a/django/core/management/commands/loaddata.py
> +++ b/django/core/management/commands/loaddata.py
> @@ -72,7 +72,7 @@ class Command(BaseCommand):
>  self.loaddata(fixture_labels)
>
>  # Close the DB connection -- unless we're still in a
> transaction. This
> -# is required as a workaround for an  edge case in MySQL: if the
> same
> +# is required as a workaround for an edge case in MySQL: if the
> same
>  # connection is used to create tables, load data, and query, the
> query
>  # can return incorrect results. See Django #7572, MySQL #37735.
>  if transaction.get_autocommit(self.using):
> diff --git a/django/db/models/fields/related_lookups.py
> b/django/db/models/fields/related_lookups.py
> --- a/django/db/models/fields/related_lookups.py
> +++ b/django/db/models/fields/related_lookups.py
> @@ -63,7 +63,7 @@ class RelatedIn(In):
>  if isinstance(self.lhs, MultiColSource):
>  # For multicolumn lookups we need to build a multicolumn
> where clause.
>  # This clause is either a SubqueryConstraint (for values
> that need to be compiled to
> -# SQL) or a OR-combined list of (col1 = val1 AND col2 = val2
> AND ...) cl

Re: [Django] #28776: Grammar a/an/and

2017-11-06 Thread Django
#28776: Grammar a/an/and
+--
 Reporter:  Дилян Палаузов  |Owner:  nobody
 Type:  Uncategorized   |   Status:  closed
Component:  Documentation   |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"6c0042430e3618ce5c276d195d92a6b884daa3a3" 6c004243]:
 {{{
 #!CommitTicketReference repository=""
 revision="6c0042430e3618ce5c276d195d92a6b884daa3a3"
 Fixed #28776 -- Fixed a/an/and typos in docs and comments.
 }}}

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


Re: [Django] #28778: Contribution guide missing django installation instructions

2017-11-06 Thread Django
#28778: Contribution guide missing django installation instructions
-+-
 Reporter:  Hrishikesh Barman|Owner:
 Type:   |  Hrishikesh Barman
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  testcases,   | Triage Stage:
  contribution   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 This isn't necessary. I think you missed the `pip install -e
 /path/to/your/local/clone/django/` command from earlier.

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


Re: [Django] #28778: Contribution guide missing django installation instructions

2017-11-06 Thread Django
#28778: Contribution guide missing django installation instructions
-+-
 Reporter:  Hrishikesh Barman|Owner:
 Type:   |  Hrishikesh Barman
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  testcases,   | Triage Stage:
  contribution   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hrishikesh Barman):

 * cc: Hrishikesh Barman (added)
 * owner:  nobody => Hrishikesh Barman


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


[Django] #28778: Contribution guide missing django installation instructions

2017-11-06 Thread Django
#28778: Contribution guide missing django installation instructions
-+-
   Reporter: |  Owner:  nobody
  Hrishikesh Barman  |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component: |Version:  1.11
  Documentation  |   Keywords:  testcases,
   Severity:  Normal |  contribution
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The **Writing your first patch for Django**
 (https://docs.djangoproject.com/en/1.11/intro/contributing/) misses on
 mentioning the installation of django using `python setup.py install` .

 It does have clear instructions about installing the dependencies using
 `pip install -r requirements/py3.txt` but that does not install django, if
 if you install django using `pip install django` it installs some other
 version of django that fails the test cases.

 I cloned the latest version from github, and pip installs django1.11.7 and
 test cases give error, when I do `setup.py install` it installs django2.0
 and test cases ran successfully.

 so, adding a line about installing the version of django using `python
 setup.py install` will be helpful.

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


Re: [Django] #28316: ModelChoiceField to_field_name doesn't work if it's different from the model field's to_field

2017-11-06 Thread Django
#28316: ModelChoiceField to_field_name doesn't work if it's different from the
model field's to_field
+--
 Reporter:  László Károlyi  |Owner:  László Károlyi
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+--

Comment (by George Khaburzaniya):

 Original PR was closed, new PR here
 https://github.com/django/django/pull/8745

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


Re: [Django] #28777: The register decorator description is badly worded - needs clarification

2017-11-06 Thread Django
#28777: The register decorator description is badly worded - needs clarification
-+-
 Reporter:  Matt Swan|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  register decorator   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Matt Swan:

Old description:

> The description text for the register decorator has a complex sentence
> that is badly worded and not proper english, meaning that the functions
> usage is not properly described.
>
> This page:
> [https://docs.djangoproject.com/en/1.11/ref/contrib/admin/]
> Please reword this sentence so it make sense:
>
> "It is given one or more model classes to register with the ModelAdmin
> and an optional keyword argument site if you are not using the default
> AdminSite:"
>
> Suggested changes - but I don't understand the sentence so the suggestion
> is just a guess:
>
> "It is given IF/FOR(?) one or more model classes to register with the
> ModelAdmin and an optional keyword argument site FULL STOP. If you are
> not using the default AdminSite:"

New description:

 The description text for the register decorator has a complex sentence
 that is badly worded and not proper english, meaning that the functions
 usage is not properly described.

 This page:
 [https://docs.djangoproject.com/en/1.11/ref/contrib/admin/]
 Please reword this sentence so it make sense:

   It is given one or more model classes to register with the ModelAdmin
 and an optional keyword argument site if you are not using the default
 AdminSite:

 Suggested changes - but I don't understand the sentence so the suggestion
 is just a guess:

 "It is given IF/FOR(?) one or more model classes to register with the
 ModelAdmin and an optional keyword argument site FULL STOP. If you are not
 using the default AdminSite:"

--

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


[Django] #28777: The register decorator description is badly worded - needs clarification

2017-11-06 Thread Django
#28777: The register decorator description is badly worded - needs clarification
-+-
   Reporter:  Matt Swan  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  1.11
  Documentation  |
   Severity:  Normal |   Keywords:  register decorator
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 The description text for the register decorator has a complex sentence
 that is badly worded and not proper english, meaning that the functions
 usage is not properly described.

 This page:
 [https://docs.djangoproject.com/en/1.11/ref/contrib/admin/]
 Please reword this sentence so it make sense:

 "It is given one or more model classes to register with the ModelAdmin and
 an optional keyword argument site if you are not using the default
 AdminSite:"

 Suggested changes - but I don't understand the sentence so the suggestion
 is just a guess:

 "It is given IF/FOR(?) one or more model classes to register with the
 ModelAdmin and an optional keyword argument site FULL STOP. If you are not
 using the default AdminSite:"

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


Re: [Django] #28761: Document prefixes in InlineFormsets

2017-11-06 Thread Django
#28761: Document prefixes in InlineFormsets
-+-
 Reporter:  Jay Welborn  |Owner:  Jay
 Type:   |  Welborn
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  InlineFormsets   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Martin):

 * needs_better_patch:  0 => 1


Comment:

 This looks good, thanks for documenting. I added one (and a half!)
 comments on the pull request.

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


Re: [Django] #28731: Passing an empty Q() to a When inside a Case causes an OperationError

2017-11-06 Thread Django
#28731: Passing an empty Q() to a When inside a Case causes an OperationError
-+-
 Reporter:  Tom van Bussel   |Owner:  Tim
 |  Martin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (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 Adam (Chainz) Johnson):

 Those are some good points Tim/Tomer. I agree that making When() raise an
 error when passed an empty Q would make sense.

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


Re: [Django] #28731: Passing an empty Q() to a When inside a Case causes an OperationError

2017-11-06 Thread Django
#28731: Passing an empty Q() to a When inside a Case causes an OperationError
-+-
 Reporter:  Tom van Bussel   |Owner:  Tim
 |  Martin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (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 Tim Martin):

 Worse, you get the same result for `Q() & Q(value=1)` as you do for `Q() |
 Q(value=1)`, because empty `Q()` expressions are ignored when combining
 (`query_utils.py:68`). I don't think there's an easy way to make this
 consistent.

 I'm guessing it should be possible to make the originally reported case
 not trigger invalid SQL, which is a step forward. Maybe it should report
 this as an invalid expression?

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


Re: [Django] #28776: Grammar a/an/and

2017-11-06 Thread Django
#28776: Grammar a/an/and
+--
 Reporter:  Дилян Палаузов  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Documentation   |  Version:  master
 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 Дилян Палаузов):

 * Attachment "grammar-a-an-and.patch" added.

 a/an/and

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


[Django] #28776: Grammar a/an/and

2017-11-06 Thread Django
#28776: Grammar a/an/and
--+
   Reporter:  Дилян Палаузов  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Documentation   |Version:  master
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 {{{
 diff --git a/django/contrib/contenttypes/views.py
 b/django/contrib/contenttypes/views.py
 --- a/django/contrib/contenttypes/views.py
 +++ b/django/contrib/contenttypes/views.py
 @@ -50,7 +50,7 @@ def shortcut(request, content_type_id, object_id):

  opts = obj._meta

 -# First, look for an many-to-many relationship to Site.
 +# First, look for a many-to-many relationship to Site.
  for field in opts.many_to_many:
  if field.remote_field.model is Site:
  try:
 diff --git a/django/contrib/staticfiles/finders.py
 b/django/contrib/staticfiles/finders.py
 --- a/django/contrib/staticfiles/finders.py
 +++ b/django/contrib/staticfiles/finders.py
 @@ -204,7 +204,7 @@ class BaseStorageFinder(BaseFinder):
  raise ImproperlyConfigured("The staticfiles storage finder %r
 "
 "doesn't have a storage class "
 "assigned." % self.__class__)
 -# Make sure we have an storage instance here.
 +# Make sure we have a storage instance here.
  if not isinstance(self.storage, (Storage, LazyObject)):
  self.storage = self.storage()
  super().__init__(*args, **kwargs)
 diff --git a/django/core/files/uploadedfile.py
 b/django/core/files/uploadedfile.py
 --- a/django/core/files/uploadedfile.py
 +++ b/django/core/files/uploadedfile.py
 @@ -15,7 +15,7 @@ __all__ = ('UploadedFile', 'TemporaryUploadedFile',
 'InMemoryUploadedFile',

  class UploadedFile(File):
  """
 -A abstract uploaded file (``TemporaryUploadedFile`` and
 +An abstract uploaded file (``TemporaryUploadedFile`` and
  ``InMemoryUploadedFile`` are the built-in concrete subclasses).

  An ``UploadedFile`` object behaves somewhat like a file object and
 diff --git a/django/core/mail/backends/filebased.py
 b/django/core/mail/backends/filebased.py
 --- a/django/core/mail/backends/filebased.py
 +++ b/django/core/mail/backends/filebased.py
 @@ -21,7 +21,7 @@ class EmailBackend(ConsoleEmailBackend):
  if not isinstance(self.file_path, str):
  raise ImproperlyConfigured('Path for saving emails is
 invalid: %r' % self.file_path)
  self.file_path = os.path.abspath(self.file_path)
 -# Make sure that self.file_path is an directory if it exists.
 +# Make sure that self.file_path is a directory if it exists.
  if os.path.exists(self.file_path) and not
 os.path.isdir(self.file_path):
  raise ImproperlyConfigured(
  'Path for saving email messages exists, but is not a
 directory: %s' % self.file_path
 diff --git a/django/core/management/commands/loaddata.py
 b/django/core/management/commands/loaddata.py
 --- a/django/core/management/commands/loaddata.py
 +++ b/django/core/management/commands/loaddata.py
 @@ -72,7 +72,7 @@ class Command(BaseCommand):
  self.loaddata(fixture_labels)

  # Close the DB connection -- unless we're still in a transaction.
 This
 -# is required as a workaround for an  edge case in MySQL: if the
 same
 +# is required as a workaround for an edge case in MySQL: if the
 same
  # connection is used to create tables, load data, and query, the
 query
  # can return incorrect results. See Django #7572, MySQL #37735.
  if transaction.get_autocommit(self.using):
 diff --git a/django/db/models/fields/related_lookups.py
 b/django/db/models/fields/related_lookups.py
 --- a/django/db/models/fields/related_lookups.py
 +++ b/django/db/models/fields/related_lookups.py
 @@ -63,7 +63,7 @@ class RelatedIn(In):
  if isinstance(self.lhs, MultiColSource):
  # For multicolumn lookups we need to build a multicolumn
 where clause.
  # This clause is either a SubqueryConstraint (for values that
 need to be compiled to
 -# SQL) or a OR-combined list of (col1 = val1 AND col2 = val2
 AND ...) clauses.
 +# SQL) or an OR-combined list of (col1 = val1 AND col2 = val2
 AND ...) clauses.
  from django.db.models.sql.where import WhereNode,
 SubqueryConstraint, AND, OR

  root_constraint = WhereNode(connector=OR)
 diff --git a/django/http/response.py b/django/http/response.py
 --- a/django/http/response.py
 +++ b/django/http/r

Re: [Django] #28518: improve performance of loading geometries from DB

2017-11-06 Thread Django
#28518: improve performance of loading geometries from DB
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sergey Fedoseev):

 [https://github.com/django/django/pull/9329 PR]

 Before:
 {{{
 In [2]: %timeit for x in City.objects.all()[:1000]: pass
 106 ms ± 802 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
 }}}
 After:
 {{{
 In [2]: %timeit for x in City.objects.all()[:1000]: pass
 81.8 ms ± 595 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
 }}}

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


Re: [Django] #28774: Use only a specific database schema instead of 'public' one (like in Postgresql)

2017-11-06 Thread Django
#28774: Use only a specific database schema instead of 'public' one (like in
Postgresql)
-+-
 Reporter:  Riccardo Campisano   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  django, orm, | Triage Stage:
  database, postgresql, schema   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Riccardo Campisano):

 Thank you for the tip and the link to the discussion.

 Riccardo

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


Re: [Django] #28765: Clarify the documentation about what types the __in lookup accepts

2017-11-06 Thread Django
#28765: Clarify the documentation about what types the __in lookup accepts
--+
 Reporter:  Дилян Палаузов|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.11
 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:"bcaef2c91d234fe742973eb7df8a47f2048d3e63" bcaef2c9]:
 {{{
 #!CommitTicketReference repository=""
 revision="bcaef2c91d234fe742973eb7df8a47f2048d3e63"
 [2.0.x] Fixed #28765 -- Clarified docs about what types the __in lookup
 accepts.

 Backport of 5587485d49af8b32ab660854f751a234baa6610b 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/072.c37b97939d69ec03625b9fdf80c6c519%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28765: Clarify the documentation about what types the __in lookup accepts

2017-11-06 Thread Django
#28765: Clarify the documentation about what types the __in lookup accepts
--+
 Reporter:  Дилян Палаузов|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.11
 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 GitHub ):

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


Comment:

 In [changeset:"5587485d49af8b32ab660854f751a234baa6610b" 5587485d]:
 {{{
 #!CommitTicketReference repository=""
 revision="5587485d49af8b32ab660854f751a234baa6610b"
 Fixed #28765 -- Clarified docs about what types the __in lookup accepts.
 }}}

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


Re: [Django] #28766: Add route information to ResolverMatch

2017-11-06 Thread Django
#28766: Add route information to ResolverMatch
-+-
 Reporter:  Benjamin Wohlwend|Owner:  Benjamin
 |  Wohlwend
 Type:  New feature  |   Status:  assigned
Component:  Core (URLs)  |  Version:  2.0
 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
-+-

Comment (by Tim Graham):

 The first argument of `re_path()` is also documented as `route` so I think
 it's okay to use that.

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

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


[Django] #28775: Queryset last() does not honor slices

2017-11-06 Thread Django
#28775: Queryset last() does not honor slices
-+-
   Reporter:  Liquid |  Owner:  nobody
  Scorpio|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Assume there is a time series of records for 100 days.

 {{{
 MyModel.objects.all().order_by('-date').last()
 }}}

 Returns the oldest record in the time series, which is same as returned
 by:

 {{{
 MyModel.objects.all().order_by('-date')[:10].last()
 }}}


 This is not intuitive. Should return the 10th newest record, the slice
 operator [:10] should be honoured.

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

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


Re: [Django] #28773: manage.py makemessages throws syntax error due to incorrectly generated django.pot

2017-11-06 Thread Django
#28773: manage.py makemessages throws syntax error due to incorrectly generated
django.pot
-+-
 Reporter:  Hendy Irawan |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  gettext, | Triage Stage:
  makemessages, Windows  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Can you provide a sample project that reproduces the problem and point to
 the code in Django that's at fault?

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


Re: [Django] #28774: Use only a specific database schema instead of 'public' one (like in Postgresql)

2017-11-06 Thread Django
#28774: Use only a specific database schema instead of 'public' one (like in
Postgresql)
-+-
 Reporter:  Riccardo Campisano   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  django, orm, | Triage Stage:
  database, postgresql, schema   |  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:   => duplicate


Comment:

 Official support for database schemas is discussed in #6148.

 I think the `'-c search_path=qlf_schema'` method you mentioned uses a
 psycopg2 configuration option and I wouldn't expect that to stop working
 unless psycopg2 changes it.

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

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


Re: [Django] #28560: distinct() on ordered queryset with restricted list of columns returns incorrect result

2017-11-06 Thread Django
#28560: distinct() on ordered queryset with restricted list of columns returns
incorrect result
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  distinct values  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

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


[Django] #28774: Use only a specific database schema instead of 'public' one (like in Postgresql)

2017-11-06 Thread Django
#28774: Use only a specific database schema instead of 'public' one (like in
Postgresql)
-+-
   Reporter:  Riccardo   |  Owner:  nobody
  Campisano  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.8
  layer (models, ORM)|   Keywords:  django, orm,
   Severity:  Normal |  database, postgresql, schema
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,

 In our project (https://github.com/desihub/qlf) we should use a PostgreSQL
 database used by others application, so that we want to configure Django
 ORM to use just a specific schema.

 I cannot find such kind of configurations in the official documentation. A
 tip for a kind of such configuration is available in

   https://www.amvtek.com/blog/posts/2014/Jun/13/accessing-multiple-
 postgres-schemas-from-django/

 and it appears to work, using a specific config like that

 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql_psycopg2',
 'OPTIONS': {
 'options': '-c search_path=qlf_schema'
 },
 },
 }}}

 However, I would be sure that this is the correct (official, supported)
 way to do such thing, and that will be supported in the future (and that
 this is not a workaround that currently work but can break in a next
 version of Django).

 Thanks,
 Riccardo

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


Re: [Django] #28514: Clarify docs regarding idempotence of RelatedManager.add()

2017-11-06 Thread Django
#28514: Clarify docs regarding idempotence of RelatedManager.add()
-+-
 Reporter:  Дилян Палаузов   |Owner:  Jezeniel
 Type:   |  Zapanta
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Дилян Палаузов):

 Regarding the PR at https://github.com/django/django/pull/9314 , as noted
 in my last comment above, .add() works not as documented, if two threats
 call it with partially overlapping set of objects.

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


Re: [Django] #28771: Add a model field option that corresponds to the short_description admin property (was: column short description could be a property of the column: listview column heading)

2017-11-06 Thread Django
#28771: Add a model field option that corresponds to the short_description admin
property
-+-
 Reporter:  Rick Graves  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  admin listview   | Triage Stage:
  column names   |  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:   => wontfix


Comment:

 I think what you refer to as "long description" is the `verbose_name`
 argument. This is used in many places throughout Django.

 I think more use cases than a shortcut for `short_description` in the
 admin is needed to justify adding a new model field option. This is also
 the type of proposal that needs a consensus on the DevelopersMailingList
 before we proceed with it. Feel free to post there if you can add more
 justification to your proposal.

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


Re: [Django] #28584: Remove workarounds for SQLite < 3.7.15

2017-11-06 Thread Django
#28584: Remove workarounds for SQLite < 3.7.15
-+-
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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):

 I didn't think it would affect anyone. Did you run into a problem?

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


Re: [Django] #28584: Remove workarounds for SQLite < 3.7.15

2017-11-06 Thread Django
#28584: Remove workarounds for SQLite < 3.7.15
-+-
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Дилян Палаузов):

 The dropped support for SQLite  < 3.7.15 is not reflected in the release
 notes.

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


Re: [Django] #28769: Utilize 'x or y' in place of 'x if x else y'

2017-11-06 Thread Django
#28769: Utilize 'x or y' in place of 'x if x else y'
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.11
 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 Tim Graham):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Ready for checkin


Comment:

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


Re: [Django] #28501: "python -m django runserver" crashes

2017-11-06 Thread Django
#28501: "python -m django runserver" crashes
-+-
 Reporter:  Kit Darko|Owner:  Yusuke
 |  Miyazaki
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.11
  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
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"278d66b94bb443e1c1581e014fee2593a33f338c" 278d66b9]:
 {{{
 #!CommitTicketReference repository=""
 revision="278d66b94bb443e1c1581e014fee2593a33f338c"
 Fixed #28501 -- Fixed "python -m django runserver" crash.
 }}}

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


Re: [Django] #28766: Add route information to ResolverMatch

2017-11-06 Thread Django
#28766: Add route information to ResolverMatch
-+-
 Reporter:  Benjamin Wohlwend|Owner:  Benjamin
 |  Wohlwend
 Type:  New feature  |   Status:  assigned
Component:  Core (URLs)  |  Version:  2.0
 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
-+-

Comment (by Benjamin Wohlwend):

 OK. However, in that case I think the attribute on `ResolverMatch` should
 be named differently, since AFAICT, "route" is specific to the new
 simplified URLs from DEP 201. Maybe `ResolverMatch.pattern`?

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


Re: [Django] #28766: Add route information to ResolverMatch

2017-11-06 Thread Django
#28766: Add route information to ResolverMatch
-+-
 Reporter:  Benjamin Wohlwend|Owner:  Benjamin
 |  Wohlwend
 Type:  New feature  |   Status:  assigned
Component:  Core (URLs)  |  Version:  2.0
 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
-+-

Comment (by Tim Graham):

 Yes, that's what I meant to suggest.

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


Re: [Django] #28773: manage.py makemessages throws syntax error due to incorrectly generated django.pot

2017-11-06 Thread Django
#28773: manage.py makemessages throws syntax error due to incorrectly generated
django.pot
-+-
 Reporter:  Hendy Irawan |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  gettext, | Triage Stage:
  makemessages, Windows  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Hendy Irawan:

Old description:

> This only happens after there are several translations (so it's not
> happening on a clean project with very few translations).
> And I'm on Windows. Seems related to #28409.
>
> {{{
> (venv) C:\Users\ceefour\git\samara\samaraweb>python manage.py
> makemessages -l id_ID --keep-pot -v3
> examining files with the extensions: .py, .txt and .html
> ignoring file .gitignore in .
> ignoring file README.md in .
> ignoring file 0001_initial.cpython-36.pyc in .\edu\migrations\__pycache__
> ignoring file 0002_category.cpython-36.pyc in
> .\edu\migrations\__pycache__
> ignoring file 0003_profile.cpython-36.pyc in .\edu\migrations\__pycache__
> ignoring file 0004_profile_price_range.cpython-36.pyc in
> .\edu\migrations\__pycache__
> ignoring file __init__.cpython-36.pyc in .\edu\migrations\__pycache__
> ignoring file admin.cpython-36.pyc in .\edu\__pycache__
> ignoring file apps.cpython-36.pyc in .\edu\__pycache__
> ignoring file models.cpython-36.pyc in .\edu\__pycache__
> ignoring file urls.cpython-36.pyc in .\edu\__pycache__
> ignoring file urls_root.cpython-36.pyc in .\edu\__pycache__
> ignoring file views.cpython-36.pyc in .\edu\__pycache__
> ignoring file views_root.cpython-36.pyc in .\edu\__pycache__
> ignoring file __init__.cpython-36.pyc in .\edu\__pycache__
> ignoring file context_processors.cpython-36.pyc in
> .\samaraweb\__pycache__
> ignoring file middleware.cpython-36.pyc in .\samaraweb\__pycache__
> ignoring file settings.cpython-36.pyc in .\samaraweb\__pycache__
> ignoring file urls.cpython-36.pyc in .\samaraweb\__pycache__
> ignoring file wsgi.cpython-36.pyc in .\samaraweb\__pycache__
> ignoring file __init__.cpython-36.pyc in .\samaraweb\__pycache__
> ignoring file samara_dev_public_edu_brand.sql in .\snapshot
> ignoring file samara_dev_public_edu_category.sql in .\snapshot
> ignoring file samara_dev_public_edu_city.sql in .\snapshot
> ignoring file samara_dev_public_edu_country.sql in .\snapshot
> ignoring file samara_dev_public_edu_place.sql in .\snapshot
> ignoring file samara_dev_public_edu_populatedplace.sql in .\snapshot
> ignoring file samara_dev_public_edu_profile.sql in .\snapshot
> ignoring file samara_dev_public_edu_profile_categories.sql in .\snapshot
> ignoring file samara_dev_public_edu_state.sql in .\snapshot
> processing file __init__.py in .\edu
> processing file admin.py in .\edu
> processing file apps.py in .\edu
> processing file 0001_initial.py in .\edu\migrations
> processing file 0002_category.py in .\edu\migrations
> processing file 0003_profile.py in .\edu\migrations
> processing file 0004_profile_price_range.py in .\edu\migrations
> processing file __init__.py in .\edu\migrations
> processing file models.py in .\edu
> processing file base.html in .\edu\templates\edu
> processing file footer.html in .\edu\templates\edu
> processing file header.html in .\edu\templates\edu
> processing file home.html in .\edu\templates\edu
> processing file index.html in .\edu\templates\edu
> processing file loc_detail.html in .\edu\templates\edu
> processing file org_detail.html in .\edu\templates\edu
> processing file privacy.html in .\edu\templates\edu
> processing file terms.html in .\edu\templates\edu
> processing file tests.py in .\edu
> processing file urls.py in .\edu
> processing file urls_root.py in .\edu
> processing file views.py in .\edu
> processing file views_root.py in .\edu
> processing file manage.py in .
> processing file __init__.py in .\samaraweb
> processing file context_processors.py in .\samaraweb
> processing file middleware.py in .\samaraweb
> processing file settings.dev.py in .\samaraweb
> processing file settings.prd.py in .\samaraweb
> processing file settings.py in .\samaraweb
> processing file urls.py in .\samaraweb
> processing file wsgi.py in .\samaraweb
> processing locale id_ID
> CommandError: errors happened while running msgmerge
> C:\Users\ceefour\git\samara\samaraweb\edu\locale\django.pot:61:3: syntax
> error
> C:\Users\ceefour\git\samara\samaraweb\edu\locale\django.pot:61: keyword
> "edu" unknown
> C:\Users\ceefour\git\samara\samaraw

Re: [Django] #28772: UnicodeWarning produced when using callable default on BinaryField in Python 2

2017-11-06 Thread Django
#28772: UnicodeWarning produced when using callable default on BinaryField in
Python 2
-+-
 Reporter:  Tim Dawborn  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  UnicodeWarning   | Triage Stage:
  BinaryField|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * type:  Uncategorized => Cleanup/optimization
 * resolution:   => wontfix


Comment:

 #23222 is related. As Django's master branch (and the upcoming 2.0
 release) no longer support Python 2 and this issue doesn't qualify for a
 backport to 1.11 as per our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy], we won't fix it.

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

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


[Django] #28773: manage.py makemessages throws syntax error due to incorrectly generated django.pot

2017-11-06 Thread Django
#28773: manage.py makemessages throws syntax error due to incorrectly generated
django.pot
-+-
   Reporter:  Hendy  |  Owner:  nobody
  Irawan |
   Type:  Bug| Status:  new
  Component: |Version:  1.11
  Internationalization   |   Keywords:  gettext,
   Severity:  Normal |  makemessages, Windows
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This only happens after there are several translations (so it's not
 happening on a clean project with very few translations).
 And I'm on Windows. Seems related to #28409.

 {{{
 (venv) C:\Users\ceefour\git\samara\samaraweb>python manage.py makemessages
 -l id_ID --keep-pot -v3
 examining files with the extensions: .py, .txt and .html
 ignoring file .gitignore in .
 ignoring file README.md in .
 ignoring file 0001_initial.cpython-36.pyc in .\edu\migrations\__pycache__
 ignoring file 0002_category.cpython-36.pyc in .\edu\migrations\__pycache__
 ignoring file 0003_profile.cpython-36.pyc in .\edu\migrations\__pycache__
 ignoring file 0004_profile_price_range.cpython-36.pyc in
 .\edu\migrations\__pycache__
 ignoring file __init__.cpython-36.pyc in .\edu\migrations\__pycache__
 ignoring file admin.cpython-36.pyc in .\edu\__pycache__
 ignoring file apps.cpython-36.pyc in .\edu\__pycache__
 ignoring file models.cpython-36.pyc in .\edu\__pycache__
 ignoring file urls.cpython-36.pyc in .\edu\__pycache__
 ignoring file urls_root.cpython-36.pyc in .\edu\__pycache__
 ignoring file views.cpython-36.pyc in .\edu\__pycache__
 ignoring file views_root.cpython-36.pyc in .\edu\__pycache__
 ignoring file __init__.cpython-36.pyc in .\edu\__pycache__
 ignoring file context_processors.cpython-36.pyc in .\samaraweb\__pycache__
 ignoring file middleware.cpython-36.pyc in .\samaraweb\__pycache__
 ignoring file settings.cpython-36.pyc in .\samaraweb\__pycache__
 ignoring file urls.cpython-36.pyc in .\samaraweb\__pycache__
 ignoring file wsgi.cpython-36.pyc in .\samaraweb\__pycache__
 ignoring file __init__.cpython-36.pyc in .\samaraweb\__pycache__
 ignoring file samara_dev_public_edu_brand.sql in .\snapshot
 ignoring file samara_dev_public_edu_category.sql in .\snapshot
 ignoring file samara_dev_public_edu_city.sql in .\snapshot
 ignoring file samara_dev_public_edu_country.sql in .\snapshot
 ignoring file samara_dev_public_edu_place.sql in .\snapshot
 ignoring file samara_dev_public_edu_populatedplace.sql in .\snapshot
 ignoring file samara_dev_public_edu_profile.sql in .\snapshot
 ignoring file samara_dev_public_edu_profile_categories.sql in .\snapshot
 ignoring file samara_dev_public_edu_state.sql in .\snapshot
 processing file __init__.py in .\edu
 processing file admin.py in .\edu
 processing file apps.py in .\edu
 processing file 0001_initial.py in .\edu\migrations
 processing file 0002_category.py in .\edu\migrations
 processing file 0003_profile.py in .\edu\migrations
 processing file 0004_profile_price_range.py in .\edu\migrations
 processing file __init__.py in .\edu\migrations
 processing file models.py in .\edu
 processing file base.html in .\edu\templates\edu
 processing file footer.html in .\edu\templates\edu
 processing file header.html in .\edu\templates\edu
 processing file home.html in .\edu\templates\edu
 processing file index.html in .\edu\templates\edu
 processing file loc_detail.html in .\edu\templates\edu
 processing file org_detail.html in .\edu\templates\edu
 processing file privacy.html in .\edu\templates\edu
 processing file terms.html in .\edu\templates\edu
 processing file tests.py in .\edu
 processing file urls.py in .\edu
 processing file urls_root.py in .\edu
 processing file views.py in .\edu
 processing file views_root.py in .\edu
 processing file manage.py in .
 processing file __init__.py in .\samaraweb
 processing file context_processors.py in .\samaraweb
 processing file middleware.py in .\samaraweb
 processing file settings.dev.py in .\samaraweb
 processing file settings.prd.py in .\samaraweb
 processing file settings.py in .\samaraweb
 processing file urls.py in .\samaraweb
 processing file wsgi.py in .\samaraweb
 processing locale id_ID
 CommandError: errors happened while running msgmerge
 C:\Users\ceefour\git\samara\samaraweb\edu\locale\django.pot:61:3: syntax
 error
 C:\Users\ceefour\git\samara\samaraweb\edu\locale\django.pot:61: keyword
 "edu" unknown
 C:\Users\ceefour\git\samara\samaraweb\edu\locale\django.pot:61: keyword
 "templates" unknown
 C:\Users\ceefour\git\samara\samaraweb\edu\locale\django.pot:61: keyword
 "edu" unknown
 C:\Users\ceefour\git\samara

Re: [Django] #23977: Add setdefault() to HttpResponse

2017-11-06 Thread Django
#23977: Add setdefault() to HttpResponse
-+-
 Reporter:  Robert Coup  |Owner:  Sergey
 Type:  New feature  |   Status:  closed
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:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Please open a new ticket rather then reopening an existing one that's been
 fixed for three years.  You can provide patches as attachments rather than
 as comments.

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


Re: [Django] #15665: Inline admins are broken when primary key is not an AutoField and not editable.

2017-11-06 Thread Django
#15665: Inline admins are broken when primary key is not an AutoField and not
editable.
-+
 Reporter:  Sebastian Noack  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Andi Albrecht):

 * cc: Andi Albrecht (added)


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

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


Re: [Django] #23977: Add setdefault() to HttpResponse

2017-11-06 Thread Django
#23977: Add setdefault() to HttpResponse
-+-
 Reporter:  Robert Coup  |Owner:  Sergey
 Type:  New feature  |   Status:  new
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:  1|UI/UX:  0
-+-
Changes (by Дилян Палаузов):

 * status:  closed => new
 * cc: Дилян Палаузов (added)
 * resolution:  fixed =>


Comment:

 HttpResponseBase.setdefault should return a value in order to be
 consistent with dict.setdefault and what users expect from a function
 called setdefault on an objects, that behaves like dict.

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


[Django] #28772: UnicodeWarning produced when using callable default on BinaryField in Python 2

2017-11-06 Thread Django
#28772: UnicodeWarning produced when using callable default on BinaryField in
Python 2
-+-
   Reporter:  Tim|  Owner:  nobody
  Dawborn|
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.8
  layer (models, ORM)|   Keywords:  UnicodeWarning
   Severity:  Normal |  BinaryField
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 This affects versions all the way back from 1.8 and the rest of the 1.x
 series (the issue tracker only lets me go back to 1.8). This only happens
 when running under Python 2.

 When using a callable `default` value to a `BinaryField` instance, a
 `UnicodeWarning` is produced due to the comparison of the return value of
 `default` against a Unicode string (from
 
https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2306):

 {{{#!python
 class BinaryField(Field):
 ...
 def get_default(self):
 if self.has_default() and not callable(self.default):
 return self.default
 default = super(BinaryField, self).get_default()
 if default == '':
 return b''
 return default
 }}}


 I've created a blank Django project called `foo` and created an app called
 `bar`. In there, I've created a model called `Baz` which has a
 `BinaryField` with a callable default.

 {{{
 $ cat bar/models.py
 import os

 from django.db import models


 def my_default():
 return os.urandom(12)


 class Baz(models.Model):
 my_field = models.BinaryField(default=my_default)
 }}}

 I have two virtualenvs setup — one running Python 2.7 and one running 3.6.
 Both have Django 1.11 installed:
 {{{
 $ ../ve2/bin/pip install -q --upgrade 'django<2'
 $ ../ve3/bin/pip install -q --upgrade 'django<2'
 }}}

 When running under Python 2, Django versions 1.8 through 1.11 (all minor
 versions inclusive) produce a `UnicodeWarning` when deprecation warnings
 are enabled:
 {{{
 $ ../ve2/bin/python -W default manage.py shell -c 'from bar.models import
 Baz; b = Baz()'
 /private/tmp/django/ve2/lib/python2.7/site-
 packages/django/db/models/fields/__init__.py:2343: UnicodeWarning: Unicode
 equal comparison failed to convert both arguments to Unicode -
 interpreting them as being unequal
   if default == '':
 $ ../ve3/bin/python -W default manage.py shell -c 'from bar.models import
 Baz; b = Baz()'
 $
 }}}

 This could be fixed by doing a type check on the returned value of the
 callable to see if it is of type `six.text_type` a la
 https://docs.djangoproject.com/en/1.11/topics/python3/#string-handling-
 with-six:
 {{{#!python
 class BinaryField(Field):
 ...
 def get_default(self):
 if self.has_default() and not callable(self.default):
 return self.default
 default = super(BinaryField, self).get_default()
 if isinstance(default, six.text_type) and default == '':
 return b''
 return default
 }}}

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


Re: [Django] #28763: Allow SessionStore's to be easily overridden to make dynamic the session cookie age

2017-11-06 Thread Django
#28763: Allow SessionStore's to be easily overridden to make dynamic the session
cookie age
-+-
 Reporter:  Jaime Herencia   |Owner:  (none)
  Enjuto |
 Type:  New feature  |   Status:  new
Component:  contrib.sessions |  Version:  master
 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
-+-

Comment (by Tomer Chachamu):

 I think it would be worth discussing in the django-developers mailing
 list.

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

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


Re: [Django] #28731: Passing an empty Q() to a When inside a Case causes an OperationError

2017-11-06 Thread Django
#28731: Passing an empty Q() to a When inside a Case causes an OperationError
-+-
 Reporter:  Tom van Bussel   |Owner:  Tim
 |  Martin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (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 Tomer Chachamu):

 Currently `Q() | Q(value=1)` outputs the same SQL as `Q(value=1)` which
 will not be the case if `Q()` is effectively always `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/068.ccf64665e4642ed6f63fcdd100b1d1be%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.