[Django] #28882: Cannot save disabled SplitDateTimeField

[Django]

#28882: Cannot save disabled SplitDateTimeField
-+
   Reporter:  avalanchy  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Forms  |Version:  1.11
   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  |
-+
 I found this on admin panel while trying to save an entry with datetime
 that was already set and the field was disabled. There is no way to save
 such entry at all because Django is always displaying an error "Enter list
 of values." above that field.

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

Re: [Django] #28876: badly formed Table Index and constraint's name when `Meta.db_table` is set with quoted string

[Django]

#28876: badly formed Table Index and constraint's name when  `Meta.db_table` is 
set
with quoted string
-+-
 Reporter:  Carlos E. C. Leite   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraints indexes  | Triage Stage:  Accepted
  db_table   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/9412 PR] for the issue with class-
 based model indexes.

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

Re: [Django] #28881: Common password validator does not handle case correctly

[Django]

#28881: Common password validator does not handle case correctly
---+--
 Reporter:  Nick Farrell   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.0
 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 Nick Farrell):

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

Re: [Django] #28881: Common password validator does not handle case correctly

[Django]

#28881: Common password validator does not handle case correctly
---+--
 Reporter:  Nick Farrell   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.11
 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
---+--
Description changed by Nick Farrell:

Old description:

> The CommonPasswordValidator holds a set of common passwords in memory,
> after strip()ing any whitespace.
> While validating a password, it converts it to lowercase before comparing
> to the set. However, the reference set was not converted to lowercase.
>
> This is not a problem when using the default set of common passwords, as
> they have been preprocessed to be lowercase. However, there is nothing in
> the documentation indicating this preprocessing should occur.
>
> https://github.com/django/django/pull/9414

New description:

 The CommonPasswordValidator holds a set of common passwords in memory,
 after strip()ing any whitespace.
 While validating a password, it converts it to lowercase before comparing
 to the set. However, the reference set was not converted to lowercase.

 This is not a problem when using the default set of common passwords, as
 they have been preprocessed to be lowercase. However, there is nothing in
 the documentation indicating this preprocessing should occur.

--

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

Re: [Django] #28881: Common password validator does not handle case correctly

[Django]

#28881: Common password validator does not handle case correctly
---+--
 Reporter:  Nick Farrell   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.11
 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
---+--
Description changed by Nick Farrell:

Old description:

> The CommonPasswordValidator holds a set of common passwords in memory,
> after strip()ing any whitespace.
> While validating a password, it converts it to lowercase before comparing
> to the set. However, the reference set was not converted to lowercase.
>
> This is not a problem when using the default set of common passwords, as
> they have been preprocessed to be lowercase. However, there is nothing in
> the documentation indicating this preprocessing should occur.

New description:

 The CommonPasswordValidator holds a set of common passwords in memory,
 after strip()ing any whitespace.
 While validating a password, it converts it to lowercase before comparing
 to the set. However, the reference set was not converted to lowercase.

 This is not a problem when using the default set of common passwords, as
 they have been preprocessed to be lowercase. However, there is nothing in
 the documentation indicating this preprocessing should occur.

 https://github.com/django/django/pull/9414

--

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

[Django] #28881: Common password validator does not handle case correctly

[Django]

#28881: Common password validator does not handle case correctly
-+
   Reporter:  Nick Farrell   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |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  |
-+
 The CommonPasswordValidator holds a set of common passwords in memory,
 after strip()ing any whitespace.
 While validating a password, it converts it to lowercase before comparing
 to the set. However, the reference set was not converted to lowercase.

 This is not a problem when using the default set of common passwords, as
 they have been preprocessed to be lowercase. However, there is nothing in
 the documentation indicating this preprocessing should occur.

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

Re: [Django] #28880: The QuerySet.query sql representation of an ORM call on a PostgreSQL ArrayField is missing a key bit of syntax.

[Django]

