Re: [Django] #30309: Remove hasattr reference in One-to-One documentation example

[Django]

#30309: Remove hasattr reference in One-to-One documentation example
---+--
 Reporter:  David Beitey   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  2.2
 Severity:  Normal |   Resolution:  invalid
 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 David Beitey):

 Replying to [comment:3 felixxm]:
 > `hasattr()` is not throwing an exceptions, just in case I checked with
 Python 3.6/3.7 and Django 2.1/2.2.
 >
 > Did you check this?
 >
 > FYI: `RelatedObjectDoesNotExist` is a subclass of `AttributeError`.

 Okay, I dug into the situation and what's happening isn't related to
 Python version.

 `RelatedObjectDoesNotExist` gets raised when the value of a OneToOneField
 is None/null.  However, if there is data in the field but it isn't present
 in the related table,  `[model_identifier].DoesNotExist` gets raised.  The
 latter exception doesn't inherit from `AttributeError` and isn't swallowed
 with `hasattr()`.

 Since the behaviour of `hasattr()` is to return False when there's no
 related object, that seems to be what should happen in both situations --
 with None as a value or a field value pointing at a non-existant related
 object.  In other words, it feels as though `RelatedObjectDoesNotExist`
 should be being raised when accessing the attribute on the model in this
 way, rather than at the query level (see traceback below).

 Here's my example:

 {{{
 from django.db import models

 class Person(models.Model):
 login = models.CharField(db_column='login', max_length=100)
 # and more...

class Meta:
 managed = False
 db_table = 'SYS_PEOPLE'

 class Author(models.Model):
 person = models.OneToOneField(Person,
   db_column='login',
   primary_key=True,
   on_delete=models.CASCADE)
 # and more...

 class Meta:
 managed = False
 db_table = 'SYS_AUTHORS'

 # manage.py shell
 from app.models import Author
 author = Author(person_id='fake')
 author.person # raises DoesNotExist
 hasattr(author, 'person')   # raises DoesNotExist

 author = Author(person_id=None)
 author.person  # raises RelatedObjectDoesNotExist
 hasattr(author, 'person')   # Swallows
 }}}

 Tracebacks:

 {{{
 Traceback (most recent call last):
   File "/home/user/local/share/virtualenvs/app-1933afW/lib/python3.7/site-
 packages/django/db/models/fields/related_descriptors.py", line 163, in
 __get__
 rel_obj = self.field.get_cached_value(instance)
   File "/home/user/local/share/virtualenvs/app-1933afW/lib/python3.7/site-
 packages/django/db/models/fields/mixins.py", line 13, in get_cached_value
 return instance._state.fields_cache[cache_name]
 KeyError: 'person'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "./manage.py", line 17, in 
 execute_from_command_line(sys.argv)
   File "/home/user/local/share/virtualenvs/app-1933afW/lib/python3.7/site-
 packages/django/core/management/__init__.py", line 381, in
 execute_from_command_line
 utility.execute()
   File "/home/user/local/share/virtualenvs/app-1933afW/lib/python3.7/site-
 packages/django/core/management/__init__.py", line 375, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/user/local/share/virtualenvs/app-1933afW/lib/python3.7/site-
 packages/django/core/management/base.py", line 316, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/user/local/share/virtualenvs/app-1933afW/lib/python3.7/site-
 packages/django/core/management/base.py", line 353, in execute
 output = self.handle(*args, **options)
   File "/home/user/local/share/virtualenvs/app-1933afW/lib/python3.7/site-
 packages/django/core/management/commands/shell.py", line 92, in handle
 exec(sys.stdin.read())
   File "", line 4, in 
   File "/home/user/local/share/virtualenvs/app-1933afW/lib/python3.7/site-
 packages/django/db/models/fields/related_descriptors.py", line 177, in
 __get__
 rel_obj = self.get_object(instance)
   File "/home/user/local/share/virtualenvs/app-1933afW/lib/python3.7/site-
 packages/django/db/models/fields/related_descriptors.py", line 297, in
 get_object
 return super().get_object(instance)
   File "/home/user/local/share/virtualenvs/app-1933afW/lib/python3.7/site-
 packages/django/db/models/fields/related_descriptors.py", line 144, in
 get_object
 return qs.get(self.field.get_reverse_related_filter(instance))
   F

[Django] #30317: model_to_dict() makes separate db calls for each missing field

[Django]

#30317: model_to_dict() makes separate db calls for each missing field
+
   Reporter:  Chris Hranj   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Forms |Version:  master
   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 |
+
 Currently, if a `model_to_dict` is called on a model instance that does
 not already contain all of its fields (as a result of a `.only()`, etc),
 it will make an individual database call for every single missing field
 when attempting to access it, unless the `fields` argument is passed and
 happens to contain only fields from the `.only()` used to query the object
 originally.

 The following example explains it more clearly (I'm using shell_plus
 (https://django-extensions.readthedocs.io/en/latest/shell_plus.html) to
 see the database interactions):


 {{{
 >>> from django.forms.models import model_to_dict
 >>> sample_book = Book(
 ... title='Some Book',
 ... author='Jane Doe',
 ... description='A good book.',
 ... publisher='ABC Publishing',
 ... some_field='some text',
 ... some_other_field='some more text',
 ... )
 >>> sample_book.save()
 INSERT INTO "books_book" ("title", "author", "description", "publisher",
 "some_field", "some_other_field")
 VALUES ('Some Book', 'Jane Doe', 'A good book.', 'ABC Publishing', 'some
 text', 'some more text')

 Execution time: 0.001141s [Database: default]

 >>> book = Book.objects.only('title').first()
 SELECT "books_book"."id",
"books_book"."title"
   FROM "books_book"
  ORDER BY "books_book"."id" ASC
  LIMIT 1

 Execution time: 0.000123s [Database: default]

 >>> model_to_dict(book)
 SELECT "books_book"."id",
"books_book"."author"
   FROM "books_book"
  WHERE "books_book"."id" = 3

 Execution time: 0.98s [Database: default]

 SELECT "books_book"."id",
"books_book"."description"
   FROM "books_book"
  WHERE "books_book"."id" = 3

 Execution time: 0.000149s [Database: default]

 SELECT "books_book"."id",
"books_book"."publisher"
   FROM "books_book"
  WHERE "books_book"."id" = 3

 Execution time: 0.67s [Database: default]

 SELECT "books_book"."id",
"books_book"."some_field"
   FROM "books_book"
  WHERE "books_book"."id" = 3

 Execution time: 0.64s [Database: default]

 SELECT "books_book"."id",
"books_book"."some_other_field"
   FROM "books_book"
  WHERE "books_book"."id" = 3

 Execution time: 0.62s [Database: default]
 }}}


 Ideally, this should make fewer (or just one) database calls if there are
 missing fields.

 Please let me know if this would be a welcome/worthwhile optimization. I
 would love to work on it, as I've never contributed to django before and I
 would really like to. Thank you!

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

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

Re: [Django] #30302: model_to_dict() should return an empty dict for an empty list of fields.

[Django]

#30302: model_to_dict() should return an empty dict for an empty list of fields.
--+
 Reporter:  Belegnar  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  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 Belegnar):

 * needs_tests:  1 => 0


Comment:

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

Re: [Django] #30316: Include default logging dictConfig in documentation

[Django]

#30316: Include default logging dictConfig in documentation
---+--
 Reporter:  Andrew Badr|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Andrew Badr):

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

[Django] #30316: Include default logging dictConfig in documentation

[Django]

#30316: Include default logging dictConfig in documentation
-+
   Reporter:  Andrew Badr|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.2
   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 people want to customize Django's logging, my guess is that they'll
 most often want to start by changing something about the default logging
 setup. Toward this end, it would be helpful if the Django dogs included a
 dictConfig for the default logging setup. Instead, the docs *describe* the
 default settings (https://docs.djangoproject.com/en/2.1/topics/logging
 /#default-logging-configuration), and give dictConfigs for several other
 possible configurations for logging
 (https://docs.djangoproject.com/en/2.1/topics/logging/#configuring-
 logging).

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

Re: [Django] #30315: StringAgg with ordering in subquery generates invalid string_agg() SQL function call

[Django]

#30315: StringAgg with ordering in subquery generates invalid string_agg() SQL
function call
--+--
 Reporter:  Reupen Shah   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  2.2
 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 Reupen Shah):

 * component:  Uncategorized => contrib.postgres


Old description:

> Consider the following models (in the `people` app):
>

> {{{
> from django.db import models
>

> class Person(models.Model):
> """Person model."""
>
> first_name = models.TextField()
> last_name = models.TextField()
> country = models.TextField(null=True, blank=True)
>

> class Book(models.Model):
> """Book model."""
>
> people = models.ManyToManyField(Person)
> }}}
>

> The following query fails:
>
> {{{
> from django.contrib.postgres.aggregates import StringAgg
> from django.db.models import Subquery, OuterRef
>
> from people.models import Person, Book
>
> subquery = Book.objects.annotate(
> _annotated_value=StringAgg('people__first_name', ', ',
> ordering=('people__first_name')),
> ).filter(
> pk=OuterRef('pk'),
> ).values(
> '_annotated_value',
> )
> Book.objects.annotate(_names=Subquery(subquery))
>
> }}}
>
> with the following error:
>
> {{{
> ProgrammingError: function string_agg(text, text, unknown) does not exist
> }}}
>
> The SQL it executes is as follows:
>
> {{{
> SELECT "people_book"."id",
>(SELECT STRING_AGG(U2."first_name", U2."first_name", ', '
>   ORDER BY "people_person"."first_name") AS
> "_annotated_value"
> FROM "people_book" U0
>LEFT OUTER JOIN "people_book_people" U1 ON (U0."id" =
>U1."book_id")
>LEFT OUTER JOIN "people_person" U2 ON (U1."person_id" =
> U2."id")
> WHERE U0."id" = ("people_book"."id")
> GROUP BY U0."id") AS "_names"
> FROM "people_book"
> }}}
>
> There are two problems in `STRING_AGG(U2."first_name", U2."first_name",
> ', 'ORDER BY "people_person"."first_name")`:
>
> 1. the ordering value is also added to the `string_agg()` call as a
> positional argument for some unknown reason
> 2. the ORDER BY expression is referencing `"people_person"` instead of
> `U2`.
>

>

> For comparison, the following query executes correctly:
>
> {{{
> Book.objects.annotate(
> _names=StringAgg('people__first_name', ', ',
> ordering=('people__first_name')),
> )
> }}}
>
> SQL for that query:
>
> {{{
> SELECT "people_book"."id",
>STRING_AGG("people_person"."first_name", ', ' ORDER BY
> "people_person"."first_name") AS "_names"
> FROM "people_book"
>LEFT OUTER JOIN "people_book_people" ON ("people_book"."id" =
> "people_book_people"."book_id")
>LEFT OUTER JOIN "people_person" ON
> ("people_book_people"."person_id" = "people_person"."id")
> GROUP BY "people_book"."id"
> }}}
>
> This query also executes correctly:
>

> {{{
> subquery = Book.objects.annotate(
> _annotated_value=StringAgg('people__first_name', ', '),
> ).filter(
> pk=OuterRef('pk'),
> ).values(
> '_annotated_value',
> )
> Book.objects.annotate(_names=Subquery(subquery))
> }}}
>
> SQL:
>
> {{{
> SELECT "people_book"."id",
>(SELECT STRING_AGG(U2."first_name", ', ') AS "_annotated_value"
> FROM "people_book" U0
>LEFT OUTER JOIN "people_book_people" U1 ON (U0."id" =
> U1."book_id")
>LEFT OUTER JOIN "people_person" U2 ON (
>   U1."person_id" = U2."id")
> WHERE U0."id" = ("people_book"."id")
> GROUP BY U0."id") AS "_names"
> FROM "people_book"
> }}}

New description:

 Consider the following models (in the `people` app):


 {{{
 from django.db import models


 class Person(models.Model):
 """Person model."""

 first_name = models.TextField()
 last_name = models.TextField()
 country = models.TextField(null=True, blank=True)


 class Book(models.Model):
 """Book model."""

 people = models.ManyToManyField(Person)
 }}}


 The following query fails:

 {{{
 from django.contrib.postgres.aggregates import StringAgg
 from django.db.models import Subquery, OuterRef

 from people.models import Person, Book

 subquery = Book.objects.annotate(
 _annotated_value=StringAgg('people__first_name', ', ',
 ordering=('people__first_name')),
 ).filter(
 pk=OuterRef('pk'),
 ).values(
 '_annotated_value',
 )
 Book.objects.annotate(_names=Subquery(subquery))

 }}}

 with the f

Re: [Django] #30315: StringAgg with ordering in subquery generates invalid string_agg() SQL function call (was: StringAgg with ordering in subquery executes invalid string_agg() SQL function call)

[Django]

#30315: StringAgg with ordering in subquery generates invalid string_agg() SQL
function call
---+--
 Reporter:  Reupen Shah|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  2.2
 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
---+--

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

[Django] #30315: StringAgg with ordering in subquery executes invalid string_agg() SQL function call

[Django]

#30315: StringAgg with ordering in subquery executes invalid string_agg() SQL
function call
-+
   Reporter:  Reupen Shah|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  2.2
   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  |
-+
 Consider the following models (in the `people` app):


 {{{
 from django.db import models


 class Person(models.Model):
 """Person model."""

 first_name = models.TextField()
 last_name = models.TextField()
 country = models.TextField(null=True, blank=True)


 class Book(models.Model):
 """Book model."""

 people = models.ManyToManyField(Person)
 }}}


 The following query fails:

 {{{
 from django.contrib.postgres.aggregates import StringAgg
 from django.db.models import Subquery, OuterRef

 from people.models import Person, Book

 subquery = Book.objects.annotate(
 _annotated_value=StringAgg('people__first_name', ', ',
 ordering=('people__first_name')),
 ).filter(
 pk=OuterRef('pk'),
 ).values(
 '_annotated_value',
 )
 Book.objects.annotate(_names=Subquery(subquery))

 }}}

 with the following error:

 {{{
 ProgrammingError: function string_agg(text, text, unknown) does not exist
 }}}

 The SQL it executes is as follows:

 {{{
 SELECT "people_book"."id",
(SELECT STRING_AGG(U2."first_name", U2."first_name", ', '
   ORDER BY "people_person"."first_name") AS
 "_annotated_value"
 FROM "people_book" U0
LEFT OUTER JOIN "people_book_people" U1 ON (U0."id" =
U1."book_id")
LEFT OUTER JOIN "people_person" U2 ON (U1."person_id" =
 U2."id")
 WHERE U0."id" = ("people_book"."id")
 GROUP BY U0."id") AS "_names"
 FROM "people_book"
 }}}

 There are two problems in `STRING_AGG(U2."first_name", U2."first_name", ',
 'ORDER BY "people_person"."first_name")`:

 1. the ordering value is also added to the `string_agg()` call as a
 positional argument for some unknown reason
 2. the ORDER BY expression is referencing `"people_person"` instead of
 `U2`.




 For comparison, the following query executes correctly:

 {{{
 Book.objects.annotate(
 _names=StringAgg('people__first_name', ', ',
 ordering=('people__first_name')),
 )
 }}}

 SQL for that query:

 {{{
 SELECT "people_book"."id",
STRING_AGG("people_person"."first_name", ', ' ORDER BY
 "people_person"."first_name") AS "_names"
 FROM "people_book"
LEFT OUTER JOIN "people_book_people" ON ("people_book"."id" =
 "people_book_people"."book_id")
LEFT OUTER JOIN "people_person" ON
 ("people_book_people"."person_id" = "people_person"."id")
 GROUP BY "people_book"."id"
 }}}

 This query also executes correctly:


 {{{
 subquery = Book.objects.annotate(
 _annotated_value=StringAgg('people__first_name', ', '),
 ).filter(
 pk=OuterRef('pk'),
 ).values(
 '_annotated_value',
 )
 Book.objects.annotate(_names=Subquery(subquery))
 }}}

 SQL:

 {{{
 SELECT "people_book"."id",
(SELECT STRING_AGG(U2."first_name", ', ') AS "_annotated_value"
 FROM "people_book" U0
LEFT OUTER JOIN "people_book_people" U1 ON (U0."id" =
 U1."book_id")
LEFT OUTER JOIN "people_person" U2 ON (
   U1."person_id" = U2."id")
 WHERE U0."id" = ("people_book"."id")
 GROUP BY U0."id") AS "_names"
 FROM "people_book"
 }}}

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

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

Re: [Django] #28296: Add support for aggregation through subqueries

[Django]

#28296: Add support for aggregation through subqueries
-+-
 Reporter:  László Károlyi   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I looks like someone went ahead [https://github.com/martsberger/django-
 sql-utils and implemented] the `AggregateSubquery` API.

 I'd like to throw another one into the mix which I believe would be more
 suitable than the `AggregateSubquery` and `subquery` kwarg idea; an
 `as_subquery()` method that returns a `Subquery` instance. It would offer
 a nicer interface through composition and allow encapsulation of most of
 the subquery creation logic instead of doing it at `Aggregate` expression
 resolving and compiling time. The `as_*` pattern is also coherent with the
 `Queryset.as_manager` interface so it shouldn't be completely alien to
 most of our users.

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

[Django] #30314: Enable SESSION_COOKIE_SECURE by Default

[Django]

#30314: Enable SESSION_COOKIE_SECURE by Default
-+
   Reporter:  nstr10 |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.1
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 Per the documentation, "Leaving this setting off isn’t a good idea because
 an attacker could capture an unencrypted session cookie with a packet
 sniffer and use the cookie to hijack the user’s session."

 If it's not a good idea for this setting to be off, why is it off by
 default? Seems backwards to me.

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

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

[Django] #30313: SQLite min version in Django 2.2 breaks Centos 7 compatability

[Django]

#30313: SQLite min version in Django 2.2 breaks Centos 7 compatability
-+-
   Reporter:  Jamie  |  Owner:  nobody
  Cockburn   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  SQLite Centos
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The latest Django 2.2 release requires SQLite 3.8.3.

 Centos 7 repos bundle SQLite 3.7.17, so this change breaks compatibility
 with one of the major linux distros.

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

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

Re: [Django] #30306: Textarea widget missing input_type

[Django]

#30306: Textarea widget missing input_type
-+-
 Reporter:  minusf   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by minusf):

 I understand that the "abstraction" is leaking. But `Select` and
 `RadioSelect` both have `input_type`, even if for a "different purpose",
 those can be used in the same way as `input_type` for "true" `Input`
 widgets...  It's not ideal, but it's already there and only `Textarea` is
 left out in the cold. The other alternative could be to add `widget_type`
 or such to every `Widget` subclass but at this point it would just
 duplicate `input_type`.

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

Re: [Django] #30237: admin check for AuthenticationMiddleware should allow subclasses

[Django]

#30237: admin check for AuthenticationMiddleware should allow subclasses
-+-
 Reporter:  Alek Ratzloff|Owner:  Herman S
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tameron NGUYEN):

 Replying to [comment:1 Tim Graham]:
 > The check is new in Django 2.2
 (371ece2f0682e51f2f796854d3e091827a7cea63). It might be possible to modify
 it so that it detects `AuthenticationMiddleware` subclasses. You could
 also simply add that error to your `SILENCED_SYSTEM_CHECKS` setting.

 Errors: ?: (admin.E408)
 'django.contrib.auth.middleware.AuthenticationMiddleware' must be in
 MIDDLEWARE in order to use the admin application.
 In settings.py, add

 {{{
 SILENCED_SYSTEM_CHECKS = [
 'admin.E408',
 ]
 }}}

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

Re: [Django] #30312: Admin app has too hard a dependency on sessions app

[Django]

#30312: Admin app has too hard a dependency on sessions app
--+
 Reporter:  Aarni Koskela |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  2.2
 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 Carlton Gibson):

 * type:  Bug => Cleanup/optimization
 * 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/061.6c48ccc6f47409a751e2a2df831d80d2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30306: Textarea widget missing input_type

