Re: [Django] #25385: Allow importing django.views.generic.View from django.views.View

[Django]

#25385: Allow importing django.views.generic.View from django.views.View
--+
 Reporter:  jambonrose|Owner:  auvipy
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Generic views |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by varun):

 Replying to [comment:19 auvipy]:
 Hi !!
 I saw your PR and there wasn't any activity or follow up in that from last
 18 days. I guess that's a reasonable period to reassign the ticket. There
 wasn't much of work in this anyway :)

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

Re: [Django] #25995: Add more sophisticated serialization support to JSONField

[Django]

#25995: Add more sophisticated serialization support to JSONField
--+
 Reporter:  jimgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  JSONB | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"3503b816cf449c7c94766c8f3f890a52083db392" 3503b81]:
 {{{
 #!CommitTicketReference repository=""
 revision="3503b816cf449c7c94766c8f3f890a52083db392"
 [1.9.x] Refs #25995 -- Documented that JSONField doesn't handle
 sophisticated serialization.

 Backport of c432dd40bde37667bfe6bb59eaff0a14c50cd27b from master
 }}}

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

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

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

[Django]

#25165: Move JavaScript calls out of HTML to fix JavaScript "no-script-eval"
warnings
-+-
 Reporter:  timgraham|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 And to fix serialization for the delete popup:
 [https://github.com/django/django/pull/5955 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/067.a3a355ec0f28ab81841b77869baef293%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25995: Add more sophisticated serialization support to JSONField

[Django]

#25995: Add more sophisticated serialization support to JSONField
--+
 Reporter:  jimgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  JSONB | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"c432dd40bde37667bfe6bb59eaff0a14c50cd27b" c432dd40]:
 {{{
 #!CommitTicketReference repository=""
 revision="c432dd40bde37667bfe6bb59eaff0a14c50cd27b"
 Refs #25995 -- Documented that JSONField doesn't handle sophisticated
 serialization.
 }}}

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

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

Re: [Django] #25997: Editing ForeignKey in admin popup causes incorrect escaping for uuid field

[Django]

#25997: Editing ForeignKey in admin popup causes incorrect escaping for uuid 
field
-+
 Reporter:  zachborboa   |Owner:  sasha0
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham ):

 In [changeset:"cb96d0c92a04cd6287cea5b904709edd1dbe6010" cb96d0c]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb96d0c92a04cd6287cea5b904709edd1dbe6010"
 [1.9.x] Added a test for adding a UUID pk object using the "Add related"
 admin popup.

 Follow up to refs #25997 but this case wasn't broken.

 Backport of 5052f79df45d843d1e44dcc47152ed503220098f from master
 }}}

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

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

Re: [Django] #25997: Editing ForeignKey in admin popup causes incorrect escaping for uuid field

[Django]

#25997: Editing ForeignKey in admin popup causes incorrect escaping for uuid 
field
-+
 Reporter:  zachborboa   |Owner:  sasha0
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham ):

 In [changeset:"5052f79df45d843d1e44dcc47152ed503220098f" 5052f79]:
 {{{
 #!CommitTicketReference repository=""
 revision="5052f79df45d843d1e44dcc47152ed503220098f"
 Added a test for adding a UUID pk object using the "Add related" admin
 popup.

 Follow up to refs #25997 but this case wasn't broken.
 }}}

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

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

Re: [Django] #26062: Adding Http 451 to Django

[Django]

#26062: Adding Http 451 to Django
---+--
 Reporter:  adminq80   |Owner:  adminq80
 Type:  New feature|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 Thanks for the suggestion, but we decided not to add subclasses for every
 HTTP code (see #6349) for an example.

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

Re: [Django] #26062: Adding Http 451 to Django

[Django]

#26062: Adding Http 451 to Django
---+--
 Reporter:  adminq80   |Owner:  adminq80
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by adminq80):

 PR #5954 is to fix this 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/066.090c340a52d8a66f6067129925f13134%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26062: Adding Http 451 to Django

[Django]

#26062: Adding Http 451 to Django
---+--
 Reporter:  adminq80   |Owner:  adminq80
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by adminq80):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * owner:  nobody => adminq80
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #26062: Adding Http 451 to Django

[Django]

#26062: Adding Http 451 to Django
---+
 Reporter:  adminq80   |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  HTTP handling  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+
 After looking at this [https://tools.ietf.org/html/draft-tbray-http-
 legally-restricted-status-00 RFC], I think we should add it to Django.

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

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

Re: [Django] #26049: Request _upload_handlers is immutable?

[Django]

#26049: Request _upload_handlers is immutable?
-+-
 Reporter:  awhillas |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  File |  Version:  1.8
  uploads/storage|   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


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

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

[Django]

#25165: Move JavaScript calls out of HTML to fix JavaScript "no-script-eval"
warnings
-+-
 Reporter:  timgraham|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"cbaa3ee3ee45d453ab6aa36d57847515dd130b9f" cbaa3ee]:
 {{{
 #!CommitTicketReference repository=""
 revision="cbaa3ee3ee45d453ab6aa36d57847515dd130b9f"
 Refs #25165 -- Removed unnecessary HTML unescaping in admin add/edit
 popups.

 Because we now load data into the page via JSON, we don't need to
 unescape it anymore.
 }}}

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

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

Re: [Django] #26053: makemigrations generates a wrong type for a DurationField column on postgresql

[Django]

#26053: makemigrations generates a wrong type for a DurationField column on
postgresql
-+-
 Reporter:  benjellounayoub  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  makemigrations,  | Triage Stage:
  DurationField, postgresql, |  Unreviewed
  psycopg2   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

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

Re: [Django] #26061: Queryset raises EmptyResultSet (instead of print SQL query)

[Django]

#26061: Queryset raises EmptyResultSet  (instead of print SQL query)
-+-
 Reporter:  ad-m |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  EmptyResultSet   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Duplicate of #22973

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

Re: [Django] #20846: Increase contrib.auth's User.username length

[Django]

#20846: Increase contrib.auth's User.username length
-+
 Reporter:  ivoras@… |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"780bddf75b93784470a2e352ed44ee35a751d667" 780bddf7]:
 {{{
 #!CommitTicketReference repository=""
 revision="780bddf75b93784470a2e352ed44ee35a751d667"
 Fixed #20846 -- Decreased User.username max_length to 150 characters.
 }}}

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

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

[Django] #26061: Queryset raises EmptyResultSet (instead of print SQL query)

[Django]

#26061: Queryset raises EmptyResultSet  (instead of print SQL query)
--+
 Reporter:  ad-m  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8
 Severity:  Normal|   Keywords:  EmptyResultSet
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 {{{
 In [19]: import django

 In [20]: django.VERSION
 Out[20]: (1, 8, 7, 'final', 0)

 In [21]: print Record.objects.filter(pk__in=[])
 []
 In [22]: print Record.objects.filter(pk__in=[]).query
 ---
 EmptyResultSetTraceback (most recent call
 last)
  in ()
 > 1 print Record.objects.filter(pk__in=[]).query

 /home/adas/.virtualenvs/poradnia/local/lib/python2.7/site-
 packages/django/db/models/sql/query.pyc in __str__(self)
 213 done by the database interface at execution time.
 214 """
 --> 215 sql, params = self.sql_with_params()
 216 return sql % params
 217

 /home/adas/.virtualenvs/poradnia/local/lib/python2.7/site-
 packages/django/db/models/sql/query.pyc in sql_with_params(self)
 221 substituted into the query.
 222 """
 --> 223 return self.get_compiler(DEFAULT_DB_ALIAS).as_sql()
 224
 225 def __deepcopy__(self, memo):

 /home/adas/.virtualenvs/poradnia/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.pyc in as_sql(self, with_limits,
 with_col_aliases, subquery)
 385 from_, f_params = self.get_from_clause()
 386
 --> 387 where, w_params = self.compile(self.query.where)
 388 having, h_params = self.compile(self.query.having)
 389 params = []

 /home/adas/.virtualenvs/poradnia/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.pyc in compile(self, node,
 select_format)
 355 sql, params = vendor_impl(self, self.connection)
 356 else:
 --> 357 sql, params = node.as_sql(self, self.connection)
 358 if select_format and not self.subquery:
 359 return node.output_field.select_format(self, sql,
 params)

 /home/adas/.virtualenvs/poradnia/local/lib/python2.7/site-
 packages/django/db/models/sql/where.pyc in as_sql(self, compiler,
 connection)
 131 return '', []
 132 else:
 --> 133 raise EmptyResultSet
 134 if full_needed - everything_childs <= 0:
 135 if self.negated:

 EmptyResultSet:

 }}}

 I expect to achieve SQL query not exception.

 There is #10181, but it was about query execution. My issues is about
 query printing.

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