#28880: The QuerySet.query sql representation of an ORM call on a PostgreSQL
ArrayField is missing a key bit of syntax.
-+-
 Reporter:  Alexander Kavanaugh  |Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
  postgres,arrayfield,syntaxerror,.query,as_sql,ARRAY|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Alexander Kavanaugh):

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


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

Re: [Django] #28880: The QuerySet.query sql representation of an ORM call on a PostgreSQL ArrayField is missing a key bit of syntax.

[Django]

#28880: The QuerySet.query sql representation of an ORM call on a PostgreSQL
ArrayField is missing a key bit of syntax.
-+-
 Reporter:  Alexander Kavanaugh  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.postgres |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  postgres,arrayfield,syntaxerror,.query,as_sql,ARRAY|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Alexander Kavanaugh):

 > It's important to remember that calling str(queryset.query) has not yet
 passed the query to the DB-API driver for proper escaping and type
 coercion, so it's not always _exactly_ what's sent to the DBMS.

 Fair point. See related #17741

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

Re: [Django] #28878: "pip install django" is broken on Python 2; can be fixed for most users with metadata

[Django]

#28878: "pip install django" is broken on Python 2; can be fixed for most users
with metadata
+
 Reporter:  Zac Hatfield Dodds  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Packaging   |  Version:  2.0
 Severity:  Release blocker |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Zac Hatfield Dodds):

 * has_patch:  0 => 1


Comment:

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

 I've made the patch against master, and included some notes on backporting
 and required edits to the PyPI listing in the pull description.  Very
 happy to hear any feedback!

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

Re: [Django] #28874: Errors on hidden input fields print out double escaped HTML

[Django]

#28874: Errors on hidden input fields print out double escaped HTML
-+-
 Reporter:  Kyle Agronick|Owner:  Daniil
 |  Ryzhkov
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Simon Charette):

 * stage:  Ready for checkin => Accepted


Comment:

 Please don't mark your own patch as RFC.

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

Re: [Django] #28875: SQL: Creation of Index fails with '/' in app_label

[Django]

#28875: SQL: Creation of Index fails with '/' in app_label
-+-
 Reporter:  Jens L.  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 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 Simon Charette):

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


Comment:

 
[https://docs.djangoproject.com/en/2.0/ref/applications/#django.apps.AppConfig.label
 As documented], app labels should be a valid Python identifiers.

 I'm afraid that excludes slashes.

 {{{
 python3 -c "assert 'foo/bar'.isidentifier()"
 Traceback (most recent call last):
   File "", line 1, in 
 AssertionError
 }}}

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

Re: [Django] #28876: badly formed Table Index and constraint's name when `Meta.db_table` is set with quoted string

[Django]

#28876: badly formed Table Index and constraint's name when  `Meta.db_table` is 
set
with quoted string
-+-
 Reporter:  Carlos E. C. Leite   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraints indexes  | Triage Stage:  Accepted
  db_table   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Thank you for your report Carlos. Original
 [https://groups.google.com/d/msg/django-users/4bkKPn7oSUY/JtBn_qIhBAAJ
 @django-user thread].

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

Re: [Django] #28880: The QuerySet.query sql representation of an ORM call on a PostgreSQL ArrayField is missing a key bit of syntax.

[Django]

#28880: The QuerySet.query sql representation of an ORM call on a PostgreSQL
ArrayField is missing a key bit of syntax.
-+-
 Reporter:  Alexander Kavanaugh  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.postgres |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  postgres,arrayfield,syntaxerror,.query,as_sql,ARRAY|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Curtis Maloney):

 It's important to remember that calling str(queryset.query) has not yet
 passed the query to the DB-API driver for proper escaping and type
 coercion, so it's not always _exactly_ what's sent to the DBMS.

 Although ArrayField is postgres only currently, should some other DBMS
 support it, and Django add support for their syntax, forcing the repr to
 use Postgres's syntax would only result in someone raising a similar
 ticket.

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

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