[Django]

#30306: Textarea widget missing input_type
-+-
 Reporter:  minusf   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 For `Input` subclasses, `input_type` corresponds to ``.
 `ChoiceWidget` uses `input_type` for a different purpose.

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

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

Re: [Django] #30312: Admin app has too hard a dependency on sessions app

[Django]

#30312: Admin app has too hard a dependency on sessions app
---+--
 Reporter:  Aarni Koskela  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.2
 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 Carlton Gibson):

 System checks are [https://docs.djangoproject.com/en/2.2/ref/settings#std
 :setting-SILENCED_SYSTEM_CHECKS designed to be silenced if not
 appropriate]. I'm inclined to think this just such an edge-case at first
 glance.

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

Re: [Django] #30311: Can't replace global admin actions with specialized ones per-admin

[Django]

#30311: Can't replace global admin actions with specialized ones per-admin
---+--
 Reporter:  Aarni Koskela  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

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


Comment:

 This is [https://docs.djangoproject.com/en/2.2/releases/2.2/#admin-
 actions-are-no-longer-collected-from-base-modeladmin-classes documented as
 a backwards incompatible change in the 2.2 release notes].

 See the discussion on #29917 and [https://groups.google.com/d/topic
 /django-developers/-OWoYL_zryM/discussion the mailing list thread].

 See [https://docs.djangoproject.com/en/2.2/ref/contrib/admin/actions
 #adminsite-actions Making actions available site-wide] docs for the
 suggested approach.

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

[Django] #30312: Admin app has too hard a dependency on sessions app

[Django]

#30312: Admin app has too hard a dependency on sessions app
-+
   Reporter:  Aarni Koskela  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  2.2
   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  |
-+
 Since #29695 (371ece2f0682e51f2f796854d3e091827a7cea63), released in 2.2,
 the admin app checks whether the `django.contrib.sessions` app is in
 `INSTALLED_APPS`.

 Some projects may have opted to use a replacement session management app
 such as https://github.com/QueraTeam/django-qsessions – the admin app
 claims to be incompatible with such a configuration, even if it actually
 means "I'm going to need _some_ session management that works like
 `django.contrib.sessions`".

 Maybe it would be better to get rid of the app check and do what's being
 done for various middleware in the checks function anyway, e.g. something
 like

 {{{
 if not
 _contains_subclass('django.contrib.sessions.middleware.SessionMiddleware',
 settings.MIDDLEWARE):
 errors.append(checks.Error(
 "'django.contrib.sessions.middleware.SessionMiddleware' must "
 "be in MIDDLEWARE in order to use the admin application.",
 id='admin.E4XX',
 ))
 }}}

 – this would be out-of-the-box compatible with e.g. Qsessions.

 The obvious workaround is to just re-add `django.contrib.sessions` back
 into `INSTALLED_APPS` which kinda works, but has the mild but unfortunate
 side effect of forcibly enabling the
 `django.contrib.sessions.models.Session` model and migrations, (re-)adding
 a useless `django_session` table into the database upon migration.

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

[Django] #30311: Can't replace global admin actions with specialized ones per-admin

[Django]

#30311: Can't replace global admin actions with specialized ones per-admin
-+
   Reporter:  Aarni Koskela  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  2.2
   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  |
-+
 f9ff1df1daac8ae1fc22b27f48735148cb5488dd landed in 2.2 (discussion in
 #29917), which makes it impossible to replace a generic site-wide action
 (such as the built-in `delete_selected`) with a new one. It fails with the
 admin.E130 system check error.

 We're seeing this with the qsessions app, which has to delete its session
 objects in non-bulk mode in order to clear caches:
 https://github.com/QueraTeam/django-
 
qsessions/blob/c21d602a50c4746da7f698a8d39317ef214e7d05/qsessions/admin.py#L41-L46
 (For this particular use case, it seems a fix is to instead override
 `modeladmin.delete_queryset` within `qsessions`'s `SessionAdmin`, as
 that's what the built-in `delete_selected` action does per
 
https://github.com/django/django/blob/851d9eac23e08ff10a2d6fe5368b02798761663c/django/contrib/admin/actions.py#L40
 .)

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

Re: [Django] #30309: Remove hasattr reference in One-to-One documentation example

[Django]

#30309: Remove hasattr reference in One-to-One documentation example
---+--
 Reporter:  David Beitey   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  2.2
 Severity:  Normal |   Resolution:  invalid
 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 felixxm):

 `hasattr()` is not throwing an exceptions, just in case I checked with
 Python 3.6/3.7 and Django 2.1/2.2.

 Did you check this?

 FYI: `RelatedObjectDoesNotExist` is a subclass of `AttributeError`.

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

Re: [Django] #30309: Remove hasattr reference in One-to-One documentation example

[Django]

#30309: Remove hasattr reference in One-to-One documentation example
---+--
 Reporter:  David Beitey   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  2.2
 Severity:  Normal |   Resolution:  invalid
 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 David Beitey):

 In my experience today, using `hasattr(p2, 'restaurant')` is throwing a
 `ObjectDoesNotExist` exception with Django 2.1.7 / Python 3.7 and the
 exception is not being swallowed.  This was the reason for me making the
 contribution.   For note, I'm not the only one to making this observation:
 https://stackoverflow.com/a/22240021/1048705 -- the last paragraph of that
 answer.

 If it's Django-specific behaviour to add `hasattr` functionality to
 swallow errors, then perhaps a bug report is necessary instead of a
 documentation fix.   If Django is doing this, I'd suggest changing the
 behaviour so Django follows Python itself; why Python made the change
 explained on the mailing list: https://mail.python.org/pipermail/python-
 dev/2010-August/103178.html

 Are we able to re-open this?  Happy to do further diagnosis if you can't
 replicate the exception being raised.

 Fwiw, I understand the use case for avoiding exception handling with a
 `OneToOneField` - I'd love a clean solution for this myself.

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