Re: [Django] #24980: Calendar selector for DateField defaults to wrong date when timezone is missmatching

[Django]

#24980: Calendar selector for DateField defaults to wrong date when timezone is
missmatching
-+
 Reporter:  edruid   |Owner:  sasha0
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+
Changes (by timgraham):

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


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

Re: [Django] #24980: Calendar selector for DateField defaults to wrong date when timezone is missmatching

[Django]

#24980: Calendar selector for DateField defaults to wrong date when timezone is
missmatching
-+
 Reporter:  edruid   |Owner:  sasha0
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.8
 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:  1
-+

Comment (by Tim Graham ):

 In [changeset:"caeacd94ddc7fa8e7e408ad252cfff4601d502c4" caeacd94]:
 {{{
 #!CommitTicketReference repository=""
 revision="caeacd94ddc7fa8e7e408ad252cfff4601d502c4"
 [1.8.x] Refs #24980 -- Fixed incorrect timezone handling in admin calendar
 widget.

 Backport of ea7542891a4e3638a695c58bd6f00658b7c85985 from master
 }}}

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

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

Re: [Django] #24980: Calendar selector for DateField defaults to wrong date when timezone is missmatching

[Django]

#24980: Calendar selector for DateField defaults to wrong date when timezone is
missmatching
-+
 Reporter:  edruid   |Owner:  sasha0
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.8
 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:  1
-+

Comment (by Tim Graham ):

 In [changeset:"835fff47322bafcd57906601b8ba8675b2d762d5" 835fff4]:
 {{{
 #!CommitTicketReference repository=""
 revision="835fff47322bafcd57906601b8ba8675b2d762d5"
 [1.9.x] Refs #24980 -- Fixed incorrect timezone handling in admin calendar
 widget.

 Backport of ea7542891a4e3638a695c58bd6f00658b7c85985 from master
 }}}

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

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

Re: [Django] #24980: Calendar selector for DateField defaults to wrong date when timezone is missmatching

[Django]

#24980: Calendar selector for DateField defaults to wrong date when timezone is
missmatching
-+
 Reporter:  edruid   |Owner:  sasha0
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.8
 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:  1
-+

Comment (by Tim Graham ):

 In [changeset:"ea7542891a4e3638a695c58bd6f00658b7c85985" ea754289]:
 {{{
 #!CommitTicketReference repository=""
 revision="ea7542891a4e3638a695c58bd6f00658b7c85985"
 Refs #24980 -- Fixed incorrect timezone handling in admin calendar widget.
 }}}

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

Re: [Django] #24980: Calendar selector for DateField defaults to wrong date when timezone is missmatching

[Django]

#24980: Calendar selector for DateField defaults to wrong date when timezone is
missmatching
-+
 Reporter:  edruid   |Owner:  sasha0
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.8
 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:  1
-+
Changes (by sasha0):

 * status:  new => assigned
 * owner:  nobody => sasha0
 * has_patch:  0 => 1


Comment:

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

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

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

Re: [Django] #25858: Deriving from abstract model with foreign key to model in same app broken on Django 1.9

[Django]

#25858: Deriving from abstract model with foreign key to model in same app 
broken
on Django 1.9
-+-
 Reporter:  kaedroho |Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 Posted to @developpers: https://groups.google.com/d/msg/django-
 developers/jRut8aYEet0/IrSiXwK5EgAJ

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

Re: [Django] #26059: BrokenLinkEmailsMiddleware flagging invalid *referer* URL

[Django]

#26059: BrokenLinkEmailsMiddleware flagging invalid *referer* URL
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
  BrokenLinkEmailsMiddleware,|  Unreviewed
  referer|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by marktranchant):

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


Comment:

 Done some testing and yes, it is #25971, not the newly-invalid referer.
 Marked ticket as invalid.

 Many thanks for the pointer. I had seen that but not realized the
 relevance.

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

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

Re: [Django] #24980: Calendar selector for DateField defaults to wrong date when timezone is missmatching

[Django]

#24980: Calendar selector for DateField defaults to wrong date when timezone is
missmatching
-+
 Reporter:  edruid   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+

Comment (by sasha0):

 Replying to [comment:10 timgraham]:
 > Looks like this broke some selenium tests:
 
`admin_widgets.tests.DateTimePickerSeleniumFirefoxTests.test_calendar_nonday_class`
 and  `test_calendar_selected_class`

 I'm looking into this.

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

Re: [Django] #26060: Regression in reverse one-to-one field when in readonly_fields

[Django]

#26060: Regression in reverse one-to-one field when in readonly_fields
-+
 Reporter:  damycra  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Bisected to fb48eb05816b1ac87d58696cdfe48be18c901f16

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

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

[Django]

#26034: Altering CharFields to have both db_index=True and unique=True crashes 
on
postgresql
-+-
 Reporter:  kaedroho |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8
 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 Tim Graham ):

 In [changeset:"f8c3d38c2d26f99ca620d76a0d88b69eeeb88c2c" f8c3d38c]:
 {{{
 #!CommitTicketReference repository=""
 revision="f8c3d38c2d26f99ca620d76a0d88b69eeeb88c2c"
 [1.8.x] Fixed #26034 -- Fixed incorrect index handling on PostgreSQL on
 Char/TextField with unique=True and db_index=True.

 Thanks Simon Charette for review.

 Backport of 56aaae58a746eb39d5e92ba60f59f4c750a8e1a8 from master
 }}}

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

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

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

[Django]

#26034: Altering CharFields to have both db_index=True and unique=True crashes 
on
postgresql
-+-
 Reporter:  kaedroho |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8
 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 Tim Graham ):

 In [changeset:"3d324b9614afa1e9b391b30f6f21d2f65fa8ac90" 3d324b9]:
 {{{
 #!CommitTicketReference repository=""
 revision="3d324b9614afa1e9b391b30f6f21d2f65fa8ac90"
 [1.9.x] Fixed #26034 -- Fixed incorrect index handling on PostgreSQL on
 Char/TextField with unique=True and db_index=True.

 Thanks Simon Charette for review.

 Backport of 56aaae58a746eb39d5e92ba60f59f4c750a8e1a8 from master
 }}}

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

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

Re: [Django] #21113: django_admin_log table stores messages in different languages depending on which language was active while editing.

[Django]

#21113: django_admin_log table stores messages in different languages depending 
on
which language was active while editing.
-+-
 Reporter:  dimyur27@…   |Owner:  Claude
 |  Paroz 
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin logs i18n  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

 * status:  new => closed
 * owner:   => Claude Paroz 
 * resolution:   => fixed


Comment:

 In [changeset:"cf7894be88f6c27680ef80796b883f6e3b709b8b" cf7894be]:
 {{{
 #!CommitTicketReference repository=""
 revision="cf7894be88f6c27680ef80796b883f6e3b709b8b"
 Fixed #21113 -- Made LogEntry.change_message language independent

 Thanks Tim Graham for the review.
 }}}

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

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

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

[Django]

#26034: Altering CharFields to have both db_index=True and unique=True crashes 
on
postgresql
-+-
 Reporter:  kaedroho |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8
 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
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"56aaae58a746eb39d5e92ba60f59f4c750a8e1a8" 56aaae58]:
 {{{
 #!CommitTicketReference repository=""
 revision="56aaae58a746eb39d5e92ba60f59f4c750a8e1a8"
 Fixed #26034 -- Fixed incorrect index handling on PostgreSQL on
 Char/TextField with unique=True and db_index=True.

 Thanks Simon Charette for review.
 }}}

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

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

Re: [Django] #25477: Modelbase.__new__ causes `AppRegistryNotReady`

[Django]