[Django] #28880: The QuerySet.query sql representation of an ORM call on a PostgreSQL ArrayField is missing a key bit of syntax.

[Django]

#28880: The QuerySet.query sql representation of an ORM call on a PostgreSQL
ArrayField is missing a key bit of syntax.
-+-
   Reporter:  Alexander  |  Owner:  (none)
  Kavanaugh  |
   Type:  Bug| Status:  new
  Component: |Version:  1.11
  contrib.postgres   |   Keywords:
   Severity:  Normal |  
postgres,arrayfield,syntaxerror,.query,as_sql,ARRAY
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Representations of Arrays in PostgreSQL operations are preceeded by the
 word ARRAY (e.g. `ARRAY['3', '4', '5']`; see also
 [https://www.postgresql.org/docs/current/static/functions-array.html array
 operation docs]. The output of `QuerySet.query` is missing "ARRAY" -- it
 currently just injects a python list representation into the rhs of the
 operation sql string.

 It is worth noting that actual operations on ArrayFields use the correct
 syntax; only the `QuerySet.query` representation is incorrect. The key
 ramification of this issue is that copying and pasting the
 `QuerySet.query` output into a psql shell and running it results in a
 SyntaxError (`ERROR:  syntax error at or near "["`). This can be quite
 confusing for people unfamiliar with PostgreSQL array syntax (like me,
 before I dug into this) attempting to troubleshoot their code.

 I'll happily work on a fix and submit a PR if I can get some guidance. I'm
 assuming the fix would need to be somewhere along the
 
[https://github.com/django/django/blob/master/django/contrib/postgres/lookups.py#L7
 postgres Lookup as_sql] code path, but I'm not sure what an elegant
 solution would be. Is overriding `process_rhs` the right move?


 Relevant bit of the Django Model:
 {{{#!python
 class Message(Model):
 network_lookup_ids = ArrayField(base_field=CharField(max_length=160))
 }}}

 Django ORM Code:
 {{{#!python
 Message.objects.filter(network_lookup_ids__overlap=["3", "4",
 "5"]).values("id", "network_lookup_ids")
 }}}

 Django QuerySet.query representation:
 {{{#!sql
 SELECT "production_message"."id",
 "production_message"."network_lookup_ids" FROM "production_message" WHERE
 "production_message"."network_lookup_ids" && ['3', '4',
 '5']::varchar(160)[]
 }}}

 Actual call made to the database (from the `pg_stat_activity` table):
 {{{#!sql
 SELECT "production_message"."id",
 "production_message"."network_lookup_ids" FROM "production_message" WHERE
 "production_message"."network_lookup_ids" && ARRAY['3', '4',
 '5']::varchar(160)[] LIMIT 21
 }}}

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

Re: [Django] #28852: Search in admin can't use index when several fields are in `search_fields`

[Django]

#28852: Search in admin can't use index when several fields are in 
`search_fields`
-+-
 Reporter:  Jonathan Sundqvist   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  search   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jonathan Sundqvist):

 > What do you think of overriding ModelAdmin.get_queryset to use
 .annotate(sv=SearchVector(...)) and then specifying 'sv__search' in the
 ModelAdmin.search_fields? It looks like that won't work with the current
 implementation, as search_fields must be model fields and not queryset
 annotations.

 From what I can see that won't really work either even if you were to
 override the modeladmin queryset. Being able to set the config of the
 search vector and the search query is key to be able to use the index.

 You could require a `full_text_search` setting in the modeladmin to
 configure the search vector.

 {{{
 full_text_search = {
 'config': 'english',
 'fields': ['field_1', 'field_2'],
 }
 }}}

 But as far as I know just using `sv__search` in that case would omit any
 config for that particular search query. I'll check it out and see what
 results I get.

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

Re: [Django] #28876: badly formed Table Index and constraint's name when `Meta.db_table` is set with quoted string

[Django]