[Django] #30310: New HTTPRequest.headers not usable in templates because of hyphens

[Django]

#30310: New HTTPRequest.headers not usable in templates because of hyphens
-+-
   Reporter:  Mark   |  Owner:  nobody
  Tranchant  |
   Type:  Bug| Status:  new
  Component:  Template   |Version:  2.2
  system |   Keywords:  request headers
   Severity:  Normal |  hyphen template
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 With the release of 2.2, I took the opportunity from the new
 [https://docs.djangoproject.com/en/2.2/ref/request-
 response/#django.http.HttpRequest.headers HTTPRequest.headers object] to
 clean up old code using e.g. `request.META['HTTP_X_REAL_IP']` to
 `request.headers['X-Real-IP']`.

 However, this new approach does not work with templates, as
 [https://docs.djangoproject.com/en/2.2/ref/templates/api/#variables-and-
 lookups variable lookups cannot use hyphens].

 Could the object contain a parallel set of keys in underscored variables?
 e.g. `request.headers['foo-bar']` is also available in
 `request.headers['foo_bar']` and can be looked up with `{{
 request.headers.foo_bar }}` in a template?

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

Re: [Django] #30252: ImageField's to_python() stores reference to closed Image object

[Django]

#30252: ImageField's to_python() stores reference to closed Image object
+--
 Reporter:  Felix Dreissig  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  2.1
 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 Carlton Gibson):

 Hi Felix.

 I'm inclined to see both this and #13750 as documentation issues... Let's
 just be clearer about the behaviour.

 Just for your proposal: if we reopen the file, where are we closing it
 again?

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