#25477: Modelbase.__new__ causes `AppRegistryNotReady`
--+
 Reporter:  cdestigter|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by edmorley):

 This caused confusion for me too - particularly since googling the
 exception (but not specifically django 1.9) brings up a number of
 misleading fixes for older problems.

 It would be great if:
 * The deprecation warning could be fixed in Django 1.8, particularly since
 it's an LTS release.
 * The Django 1.9 release notes could emphasise this breakage a bit more
 than they do currently, perhaps by changing this paragraph:
 > All models need to be defined inside an installed application or declare
 an explicit app_label. Furthermore, it isn’t possible to import them
 before their application is loaded. In particular, it isn’t possible to
 import models inside the root package of an application.
 (https://docs.djangoproject.com/en/1.9/releases/1.9/#features-removed-
 in-1-9)
 ...to mention the `AppRegistryNotReady: Apps aren't loaded yet.` exception
 explicitly.
 * The `AppRegistryNotReady` exception could state what app was being
 loaded, since it's not always clear from the traceback. (And in my case it
 was one of my third party packages that was causing the problem.)

 Many thanks :-)

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

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

Re: [Django] #26053: makemigrations generates a wrong type for a DurationField column on postgresql

[Django]

#26053: makemigrations generates a wrong type for a DurationField column on
postgresql
-+-
 Reporter:  benjellounayoub  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  makemigrations,  | Triage Stage:
  DurationField, postgresql, |  Unreviewed
  psycopg2   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 @benjellounayoub, the migration I commited was generated with the master
 branch because I first reproduced against 1.9 and tried against master to
 see if it was fixed.

 I managed to reproduce against Django [https://asciinema.org/a/33254
 again]. Please let me know if I missed something.

 Are you sure you don't have any third party app that might have interfered
 and you are really using the `django.db.models.DurationField`?

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

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

Re: [Django] #25385: Allow importing django.views.generic.View from django.views.View

[Django]

#25385: Allow importing django.views.generic.View from django.views.View
--+
 Reporter:  jambonrose|Owner:  auvipy
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Generic views |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by auvipy):

 Replying to [comment:18 varun]:
 > PR: https://github.com/django/django/pull/5951
  Hi Varun, I've already send a PR and the PR is still open. besides I
 haven't deassigned the issue yet :) so to avoid duplicate works better to
 ask the assigned guy first.

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

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

Re: [Django] #25385: Allow importing django.views.generic.View from django.views.View

[Django]

#25385: Allow importing django.views.generic.View from django.views.View
--+
 Reporter:  jambonrose|Owner:  auvipy
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Generic views |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by varun):

 * has_patch:  0 => 1


Comment:

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

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

Re: [Django] #26056: ArrayField does not work with ValueListQuerySet

[Django]

#26056: ArrayField does not work with ValueListQuerySet
--+
 Reporter:  CGenie|Owner:
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Description changed by timgraham:

Old description:

> Basically queries of type:
>
> {{{#!python
> A.objects.filter(array_field__overlap=B.objects.filter(foo))
> }}}
>
> fail at Python level:
>
> {{{
> Traceback (most recent call last):
>   File "failing.py", line 9, in 
> UserList.objects.filter(users__overlap=User.objects.all().values_list('id',
> flat=True)).count()
>   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
> packages/Django-1.8.5-py2.7.egg/django/db/models/query.py", line 318, in
> count
> return self.query.get_count(using=self.db)
>   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
> packages/Django-1.8.5-py2.7.egg/django/db/models/sql/query.py", line 466,
> in get_count
> number = obj.get_aggregation(using, ['__count'])['__count']
>   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
> packages/Django-1.8.5-py2.7.egg/django/db/models/sql/query.py", line 447,
> in get_aggregation
> result = compiler.execute_sql(SINGLE)
>   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
> packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
> 829, in execute_sql
> sql, params = self.as_sql()
>   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
> packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
> 387, in as_sql
> where, w_params = self.compile(self.query.where)
>   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
> packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
> 357, in compile
> sql, params = node.as_sql(self, self.connection)
>   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
> packages/Django-1.8.5-py2.7.egg/django/db/models/sql/where.py", line 104,
> in as_sql
> sql, params = compiler.compile(child)
>   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
> packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
> 357, in compile
> sql, params = node.as_sql(self, self.connection)
>   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
> packages/Django-1.8.5-py2.7.egg/django/contrib/postgres/fields/array.py",
> line 183, in as_sql
> sql, params = super(ArrayOverlap, self).as_sql(qn, connection)
>   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
> packages/Django-1.8.5-py2.7.egg/django/contrib/postgres/lookups.py", line
> 8, in as_sql
> params = lhs_params + rhs_params
> TypeError: can only concatenate list (not "tuple") to list
> }}}
>
> Toy project to reproduce this behavior can be found here:
> https://github.com/CGenie/django_array_join_fail
>
> This fails in 1.8 as well as in 1.9.

New description:

 Basically queries of type:

 {{{#!python
 A.objects.filter(array_field__overlap=B.objects.filter(foo).values_list('id',
 flat=True))
 }}}

 fail at Python level:

 {{{
 Traceback (most recent call last):
   File "failing.py", line 9, in 
 UserList.objects.filter(users__overlap=User.objects.all().values_list('id',
 flat=True)).count()
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/query.py", line 318, in
 count
 return self.query.get_count(using=self.db)
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/query.py", line 466,
 in get_count
 number = obj.get_aggregation(using, ['__count'])['__count']
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/query.py", line 447,
 in get_aggregation
 result = compiler.execute_sql(SINGLE)
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
 829, in execute_sql
 sql, params = self.as_sql()
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
 387, in as_sql
 where, w_params = self.compile(self.query.where)
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
 357, in compile
 sql, params = node.as_sql(self, self.connection)
   File "/home/przemek/

Re: [Django] #26056: ArrayField does not work with ValueListQuerySet

[Django]

#26056: ArrayField does not work with ValueListQuerySet
--+
 Reporter:  CGenie|Owner:
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by charettes):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.9 => master
 * needs_docs:   => 0
 * type:  Bug => New feature
 * stage:  Unreviewed => Accepted


Comment:

 Accepting as a new feature by assuming you meant
 `B.objects.filter(foo).values('pk')` in your reported example.

 The implementation could simply use the PostgreSQL `array()` function to
 wrap the queryset.

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

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

[Django]

#25165: Move JavaScript calls out of HTML to fix JavaScript "no-script-eval"
warnings
-+-
 Reporter:  timgraham|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

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

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

[Django]

#25165: Move JavaScript calls out of HTML to fix JavaScript "no-script-eval"
warnings
-+-
 Reporter:  timgraham|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"ade54ffa34ddc6c19b26c6ea72b46f73af7b682b" ade54ff]:
 {{{
 #!CommitTicketReference repository=""
 revision="ade54ffa34ddc6c19b26c6ea72b46f73af7b682b"
 Refs #25165 -- Fixed JSON serialization for add/edit popup in the admin.

 Forwardport of test in o839d71d8562abe0b245024e55ca1d02a45e58fd from
 stable/1.9.x
 (refs #25997).
 }}}

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

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

Re: [Django] #25997: Editing ForeignKey in admin popup causes incorrect escaping for uuid field

[Django]

#25997: Editing ForeignKey in admin popup causes incorrect escaping for uuid 
field
-+
 Reporter:  zachborboa   |Owner:  sasha0
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham ):

 In [changeset:"ade54ffa34ddc6c19b26c6ea72b46f73af7b682b" ade54ff]:
 {{{
 #!CommitTicketReference repository=""
 revision="ade54ffa34ddc6c19b26c6ea72b46f73af7b682b"
 Refs #25165 -- Fixed JSON serialization for add/edit popup in the admin.

 Forwardport of test in o839d71d8562abe0b245024e55ca1d02a45e58fd from
 stable/1.9.x
 (refs #25997).
 }}}

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

Re: [Django] #26043: Add a hook to run queries between the start of a transaction and a view

[Django]

#26043: Add a hook to run queries between the start of a transaction and a view
---+
 Reporter:  srkunze|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by apollo13):

 @tim: Yes that was the main motivation of the middleware refactor. We
 should have `TransactionMiddleware` in 1.10 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/065.a04431ce6c7b0e23dcc639c2409769a9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26043: Add a hook to run queries between the start of a transaction and a view

[Django]

#26043: Add a hook to run queries between the start of a transaction and a view
---+
 Reporter:  srkunze|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by apollo13):

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

Re: [Django] #23521: removal of concrete Model from bases doesn't remove it from ModelState bases

[Django]

#23521: removal of concrete Model from bases doesn't remove it from ModelState
bases
+
 Reporter:  sir-sigurd  |Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 crearc):

 * cc: ericmills2@… (added)


Comment:

 This bug has burned me pretty bad. I was working through steps to switch
 from concrete inheritance to abstract inheritance. Is someone going to
 revisit this?

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

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

[Django]