#28876: badly formed Table Index and constraint's name when  `Meta.db_table` is 
set
with quoted string
-+-
 Reporter:  Carlos E. C. Leite   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraints indexes  | Triage Stage:  Accepted
  db_table   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 This ticket describes two issues:
  - incorrect name of class-based model indexes for models with quoted
 `db_table`,
  - incorrect name of foreign-key constraint for models with quoted
 `db_table`.

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

Re: [Django] #28876: badly formed Table Index and constraint's name when `Meta.db_table` is set with quoted string

[Django]

#28876: badly formed Table Index and constraint's name when  `Meta.db_table` is 
set
with quoted string
-+-
 Reporter:  Carlos E. C. Leite   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraints indexes  | Triage Stage:  Accepted
  db_table   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  nobody => felixxm
 * status:  new => assigned
 * version:  1.11 => 2.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/068.e22ead21cad8c0b1f02f3dfe3a759438%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28874: Errors on hidden input fields print out double escaped HTML

[Django]

#28874: Errors on hidden input fields print out double escaped HTML
-+-
 Reporter:  Kyle Agronick|Owner:  Daniil
 |  Ryzhkov
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Daniil Ryzhkov):

 * stage:  Accepted => Ready for checkin


Comment:

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

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

[Django] #28879: Widget NumberInput becomes text if you change size

[Django]

#28879: Widget NumberInput becomes text if you change size
+
   Reporter:  Chris Davies-Barnard  |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Uncategorized |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 |
+
 I'm adjusting the width of some form fields because small integers such as
 qty and price don't need to be 20 long and the following code results in
 them becoming type = 'text' regardless.

 models.DecimalField: {'widget': TextInput(attrs={'size':'7'})},
 models.IntegerField: {'widget': NumberInput(attrs={'size':'3'})},

 breaking other aspects.  Sorry don't know if I need to add more detail
 etc...

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

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

Re: [Django] #28878: "pip install django" is broken on Python 2; can be fixed for most users with metadata

[Django]

#28878: "pip install django" is broken on Python 2; can be fixed for most users
with metadata
+
 Reporter:  Zac Hatfield Dodds  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Packaging   |  Version:  2.0
 Severity:  Release blocker |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Sergey Fedoseev):

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

Re: [Django] #28878: "pip install django" is broken on Python 2; can be fixed for most users with metadata

[Django]

#28878: "pip install django" is broken on Python 2; can be fixed for most users
with metadata
+--
 Reporter:  Zac Hatfield Dodds  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Packaging   |  Version:  2.0
 Severity:  Release blocker |   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 Sergey Fedoseev):

 * cc: Sergey Fedoseev (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/064.e664e6f9749f5427e750f2faab2fe3eb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28870: add support for serialization of `functools.partialmethod` objects in migrations

[Django]

#28870: add support for serialization of `functools.partialmethod` objects in
migrations
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  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 Sergey Fedoseev):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #28852: Search in admin can't use index when several fields are in `search_fields`

[Django]

#28852: Search in admin can't use index when several fields are in 
`search_fields`
-+-
 Reporter:  Jonathan Sundqvist   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  search   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tomer Chachamu):

 * cc: Tomer Chachamu (added)


Comment:

 I've also had to customise {{{ModelAdmin.get_search_results}}} because of
 its not-so-smartness (I will probably open a separate card for it).

 We've already moved away from the symbols for lookups, see
 
https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.search_fields
 and previous discussion https://code.djangoproject.com/ticket/26184.

 What do you think of overriding {{{ModelAdmin.get_queryset}}} to use
 {{{.annotate(sv=SearchVector(...))}}} and then specifying
 {{{'sv__search'}}} in the {{{ModelAdmin.search_fields}}}? It looks like
 that won't work with the current implementation, as {{{search_fields}}}
 must be model fields and not queryset annotations.

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

Re: [Django] #28858: Remove 'else' after 'return' or 'raise'

[Django]