Re: [Django] #30308: Clarify in documentation that runserver is overridden for django.contrib.staticfiles

[Django]

#30308: Clarify in documentation that runserver is overridden for
django.contrib.staticfiles
---+--
 Reporter:  davidjb|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  2.2
 Severity:  Normal |   Resolution:  wontfix
 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 Carlton Gibson):

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


Comment:

 Closing
 [https://github.com/django/django/pull/11121#pullrequestreview-221568931
 as per comment on PR]. (Roughly: too much of an edge-case to be worth the
 complication, and advising the use of `collectstatic` in development not
 the best way to go.)

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

Re: [Django] #30309: Remove hasattr reference in One-to-One documentation example

[Django]

#30309: Remove hasattr reference in One-to-One documentation example
---+--
 Reporter:  davidjb|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  2.2
 Severity:  Normal |   Resolution:  invalid
 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 felixxm):

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


Comment:

 IMO this doc is still valid and it is not related with pre-Python 3.2
 behavior. It's quite straightforward, so if you want to check that `p2`
 doesn’t have an associated restaurant you can catch `ObjectDoesNotExist`
 exception or you can use `hasattr(p2, 'restaurant')` (if you don't want to
 catch exceptions).

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

Re: [Django] #30307: dbshell doesn't pass password properly on Oracle 18c.