#25165: Move JavaScript calls out of HTML to fix JavaScript "no-script-eval"
warnings
-+-
 Reporter:  timgraham|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"822a03b3e41c7c26b7b623c782fbcf9e6eea863f" 822a03b3]:
 {{{
 #!CommitTicketReference repository=""
 revision="822a03b3e41c7c26b7b623c782fbcf9e6eea863f"
 Refs #25165 -- Fixed failure of admin's "Add another" popup to close.

 Thanks Thomas Grainger for the fix.
 }}}

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

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

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

[Django]

#26034: Altering CharFields to have both db_index=True and unique=True crashes 
on
postgresql
-+-
 Reporter:  kaedroho |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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

Re: [Django] #26060: Regression in reverse one-to-one field when in readonly_fields

[Django]

#26060: Regression in reverse one-to-one field when in readonly_fields
---+--
 Reporter:  damycra|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by damycra):

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


Old description:

> When upgrading from 1.7 to 1.8(.8) I started encountering errors in the
> admin with a reverse one to one relationship when it was in
> readonly_fields.  I assume this is a regression.  Naturally, I am happy
> to help fix it (if it is not by design), given a steer!
>
> Tested with Python 2.7.10, the project template was created with Django
> 1.8.8.
>
> cd /tmp
> git clone https://github.com/damycra/django-readonly-onetoone.git
> cd django-readonly-onetoone/
> mkvirtualenv dj_onetoone
>
> # make sure virtualenv is activated, then:
> pip install -r requirements.txt
> ./manage.py migrate
> ./manage.py createsuperuser
> ./manage.py runserver
> # open http://127.0.0.1:8000/admin/simple/a/add/
> # create an A object
> # create a B object referencing the A
> http://127.0.0.1:8000/admin/simple/b/add
> # return to original A object http://127.0.0.1:8000/admin/simple/a/1/
>
> # now upgrade to Django 1.8.8
> pip install Django==1.8.8
> ./manage.py migrate
> ./manage.py runserver
> # return to http://127.0.0.1:8000/admin/simple/a/1/
> ''' AttributeError at /admin/simple/a/1/
> OneToOneRel object has no attribute 'rel
>
> # now upgrade to Django 1.9.1
> pip install Django==1.9.1
> ./manage.py migrate
> ./manage.py runserver
> # go to http://127.0.0.1:8000/admin/simple/a/1/change/
> ''' AttributeError at /admin/simple/a/1/change/
> 'OneToOneRel' object has no attribute 'flatchoices
>
> A simple workaround is to use a method on ModelAdmin
>
> {{{
> class WorkingAAdmin(admin.ModelAdmin):
> readonly_fields = ['working_b']
> def working_b(self, instance):
> return instance.b
> working_b.short_description = 'working'
> }}}
>
> See also [https://code.djangoproject.com/ticket/24851#comment:8
> https://code.djangoproject.com/ticket/24851#comment:8]

New description:

 When upgrading from 1.7 to 1.8(.8) I started encountering errors in the
 admin with a reverse one to one relationship when it was in
 readonly_fields.  I assume this is a regression.  Naturally, I am happy to
 help fix it (if it is not by design), given a steer!

 The attached simple project shows the issue (it was created with Django
 1.8.8). Python 2.7.10

 cd /tmp
 git clone https://github.com/damycra/django-readonly-onetoone.git
 cd django-readonly-onetoone/
 mkvirtualenv dj_onetoone

 # make sure virtualenv is activated, then:
 pip install -r requirements.txt
 ./manage.py migrate
 ./manage.py createsuperuser
 ./manage.py runserver
 # open http://127.0.0.1:8000/admin/simple/a/add/
 # create an A object
 # create a B object referencing the A
 http://127.0.0.1:8000/admin/simple/b/add
 # return to original A object http://127.0.0.1:8000/admin/simple/a/1/

 # now upgrade to Django 1.8.8
 pip install Django==1.8.8
 ./manage.py migrate
 ./manage.py runserver
 # return to http://127.0.0.1:8000/admin/simple/a/1/
 ''' AttributeError at /admin/simple/a/1/
 OneToOneRel object has no attribute 'rel

 # now upgrade to Django 1.9.1
 pip install Django==1.9.1
 ./manage.py migrate
 ./manage.py runserver
 # go to http://127.0.0.1:8000/admin/simple/a/1/change/
 ''' AttributeError at /admin/simple/a/1/change/
 'OneToOneRel' object has no attribute 'flatchoices

 A simple workaround is to use a method on ModelAdmin

 {{{
 class WorkingAAdmin(admin.ModelAdmin):
 readonly_fields = ['working_b']
 def working_b(self, instance):
 return instance.b
 working_b.short_description = 'working'
 }}}

 See also [https://code.djangoproject.com/ticket/24851#comment:8
 https://code.djangoproject.com/ticket/24851#comment:8]

--

--
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.9793b58a85ebeaa10505716077cefd95%

Re: [Django] #26060: Regression in reverse one-to-one field when in readonly_fields

[Django]

#26060: Regression in reverse one-to-one field when in readonly_fields
---+
 Reporter:  damycra|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.8
 Severity:  Normal | Resolution:
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by damycra):

 * Attachment "django-readonly-onetoone-master.zip" added.

 Zip of Github project

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

[Django] #26060: Regression in reverse one-to-one field when in readonly_fields

[Django]

#26060: Regression in reverse one-to-one field when in readonly_fields
---+
 Reporter:  damycra|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When upgrading from 1.7 to 1.8(.8) I started encountering errors in the
 admin with a reverse one to one relationship when it was in
 readonly_fields.  I assume this is a regression.  Naturally, I am happy to
 help fix it (if it is not by design), given a steer!

 Tested with Python 2.7.10, the project template was created with Django
 1.8.8.

 cd /tmp
 git clone https://github.com/damycra/django-readonly-onetoone.git
 cd django-readonly-onetoone/
 mkvirtualenv dj_onetoone

 # make sure virtualenv is activated, then:
 pip install -r requirements.txt
 ./manage.py migrate
 ./manage.py createsuperuser
 ./manage.py runserver
 # open http://127.0.0.1:8000/admin/simple/a/add/
 # create an A object
 # create a B object referencing the A
 http://127.0.0.1:8000/admin/simple/b/add
 # return to original A object http://127.0.0.1:8000/admin/simple/a/1/

 # now upgrade to Django 1.8.8
 pip install Django==1.8.8
 ./manage.py migrate
 ./manage.py runserver
 # return to http://127.0.0.1:8000/admin/simple/a/1/
 ''' AttributeError at /admin/simple/a/1/
 OneToOneRel object has no attribute 'rel

 # now upgrade to Django 1.9.1
 pip install Django==1.9.1
 ./manage.py migrate
 ./manage.py runserver
 # go to http://127.0.0.1:8000/admin/simple/a/1/change/
 ''' AttributeError at /admin/simple/a/1/change/
 'OneToOneRel' object has no attribute 'flatchoices

 A simple workaround is to use a method on ModelAdmin

 {{{
 class WorkingAAdmin(admin.ModelAdmin):
 readonly_fields = ['working_b']
 def working_b(self, instance):
 return instance.b
 working_b.short_description = 'working'
 }}}

 See also [https://code.djangoproject.com/ticket/24851#comment:8
 https://code.djangoproject.com/ticket/24851#comment:8]

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

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
--+
 Reporter:  jonasborgstrom|Owner:  tltx
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by tltx):

 Hi again, pull request is up.

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

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

Re: [Django] #25997: Editing ForeignKey in admin popup causes incorrect escaping for uuid field

[Django]

#25997: Editing ForeignKey in admin popup causes incorrect escaping for uuid 
field
-+
 Reporter:  zachborboa   |Owner:  sasha0
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"a839d71d8562abe0b245024e55ca1d02a45e58fd" a839d71d]:
 {{{
 #!CommitTicketReference repository=""
 revision="a839d71d8562abe0b245024e55ca1d02a45e58fd"
 [1.9.x] Fixed #25997 -- Removed redundant escaping in admin's edit related
 model popup.
 }}}

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

Re: [Django] #26058: Custom storage backend's not entirely decoupled from FileField

[Django]