#28858: Remove 'else' after 'return' or 'raise'
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  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 Дилян Палаузов):

 python has no switch..case, but "elif", which is not the same.  The
 readability criterion is very subjective one, e.g. the author might not
 have been aware that the 'else' was useless. As for
 {{{
 if x:
 return y
 else:
 raise z
 }}}
 the {{{else}}} does not add for readability.

 The first snippets of django/contrib/gis/gdal/srs.py or
 django/contrib/gis/geoip2/base.py I sent, have nothing to do with
 readability.

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

[Django] #28878: "pip install django" is broken on Python 2; can be fixed for most users with metadata

[Django]

#28878: "pip install django" is broken on Python 2; can be fixed for most users
with metadata
--+
   Reporter:  Zac Hatfield Dodds  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Packaging   |Version:  2.0
   Severity:  Release blocker |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 For users on Python 2, 'pip install django' ''should'' install the latest
 compatible version, which is 1.11.x.

 Unfortunately, it currently tries to install Django 2.0, and setup.py
 throws an error (the details are unimportant, except that it's a terrible
 user experience).  This is unfortunately inevitable for users with very
 old versions of pip, who are therefore out of luck unless they upgrade it.

 For any user with pip 9+ though, we can use the
 [https://packaging.python.org/tutorials/distributing-packages/#python-
 requires python-requires] argument to 'setuptools.setup'.  All users will
 then transparently get the latest version that is compatible with their
 Python, and all will be well.

 [http://www.python3statement.org/practicalities/] has a range of further
 advice on making this process as smooth as possible, including tips about
 setuptools versions and where to insert explicit warnings and errors for
 users who somehow get an incompatible version anyway.

 I'd be happy to review any patches in relation to this, or help write them
 if someone can help with django-specific questions :-)

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

Re: [Django] #28858: Remove 'else' after 'return' or 'raise'

[Django]

#28858: Remove 'else' after 'return' or 'raise'
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  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 you answered your own question there - it is used when it impacts
 readability (as judged by the original authors, who may not always agree
 with each other).

 An `if..elif..else..` block clearly lists mutually exclusive branches
 taken, and can be seen by looking at a single indentation level.
 `if..return; if.. return;..` requires checking two indentation levels to
 ensure there's a `return/raise` ending every `if`.

 For example, in the first hunk of the patch, the code is:

 {{{
 if bla:
some code
 if bla2:
raise
 elif bla3:
raise
 return val
 }}}

 After the change, it is:

 {{{
 if bla:
some code
 if bla2:
raise
 if bla3:
raise
 return val
 }}}

 A newline before `if bla2` would improve readability, however the `elif`
 is already helping to show there is some similarity between `if bla2` and
 `if bla3`, and that `if bla` has 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/072.4a3e69c069c6393cf76a3564c2b2cdbd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28858: Remove 'else' after 'return' or 'raise'

[Django]

#28858: Remove 'else' after 'return' or 'raise'
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  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 Дилян Палаузов):

 Skipping {{{else}}} after {{{return}}}, when it does not impact
 readability, leads to less code, and the resulting code is faster to read
 (by humans).

 Currently it is unclear, when useless {{{else}}} shall be written.

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

Re: [Django] #28574: Add a QuerySet.explain() method

[Django]

#28574: Add a QuerySet.explain() method
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Martin):

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

Re: [Django] #28581: Pagination topic docs need a little restructuring

[Django]

#28581: Pagination topic docs need a little restructuring
--+
 Reporter:  luto  |Owner:  luto
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Martin):

 * needs_better_patch:  0 => 1


Comment:

 Sorry for the confusion - I'm new to the Django ticketing system and I
 don't think I've seen anyone use the ticket field for linking to PRs.
 People usually put them in the comments.

 Anyway, the patch looks good to me. I flagged a couple of things for
 consideration on the pull request, but it's all subjective stuff so up to
 you if you want to leave it as it is.

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