[Django]

#30307: dbshell doesn't pass password properly on Oracle 18c.
-+-
 Reporter:  Mark Gordon  |Owner:  msg555@…
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle dbshell   | Triage Stage:  Accepted
  runshell   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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

Re: [Django] #30307: dbshell doesn't pass password properly on Oracle 18c.

[Django]

#30307: dbshell doesn't pass password properly on Oracle 18c.
-+-
 Reporter:  Mark Gordon  |Owner:  msg555@…
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle dbshell   | Triage Stage:  Accepted
  runshell   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 I'm really sure that previous solution worked properly with `sqlplus` for
 Oracle 11.2 and 12.1, it has been also confirmed also by Shane Allgeier
 who reported #29199.

 There is a test to check new format in the (`test_password_with_at_sign`),
 we resigned from creating dynamically a custom Oracle user etc. to check
 this.

 I double-checked and can confirmed that format without backslashes works
 for Oracle 12.2 and 18c so changes in `django/db/backends/oracle/base.py`
 looks good.

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

Re: [Django] #30306: Textarea widget missing input_type

[Django]

#30306: Textarea widget missing input_type
-+-
 Reporter:  minusf   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by minusf):

 Closed already?  I think this is a fair bit of inconsistency and I would
 welcome at least some discussion.

 This is not just about not triggering an exception.  This is about having
 a useful way to identify widget types.
 So textareas are the widgets that have no `input_type`?  This makes
 programmatic widget customisation painful.

 As for the value, what's wrong with `'textarea'` ?  Select has `select`,
 checkbox has `checkbox`, etc.  Even `hidden` has one.
 Why should `textarea` be different?

 {{{
 class Input(Widget):
 """
 Base class for all  widgets.
 """
 input_type = None  # Subclasses must define this.
 <= my emphasis
 template_name = 'django/forms/widgets/input.html'

 }}}

 While this comment is in `Input` and not `Widget` (and `Textarea` inherits
 from `Widget`) the intention and philosophy seems clear to me.

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