#26058: Custom storage backend's not entirely decoupled from FileField
-+-
 Reporter:  Korijn   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  File |  Version:  1.9
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  custom storage   | Triage Stage:  Accepted
  filefield  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Korijn):

 How's this?


 {{{
 def generate_filename(self, instance, filename):
 # allow for customized filename generation
 if hasattr(self.storage, 'generate_filename'):
 if callable(self.upload_to):
 filename = self.upload_to(instance, filename)
 return self.storage.generate_filename(filename)

 filename =
 force_text(datetime.datetime.now().strftime(force_str(self.upload_to)))
 return self.storage.generate_filename(filename)

 # If upload_to is a callable, make sure that the path it returns
 is
 # passed through get_valid_name() of the underlying storage.
 if callable(self.upload_to):
 directory_name, filename =
 os.path.split(self.upload_to(instance, filename))
 filename = self.storage.get_valid_name(filename)
 return os.path.normpath(os.path.join(directory_name,
 filename))

 return os.path.join(self.get_directory_name(),
 self.get_filename(filename))
 }}}

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

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
--+
 Reporter:  jonasborgstrom|Owner:  tltx
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by timgraham):

 Master please.

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

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

[Django]

#25165: Move JavaScript calls out of HTML to fix JavaScript "no-script-eval"
warnings
-+-
 Reporter:  timgraham|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/5948 PR] for the issue in comment
 4.

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

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

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
--+
 Reporter:  jonasborgstrom|Owner:  tltx
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by tltx):

 Absolutely, which branch should I create a PR against?

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

Re: [Django] #24980: Calendar selector for DateField defaults to wrong date when timezone is missmatching

[Django]

#24980: Calendar selector for DateField defaults to wrong date when timezone is
missmatching
-+
 Reporter:  edruid   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+
Changes (by timgraham):

 * status:  closed => new
 * has_patch:  1 => 0
 * resolution:  fixed =>


Comment:

 Looks like this broke some selenium tests:
 
`admin_widgets.tests.DateTimePickerSeleniumFirefoxTests.test_calendar_nonday_class`
 and  `test_calendar_selected_class`

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

Re: [Django] #26059: BrokenLinkEmailsMiddleware flagging invalid *referer* URL

[Django]

#26059: BrokenLinkEmailsMiddleware flagging invalid *referer* URL
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  BrokenLinkEmailsMiddleware,|  Unreviewed
  referer|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Any chance this is related to `APPEND_SLASH` and #25971?

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

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

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

[Django]

#26034: Altering CharFields to have both db_index=True and unique=True crashes 
on
postgresql
-+-
 Reporter:  kaedroho |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 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 timgraham):

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

Re: [Django] #26059: BrokenLinkEmailsMiddleware flagging invalid *referer* URL

[Django]

#26059: BrokenLinkEmailsMiddleware flagging invalid *referer* URL
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  BrokenLinkEmailsMiddleware,|  Unreviewed
  referer|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by marktranchant):

 I'll have a go, but looking at the relatively simple middleware code, I'm
 not sure that's where the problem lies.

 {{{
 class BrokenLinkEmailsMiddleware(object):
 def process_response(self, request, response):
 if response.status_code == 404 and not settings.DEBUG:
 # (send the email)
 }}}

 It looks from that as though the '''referer''' URL is being queried at
 some point, and the middleware is doing what it should.

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

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

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

[Django]

#25971: BrokenLinkEmailsMiddleware shouldn't report 404s when URL = Referer + 
"/"
--+
 Reporter:  jribbens  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by timgraham):

 Unless this is a regression in Django 1.8, please send the pull request
 against master. The ticket "Version" only indicates what version the issue
 was reported in.

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

Re: [Django] #26055: mod_wsgi docs refer to serving CSS files as static without corresponding example

[Django]

#26055: mod_wsgi docs refer to serving CSS files as static without corresponding
example
---+--
 Reporter:  chmarr |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Tim Graham ):

 In [changeset:"f42ab40b733e9a9a00afd9f68de1f041cb96c7e6" f42ab40]:
 {{{
 #!CommitTicketReference repository=""
 revision="f42ab40b733e9a9a00afd9f68de1f041cb96c7e6"
 [1.9.x] Fixed #26055 -- Removed an orphaned phrase in
 docs/howto/deployment/wsgi/modwsgi.txt.

 Backport of db8f462494d603eba922818479a87f5ddfe1a13b from master
 }}}

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

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

Re: [Django] #26055: mod_wsgi docs refer to serving CSS files as static without corresponding example

[Django]

#26055: mod_wsgi docs refer to serving CSS files as static without corresponding
example
---+--
 Reporter:  chmarr |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Tim Graham ):

 In [changeset:"ae39a066031e544ec245d35a558e4d02ef798558" ae39a066]:
 {{{
 #!CommitTicketReference repository=""
 revision="ae39a066031e544ec245d35a558e4d02ef798558"
 [1.8.x] Fixed #26055 -- Removed an orphaned phrase in
 docs/howto/deployment/wsgi/modwsgi.txt.

 Backport of db8f462494d603eba922818479a87f5ddfe1a13b from master
 }}}

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

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

Re: [Django] #26055: mod_wsgi docs refer to serving CSS files as static without corresponding example

[Django]

#26055: mod_wsgi docs refer to serving CSS files as static without corresponding
example
---+--
 Reporter:  chmarr |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"db8f462494d603eba922818479a87f5ddfe1a13b" db8f4624]:
 {{{
 #!CommitTicketReference repository=""
 revision="db8f462494d603eba922818479a87f5ddfe1a13b"
 Fixed #26055 -- Removed an orphaned phrase in
 docs/howto/deployment/wsgi/modwsgi.txt.
 }}}

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

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
--+
 Reporter:  jonasborgstrom|Owner:  tltx
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by timgraham):

 Are you able to submit the patch as a pull request?

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

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

Re: [Django] #26058: Custom storage backend's not entirely decoupled from FileField

[Django]

#26058: Custom storage backend's not entirely decoupled from FileField
-+-
 Reporter:  Korijn   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  File |  Version:  1.9
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  custom storage   | Triage Stage:  Accepted
  filefield  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 The main question is whether or not the changes can be made in a backwards
 compatible fashion.

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

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
--+
 Reporter:  jonasborgstrom|Owner:  tltx
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.9
 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 tltx):

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


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

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
--+
 Reporter:  jonasborgstrom|Owner:  tltx
 Type:  Bug   |   Status:  closed
Component:  contrib.sessions  |  Version:  1.9
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by tltx):

 Run the unit test without the fix to verify the bug. This fix should also
 be back ported to 1.8 as it is a security fix.

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

Re: [Django] #26059: BrokenLinkEmailsMiddleware flagging invalid *referer* URL

[Django]

#26059: BrokenLinkEmailsMiddleware flagging invalid *referer* URL
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  BrokenLinkEmailsMiddleware,|  Unreviewed
  referer|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Could you
 
[https://github.com/django/django/blob/59ef6559a31c175c1f52668ef0ffe9b8d87aa5a5/tests/middleware/tests.py#L333
 provide a test] to reproduce the issue?

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

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

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
--+
 Reporter:  jonasborgstrom|Owner:  tltx
 Type:  Bug   |   Status:  closed
Component:  contrib.sessions  |  Version:  1.9
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by tltx):

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


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

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
--+
 Reporter:  jonasborgstrom|Owner:  tltx
 Type:  Bug   |   Status:  assigned
Component:  contrib.sessions  |  Version:  1.9
 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 tltx):

 * Attachment "21608.diff" 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/072.8beac6245babb6e0d75fa086daae001d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
--+
 Reporter:  jonasborgstrom|Owner:  tltx
 Type:  Bug   |   Status:  assigned
Component:  contrib.sessions  |  Version:  1.9
 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 tltx):

 * cc: tlt@… (added)
 * owner:  anonymous => tltx
 * version:  1.8 => 1.9
 * needs_better_patch:  1 => 0


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

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

[Django] #26059: BrokenLinkEmailsMiddleware flagging invalid *referer* URL

[Django]

#26059: BrokenLinkEmailsMiddleware flagging invalid *referer* URL
-+-
 Reporter:   |  Owner:  nobody
  marktranchant  |
 Type:  Bug  | Status:  new
Component:  Core |Version:  1.9
  (URLs) |
 Severity:  Normal   |   Keywords:  BrokenLinkEmailsMiddleware, referer
 Triage Stage:   |  Has patch:  0
  Unreviewed |
Easy pickings:  0|  UI/UX:  0
-+-
 My project has a URL for users in the format {{{/staff/$USERNAME}}}. The
 view contains a form allows the user to update their details and redirects
 to {{{/staff}}} on submission.

 Recently (since either 1.9 or 1.9.1), I've been getting Broken Link email
 alerts without a corresponding 404 in the {{{nginx}}} server logs. It
 turns out these are being generated when the user updates their username,
 so when the redirect occurs, {{{/staff/$OLD_USERNAME}}} (the referer URL)
 is no longer valid.

 My project has not changed in the way it processes these requests: this is
 a new feature/bug/regression in Django, as far as I can tell.

 {{{
 Referrer: https://myproject/staff/wonko_the_sane/
 Requested URL: /staff
 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101
 Firefox/43.0
 IP address: 127.0.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/056.476eb5d2f524e7c23ad8ccbadba98df2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26058: Custom storage backend's not entirely decoupled from FileField

[Django]

#26058: Custom storage backend's not entirely decoupled from FileField
-+-
 Reporter:  Korijn   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  1.9
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  custom storage   | Triage Stage:
  filefield  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Korijn):

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


Old description:

> Let me start by saying that I've implemented custom FileFields that can
> handle Numpy objects, to provide some convenience methods to access the
> typed objects.
>
> Later, when implementing a custom storage backend for Azure Storage, I
> encountered some issues when handling filenames. Cloud storage doesn't
> behave like local file system storage does. Most of Django's code is
> agnostic of this problem, except for a small section of FileField:
>
> https://github.com/django/django/blob/77b8d8cb6d6d6345f479c68c4892291c1492ba7e/django/db/models/fields/files.py#L306-L320
>
> In Azure, blobs are stored in containers, and are optionally stored in
> subfolders (known as prefixes in Azure-speak). To be able to use the
> upload_to property, I need to be able to pass the full path, e.g.:
>
> container/blob
> container/sub/blob
> container/sub/sub/blob
>
> Unfortunately, FileField strips the directory part and only passes the
> blob name to my custom storage backend's get_valid_name implementation,
> where I really need to validate the whole string. I ended up subclassing
> FileField:
>
> {{{
> class CloudStorageFileField(FileField):
> """
> Provides some overrides to enable cloud storage backends
> """
>
> def get_directory_name(self):
> return
> force_text(datetime.datetime.now().strftime(force_str(self.upload_to)))
>
> def get_filename(self, filename):
> return filename
>
> def generate_filename(self, instance, filename):
> if callable(self.upload_to):
> filename = self.upload_to(instance, filename)
> filename = self.storage.get_valid_name(filename)
> return filename
>
> return self.get_directory_name() +
> self.storage.get_valid_name(filename)
> }}}
>
> As you can see, all I did was remove the local file system related logic.
> Unfortunately, my custom file fields need to inherit from this class to
> work with Azure storage, and when I switch to local storage in a
> different environment, they have to inherit from the regular FileField!
> This is obviously an undesirable situation, imposed by the otherwise-
> great tight coupling to local file system logic in the three methods of
> FileField.
>
> In order to truly decouple this, FielField would need to be a little bit
> more agnostic about the storage backend. This could be done by moving the
> generate_filename method to the backend entirely, for example.
>
> I classified this as a bug, as this case shows that you're not "entirely"
> able to do anything you want when implementing custom storage backends.
>
> You can see the full implementation of both the backend and the
> numpyfilefield here: https://gist.github.com/Korijn/e0bcbdcedb494509973a
>
> Your thoughts?

New description:

 Let me start by saying that I've implemented custom FileFields that can
 handle Numpy objects, to provide some convenience methods to access the
 typed objects.

 Later, when implementing a custom storage backend for Azure Storage, I
 encountered some issues when handling filenames. Cloud storage doesn't
 behave like local file system storage does. Most of Django's code is
 agnostic of this problem, except for a small section of FileField:

 
https://github.com/django/django/blob/77b8d8cb6d6d6345f479c68c4892291c1492ba7e/django/db/models/fields/files.py#L306-L320

 In Azure, blobs are stored in containers, and are optionally stored in
 subfolders (known as prefixes in Azure-speak). To be able to use the
 upload_to property, I need to be able to pass the full path, e.g.:

 container/blob
 container/sub/blob
 container/sub/sub/blob

 Unfortunately, FileField strips the directory part and only passes the
 blob name to my custom storage backend's get_valid_name implementation,
 where I really need to validate the whole string. I ended up subclassing
 FileField:

 {{{
 class CloudStorageFileField(FileField):
 """
 Provides some overrides to enable cloud storage backends
 """

 def get_directory_name(self):
 retur

[Django] #26058: Custom storage backend's not entirely decoupled from FileField

[Django]

#26058: Custom storage backend's not entirely decoupled from FileField
-+-
 Reporter:  Korijn   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  File |Version:  1.9
  uploads/storage|   Keywords:  custom storage
 Severity:  Normal   |  filefield
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Let me start by saying that I've implemented custom FileFields that can
 handle Numpy objects, to provide some convenience methods to access the
 typed objects.

 Later, when implementing a custom storage backend for Azure Storage, I
 encountered some issues when handling filenames. Cloud storage doesn't
 behave like local file system storage does. Most of Django's code is
 agnostic of this problem, except for a small section of FileField:

 
https://github.com/django/django/blob/77b8d8cb6d6d6345f479c68c4892291c1492ba7e/django/db/models/fields/files.py#L306-L320

 In Azure, blobs are stored in containers, and are optionally stored in
 subfolders (known as prefixes in Azure-speak). To be able to use the
 upload_to property, I need to be able to pass the full path, e.g.:

 container/blob
 container/sub/blob
 container/sub/sub/blob

 Unfortunately, FileField strips the directory part and only passes the
 blob name to my custom storage backend's get_valid_name implementation,
 where I really need to validate the whole string. I ended up subclassing
 FileField:

 {{{
 class CloudStorageFileField(FileField):
 """
 Provides some overrides to enable cloud storage backends
 """

 def get_directory_name(self):
 return
 force_text(datetime.datetime.now().strftime(force_str(self.upload_to)))

 def get_filename(self, filename):
 return filename

 def generate_filename(self, instance, filename):
 if callable(self.upload_to):
 filename = self.upload_to(instance, filename)
 filename = self.storage.get_valid_name(filename)
 return filename

 return self.get_directory_name() +
 self.storage.get_valid_name(filename)
 }}}

 As you can see, all I did was remove the local file system related logic.
 Unfortunately, my custom file fields need to inherit from this class to
 work with Azure storage, and when I switch to local storage in a different
 environment, they have to inherit from the regular FileField! This is
 obviously an undesirable situation, imposed by the otherwise-great tight
 coupling to local file system logic in the three methods of FileField.

 In order to truly decouple this, FielField would need to be a little bit
 more agnostic about the storage backend. This could be done by moving the
 generate_filename method to the backend entirely, for example.

 I classified this as a bug, as this case shows that you're not "entirely"
 able to do anything you want when implementing custom storage backends.

 You can see the full implementation of both the backend and the
 numpyfilefield here: https://gist.github.com/Korijn/e0bcbdcedb494509973a

 Your thoughts?

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

Re: [Django] #26055: mod_wsgi docs refer to serving CSS files as static without corresponding example

[Django]

#26055: mod_wsgi docs refer to serving CSS files as static without corresponding
example
---+--
 Reporter:  chmarr |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by timgraham):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Documentation
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * type:  Uncategorized => Bug


Comment:

 "Any CSS file" should have been removed in
 4b0a45ce64bfa1ce39d963738ffb0af57f4517e5.

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

Re: [Django] #26053: makemigrations generates a wrong type for a DurationField column on postgresql

[Django]

#26053: makemigrations generates a wrong type for a DurationField column on
postgresql
-+-
 Reporter:  benjellounayoub  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  makemigrations,  | Triage Stage:
  DurationField, postgresql, |  Unreviewed
  psycopg2   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Could you please provide a sample project with steps to reproduce it? For
 the provided model, I'm still seeing this for the 1.9 branch:
 {{{
 migrations.CreateModel(
 name='Foo',
 fields=[
 ('id', models.AutoField(auto_created=True, primary_key=True,
 serialize=False, verbose_name='ID')),
 ('bar', models.DurationField()),
 ],
 ),
 }}}

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

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

Re: [Django] #23577: CREATE INDEX-related OperationalError on migrating renamed models with colliding field names

[Django]

#23577: CREATE INDEX-related OperationalError on migrating renamed models with
colliding field names
+
 Reporter:  CrimsonZen  |Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 evenicoulddoit):

 I tried to migrate to a new model and bumped into this one. To fix, I made
 sure that I renamed my existing model to "old" first (e.g.
 Model->ModelOld), create the new model with the previous name (e.g.
 Model), migrate the data and then remove the old model. My previous
 strategy of creating the new table migrating the data and then renaming it
 broke due to the index issues.

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

Re: [Django] #26057: Template {% if perms.app_label.permission %} check failing, but {% if 'app_label.permission' in perms %} works

[Django]

#26057: Template {% if perms.app_label.permission %} check failing, but {% if
'app_label.permission' in perms %} works
-+--
 Reporter:  McAnix   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  permissions  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by McAnix):

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


Comment:

 The issue was in the call:

 {{{
 {% if perms.core.can_view_co.uk %}
 }}}

 which would split on the .

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

Re: [Django] #26053: makemigrations generates a wrong type for a DurationField column on postgresql

[Django]

#26053: makemigrations generates a wrong type for a DurationField column on
postgresql
-+-
 Reporter:  benjellounayoub  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  makemigrations,  | Triage Stage:
  DurationField, postgresql, |  Unreviewed
  psycopg2   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by benjellounayoub):

 Replying to [comment:1 charettes]:

 I think you are using the Django's version 1.10.dev for your test and not
 the 1.9

 > Hi benjellounayoub,
 >
 > I couldn't reproduce against PostgreSQL 9.3 and 9.3 on Ubuntu with
 Django 1.9.1 and master using a [https://github.com/charettes/django-
 ticketing/commit/b5ddf8554d41d23474f48ae3bf156af5f0f0b9ca similar test
 application].
 >
 > {{{
 > \d ticket_26053_foo;
 >   Table "public.ticket_26053_foo"
 >  Column |   Type   |   Modifiers
 >
 
+--+---
 >  id | integer  | not null default
 nextval('ticket_26053_foo_id_seq'::regclass)
 >  bar| interval | not null
 > Indexes:
 > "ticket_26053_foo_pkey" PRIMARY KEY, btree (id)
 > }}}
 >
 > Can you confirm the generated migration's `CreateModel` operation used a
 `models.DurationField()` for its `'bar'` 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/073.fac251fb7e44456b85291119368b3d52%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26053: makemigrations generates a wrong type for a DurationField column on postgresql