Re: [Django] #30300: Allow migrations directories without __init__.py files

[Django]

#30300: Allow migrations directories without __init__.py files
-+-
 Reporter:  Benjy Weinberger |Owner:  Benjy
 |  Weinberger
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (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 Václav Řehák):

 We had a similar issue with test discovery. One of our developers read an
 article that `__init__.py` files are not required on Python3 and started
 removing them. Everything seemingly worked but some tests were not
 discovered and did not run in CI (which made it difficult to spot).

 I think Django should not required them if technically possible or at
 least it should be made clear in the documentation (sorry if I overlooked
 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/064.fe614d28b752ab12369cdcc37070c620%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30309: Remove hasattr reference in One-to-One documentation example

[Django]

#30309: Remove hasattr reference in One-to-One documentation example
-+
   Reporter:  davidjb|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  2.2
   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  |
-+
 The One-to-One example of using `hasattr` to avoid exception handling is
 based on the side effect of `hasattr` swallowing all exceptions.  This was
 pre-Python 3.2 behaviour and has been changed to only suppress
 AttributeErrors as explained at https://bugs.python.org/issue9666.

 PR: https://github.com/django/django/pull/11159

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

Re: [Django] #30307: dbshell doesn't pass password properly on Oracle 18c.

[Django]

#30307: dbshell doesn't pass password properly on Oracle 18c.
-+-
 Reporter:  Mark Gordon  |Owner:  msg555@…
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle dbshell   | Triage Stage:  Accepted
  runshell   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mark Gordon):

 * has_patch:  0 => 1


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

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

[Django] #30308: Clarify in documentation that runserver is overridden for django.contrib.staticfiles

[Django]

#30308: Clarify in documentation that runserver is overridden for
django.contrib.staticfiles
-+
   Reporter:  davidjb|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  2.2
   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  |
-+
 In the main [https://docs.djangoproject.com/en/dev/howto/static-files
 /#serving-static-files-during-development static files] documentation, the
 serving process is generally explained that `runserver` will automatically
 serve files if DEBUG is set to true.  This isn't quite the full story
 because it's not the _original_ `runserver` that is being used, and rather
 it's the one from `django.contrib.staticfiles`.  This  gets explained if
 you
 [https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#runserver
 dig deeper], but it isn't clear what's happening before getting this deep.

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

 This PR makes a clarification to the wording of this section in the docs
 to explain ''how'' `runserver` is working its magic, and that if you have
 a custom `runserver` command (like I did), you need a special strategy.

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

Re: [Django] #30307: dbshell doesn't pass password properly on Oracle 18c.

[Django]

#30307: dbshell doesn't pass password properly on Oracle 18c.
-+-
 Reporter:  Mark Gordon  |Owner:  msg555@…
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle dbshell   | Triage Stage:  Accepted
  runshell   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mark Gordon):

 Are you finding documentation about this anywhere?

 Apologies if you were just being brief, but let's make sure we're talking
 about the same thing. If

 sqlplus -L username/\"p@ssword\"@localhost:1521/some_database

 is what you entered on the command line then yes it will work because the
 normal shell escaping mechanisms will convert the \" sequence to just a
 double quote when passed to the underlying sqlplus command. However, there
 is no such unescaping shell layer when you use the array form of
 subprocess.run, the arguments are passed literally meaning that there's
 going to be random backslashes in the password portion of the connect
 string.

 e.g. if you ran


 sqlplus -L 'username/\"p@ssword\"@localhost:1521/some_database'

 which is the equivalant of what dbshell is doing then it should fail.

 Additionally, there are no tests of this function in the codebase as far
 as I can tell. The PR that introduced this change did not add tests for
 the dbshell related functionality.

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

Re: [Django] #30304: Support setting Secure, HttpOnly, SameSite on the language cookie

[Django]

#30304: Support setting Secure, HttpOnly, SameSite on the language cookie
-+-
 Reporter:  Ran Benita   |Owner:  Ran
 |  Benita
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  language cookie  | 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 felixxm):

 * stage:  Accepted => Ready for checkin


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

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