[Django]

#26053: makemigrations generates a wrong type for a DurationField column on
postgresql
-+-
 Reporter:  benjellounayoub  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  makemigrations,  | Triage Stage:
  DurationField, postgresql, |  Unreviewed
  psycopg2   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by benjellounayoub):

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


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

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

Re: [Django] #26053: makemigrations generates a wrong type for a DurationField column on postgresql

[Django]

#26053: makemigrations generates a wrong type for a DurationField column on
postgresql
-+-
 Reporter:  benjellounayoub  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  makemigrations,  | Triage Stage:
  DurationField, postgresql, |  Unreviewed
  psycopg2   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by benjellounayoub):

 Sorry but there is no mistake at all, i can reproduce the issue again and
 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/073.af2ffd902357d8e70e8d5307f85e632a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26057: Template {% if perms.app_label.permission %} check failing, but {% if 'app_label.permission' in perms %} works

[Django]

#26057: Template {% if perms.app_label.permission %} check failing, but {% if
'app_label.permission' in perms %} works
-+--
 Reporter:  McAnix   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  permissions  | 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 McAnix:

Old description:

> I'm encountering the issue above for dynamically generated permissions.
>
> I have a Zone model (see below) in a project named "Core" that holds some
> content and dynamically builds row-level-like permissions for each entry
> using a post_save and post_delete hook to manage it. Please don't judge
> me on the usage, it was the simplest solution at the time and the Zone
> model content changes infrequently.
>
> The issue I'm facing is when using the dynamic permissions in a template,
> even as admin. I've tested the following in the template:
>
> {{{
> {% if 'core.can_view_myzone' in perms %}Check passes{% endif %} <- WORKS
> {% perms.core.can_view_myzone %}Check fails{% endif %} <- DOESN'T WORK
> }}}
>
> Also in the view:
>
> {{{
> print "CAN VIEW: %s" % request.user.has_perm('core.can_view_myzone') <-
> WORKS
> }}}
>
> Other permissions that are created via the permissions variable in the
> Meta class work fine '''BUT''' not if they're in the Zone model. I have
> checked migrations and the db tables for
> django_content_type/auth_permission and everything exists there and links
> correctly.
>
> Middleware as follows:
>
> {{{
> MIDDLEWARE_CLASSES = (
> 'django.middleware.common.CommonMiddleware',
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> 'django.contrib.messages.middleware.MessageMiddleware',
> )
> }}}
>
> Template Context Processors:
>
> {{{
> TEMPLATE_CONTEXT_PROCESSORS =
> ('django.contrib.auth.context_processors.auth',
> 'django.core.context_processors.debug',
> 'django.core.context_processors.i18n',
> 'django.core.context_processors.media',
> 'django.core.context_processors.static',
> 'django.contrib.messages.context_processors.messages',
> 'djutils.context_processors.settings_loader') # This just exposes
> selected settings to the templates
> }}}
>
> {{{
> class Zone(models.Model):
>   """A holder model for zone information as well as permission slips for
> each zone"""
>
>   class Meta:
> permissions = ()
>
>   cdate = models.DateTimeField(auto_now_add=True)
>   name = models.CharField(max_length=63)
>   url = models.CharField(max_length=255, verbose_name="Zone URL")
>   enabled = models.BooleanField()
>
>   def __unicode__(self):
> return "%s (Enabled: %s)" % (self.name, self.enabled)
>
> def create_zone_permission(sender, instance, created, raw, using,
> **kwargs):
>   """Creates a new zone permission entry for the new zone"""
>   content_type = ContentType.objects.get(app_label='core', model='zone')
>   codename = 'can_view_%s' % (instance.name, )
>   name='Can View %s' % (instance.name, )
>
>   if not Permission.objects.using(using).filter(codename=codename,
> content_type=content_type).exists():
> logger.info("Creating zone specific permissions for %s" % (codename,
> ))
> Permission.objects.using(using).create(codename=codename, name=name,
> content_type=content_type)
>

> def delete_zone_permission(sender, instance, using, **kwargs):
>   """Creates a new zone permission entry for the new zone"""
>   content_type = ContentType.objects.get(app_label='core', model='zone')
>   codename = 'can_view_%s' % (instance.name, )
>
>   if Permission.objects.using(using).filter(codename=codename,
> content_type=content_type).exists():
> logger.info("Deleting zone specific permissions for %s" % (codename,
> ))
> permission =
> Permission.objects.using(using).filter(codename=codename,
> content_type=content_type)
>
> permission.delete(using=using)
>
> post_save.connect(create_zone_permission, sender=Zone)
> post_delete.connect(delete_zone_permission, sender=Zone)
> }}}

New description:

 I'm encountering the issue above for dynamically generated permissions.

 I have a Zone model (see below) in a project named "Core" that holds some
 content and dynamically builds row-level-like permissions for each entry
 using a post_save and post_delete hook to manage it. Please don't judge me
 on the usage, it was the simplest solution at the time and the Zone model
 content changes infrequently.

 The issue I'm facing is when using the dynamic permissions in a template,
 

Re: [Django] #26057: Template {% if perms.app_label.permission %} check failing, but {% if 'app_label.permission' in perms %} works

[Django]

#26057: Template {% if perms.app_label.permission %} check failing, but {% if
'app_label.permission' in perms %} works
-+--
 Reporter:  McAnix   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  permissions  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by McAnix):

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


Old description:

> I'm encountering the issue above for dynamically generated permissions.
>
> I have a Zone model (see below) in a project named "Core" that holds some
> content and dynamically builds row-level-like permissions for each entry
> using a post_save and post_delete hook to manage it. Please don't judge
> me on the usage, it was the simplest solution at the time and the Zone
> model content changes infrequently.
>
> The issue I'm facing is when using the dynamic permissions in a template.
> I've tested the following in the template:
>
> {{{
> {% if 'core.can_view_myzone' in perms %}Check passes{% endif %} <- WORKS
> {% perms.core.can_view_myzone %}Check fails{% endif %} <- DOESN'T WORK
> }}}
>
> Also in the view:
>
> {{{
> print "CAN VIEW: %s" % request.user.has_perm('core.can_view_myzone') <-
> WORKS
> }}}
>
> Other permissions that are created via the permissions variable in the
> Meta class work fine '''BUT''' not if they're in the Zone model. I have
> checked migrations and the db tables for
> django_content_type/auth_permission and everything exists there and links
> correctly.
>
> Middleware as follows:
>
> {{{
> MIDDLEWARE_CLASSES = (
> 'django.middleware.common.CommonMiddleware',
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> 'django.contrib.messages.middleware.MessageMiddleware',
> )
> }}}
>
> Template Context Processors:
>
> {{{
> TEMPLATE_CONTEXT_PROCESSORS =
> ('django.contrib.auth.context_processors.auth',
> 'django.core.context_processors.debug',
> 'django.core.context_processors.i18n',
> 'django.core.context_processors.media',
> 'django.core.context_processors.static',
> 'django.contrib.messages.context_processors.messages',
> 'djutils.context_processors.settings_loader') # This just exposes
> selected settings to the templates
> }}}
>
> {{{
> class Zone(models.Model):
>   """A holder model for zone information as well as permission slips for
> each zone"""
>
>   class Meta:
> permissions = ()
>
>   cdate = models.DateTimeField(auto_now_add=True)
>   name = models.CharField(max_length=63)
>   url = models.CharField(max_length=255, verbose_name="Zone URL")
>   enabled = models.BooleanField()
>
>   def __unicode__(self):
> return "%s (Enabled: %s)" % (self.name, self.enabled)
>
> def create_zone_permission(sender, instance, created, raw, using,
> **kwargs):
>   """Creates a new zone permission entry for the new zone"""
>   content_type = ContentType.objects.get(app_label='core', model='zone')
>   codename = 'can_view_%s' % (instance.name, )
>   name='Can View %s' % (instance.name, )
>
>   if not Permission.objects.using(using).filter(codename=codename,
> content_type=content_type).exists():
> logger.info("Creating zone specific permissions for %s" % (codename,
> ))
> Permission.objects.using(using).create(codename=codename, name=name,
> content_type=content_type)
>

> def delete_zone_permission(sender, instance, using, **kwargs):
>   """Creates a new zone permission entry for the new zone"""
>   content_type = ContentType.objects.get(app_label='core', model='zone')
>   codename = 'can_view_%s' % (instance.name, )
>
>   if Permission.objects.using(using).filter(codename=codename,
> content_type=content_type).exists():
> logger.info("Deleting zone specific permissions for %s" % (codename,
> ))
> permission =
> Permission.objects.using(using).filter(codename=codename,
> content_type=content_type)
>
> permission.delete(using=using)
>
> post_save.connect(create_zone_permission, sender=Zone)
> post_delete.connect(delete_zone_permission, sender=Zone)
> }}}

New description:

 I'm encountering the issue above for dynamically generated permissions.

 I have a Zone model (see below) in a project named "Core" that holds some
 content and dynamically builds row-level-like permissions for each entry
 using a post_save and post_delete hook to manage it. Please don't judge me
 on the usage, it was the simplest solution at the time and the Zone model
 content changes infrequently.

 The issue I'm facing is

[Django] #26057: Template {% if perms.app_label.permission %} check failing, but {% if 'app_label.permission' in perms %} works

[Django]

#26057: Template {% if perms.app_label.permission %} check failing, but {% if
'app_label.permission' in perms %} works
-+-
 Reporter:  McAnix   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.8
 Severity:  Normal   |   Keywords:  permissions
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 I'm encountering the issue above for dynamically generated permissions.

 I have a Zone model (see below) in a project named "Core" that holds some
 content and dynamically builds row-level-like permissions for each entry
 using a post_save and post_delete hook to manage it. Please don't judge me
 on the usage, it was the simplest solution at the time and the Zone model
 content changes infrequently.

 The issue I'm facing is when using the dynamic permissions in a template.
 I've tested the following in the template:

 {{{
 {% if 'core.can_view_myzone' in perms %}Check passes{% endif %} <- WORKS
 {% perms.core.can_view_myzone %}Check fails{% endif %} <- DOESN'T WORK
 }}}

 Also in the view:

 {{{
 print "CAN VIEW: %s" % request.user.has_perm('core.can_view_myzone') <-
 WORKS
 }}}

 Other permissions that are created via the permissions variable in the
 Meta class work fine '''BUT''' not if they're in the Zone model. I have
 checked migrations and the db tables for
 django_content_type/auth_permission and everything exists there and links
 correctly.

 Middleware as follows:

 {{{
 MIDDLEWARE_CLASSES = (
 'django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 )
 }}}

 Template Context Processors:

 {{{
 TEMPLATE_CONTEXT_PROCESSORS =
 ('django.contrib.auth.context_processors.auth',
 'django.core.context_processors.debug',
 'django.core.context_processors.i18n',
 'django.core.context_processors.media',
 'django.core.context_processors.static',
 'django.contrib.messages.context_processors.messages',
 'djutils.context_processors.settings_loader') # This just exposes selected
 settings to the templates
 }}}

 {{{
 class Zone(models.Model):
   """A holder model for zone information as well as permission slips for
 each zone"""

   class Meta:
 permissions = ()

   cdate = models.DateTimeField(auto_now_add=True)
   name = models.CharField(max_length=63)
   url = models.CharField(max_length=255, verbose_name="Zone URL")
   enabled = models.BooleanField()

   def __unicode__(self):
 return "%s (Enabled: %s)" % (self.name, self.enabled)

 def create_zone_permission(sender, instance, created, raw, using,
 **kwargs):
   """Creates a new zone permission entry for the new zone"""
   content_type = ContentType.objects.get(app_label='core', model='zone')
   codename = 'can_view_%s' % (instance.name, )
   name='Can View %s' % (instance.name, )

   if not Permission.objects.using(using).filter(codename=codename,
 content_type=content_type).exists():
 logger.info("Creating zone specific permissions for %s" % (codename,
 ))
 Permission.objects.using(using).create(codename=codename, name=name,
 content_type=content_type)


 def delete_zone_permission(sender, instance, using, **kwargs):
   """Creates a new zone permission entry for the new zone"""
   content_type = ContentType.objects.get(app_label='core', model='zone')
   codename = 'can_view_%s' % (instance.name, )

   if Permission.objects.using(using).filter(codename=codename,
 content_type=content_type).exists():
 logger.info("Deleting zone specific permissions for %s" % (codename,
 ))
 permission = Permission.objects.using(using).filter(codename=codename,
 content_type=content_type)

 permission.delete(using=using)

 post_save.connect(create_zone_permission, sender=Zone)
 post_delete.connect(delete_zone_permission, sender=Zone)
 }}}

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

[Django] #26056: ArrayField does not work with ValueListQuerySet

[Django]

#26056: ArrayField does not work with ValueListQuerySet
--+-
 Reporter:  CGenie|  Owner:
 Type:  Bug   | Status:  new
Component:  contrib.postgres  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 Basically queries of type:

 {{{#!python
 A.objects.filter(array_field__overlap=B.objects.filter(foo))
 }}}

 fail at Python level:

 {{{
 Traceback (most recent call last):
   File "failing.py", line 9, in 
 UserList.objects.filter(users__overlap=User.objects.all().values_list('id',
 flat=True)).count()
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/query.py", line 318, in
 count
 return self.query.get_count(using=self.db)
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/query.py", line 466,
 in get_count
 number = obj.get_aggregation(using, ['__count'])['__count']
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/query.py", line 447,
 in get_aggregation
 result = compiler.execute_sql(SINGLE)
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
 829, in execute_sql
 sql, params = self.as_sql()
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
 387, in as_sql
 where, w_params = self.compile(self.query.where)
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
 357, in compile
 sql, params = node.as_sql(self, self.connection)
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/where.py", line 104,
 in as_sql
 sql, params = compiler.compile(child)
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/db/models/sql/compiler.py", line
 357, in compile
 sql, params = node.as_sql(self, self.connection)
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/contrib/postgres/fields/array.py",
 line 183, in as_sql
 sql, params = super(ArrayOverlap, self).as_sql(qn, connection)
   File "/home/przemek/.virtualenvs/italamo/lib/python2.7/site-
 packages/Django-1.8.5-py2.7.egg/django/contrib/postgres/lookups.py", line
 8, in as_sql
 params = lhs_params + rhs_params
 TypeError: can only concatenate list (not "tuple") to list
 }}}

 Toy project to reproduce this behavior can be found here:
 https://github.com/CGenie/django_array_join_fail

 This fails in 1.8 as well as in 1.9.

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