Re: [Django] #24823: FileField with callable default raise error with forms

[Django]

#24823: FileField with callable default raise error  with forms
-+-
 Reporter:  Haussonne Yves-  |Owner:  nobody
  Marie  |
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  FileField, models,   | Triage Stage:
  field, callable, default, form |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tai Lee):

 * cc: real.human@… (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/062.641810abed1c9c41cf559197b4d47e66%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24823: FileField with callable default raise error with forms

[Django]

#24823: FileField with callable default raise error  with forms
-+-
 Reporter:  Haussonne Yves-  |Owner:  nobody
  Marie  |
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  FileField, models,   | Triage Stage:
  field, callable, default, form |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tai Lee):

 * keywords:  FileField, models, field => FileField, models, field,
 callable, default, form


Comment:

 Plus, the fact that this actually does work as expected for `FileField`
 (models) is *only* broken with forms, makes the case stronger that this is
 a clear bug. The forms docs even say (of `Field.initial`):

 {{{
 Instead of a constant, you can also pass any callable
 }}}

 And when we stepped through form cleaning, we noticed that form data *did*
 contain a properly evaluated default as `initial-{fieldname}`, but the
 field cleaning ignored it and assigned the raw callable from the model
 instead.

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

Re: [Django] #24823: FileField with callable default raise error with forms

[Django]

#24823: FileField with callable default raise error  with forms
-+-
 Reporter:  Haussonne Yves-  |Owner:  nobody
  Marie  |
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  FileField, models,   | Triage Stage:
  field  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tai Lee):

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


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

Re: [Django] #24823: FileField with callable default raise error with forms

[Django]

#24823: FileField with callable default raise error  with forms
-+-
 Reporter:  Haussonne Yves-  |Owner:  nobody
  Marie  |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  FileField, models,   | Triage Stage:
  field  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tai Lee):

 Just spent a few hours stepping through tracebacks trying to find out
 exactly what Django is doing here, before coming to the conclusion that it
 must be a Django bug and searching for an existing ticket.

 Perhaps I haven't read the documentation recently or thoroughly enough,
 but they don't seem that ambiguous regarding the behaviour of `default`
 specifically:

 {{{
 The default value for the field. This can be a value or a callable object.
 If callable it will be called every time a new object is created.
 }}}

 There's no special caveat for `FileField` and `ImageField` saying that
 callables cannot be used.

 Whether or not additional special handling of the evaluated default value
 (as per discussion on #17224) is ever implemented, that should not make
 any difference at all as to whether or not a callable can be used as a
 default.

 I think this ticket should be re-opened, and can and should be resolved
 much quicker and simpler than #17224, without much debate?

 It's valid to assign a string to a `FileField` (on an instance, or as a
 default value). Is there any reason why a callable that returns a string
 shouldn't be valid?

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

Re: [Django] #24648: Model fields that reference settings that differ between dev and prod trigger the autodetector

[Django]

#24648: Model fields that reference settings that differ between dev and prod
trigger the autodetector
--+
 Reporter:  Christophe Pettus |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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 Tai Lee):

 We've encountered issues with migrations storing serialized settings at
 the time the migration was created. We've always fixed them in our
 projects and suggested to 3rd party projects that they simple edit the
 resulting migration to import and use the setting directly instead of its
 serialized value. No need for callables.

 I suppose something like `SettingsReference` might allow the auto
 migration to detect and properly reference the setting automatically, but
 it seems like an *extremely* easy mistake to forget to do this in advance
 and to end up with serialized migrations where the fix still requires
 manually editing the migration, at which point the use of
 `SettingsReference` is redundant.

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

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

Re: [Django] #28298: Alter field adds constaint on column db_constraint=False

[Django]

#28298: Alter field adds constaint on column db_constraint=False
---+
 Reporter:  Josh Schneier  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"fba0eaa5d60603721d7b4653e3efacbfb3613bd2" fba0eaa5]:
 {{{
 #!CommitTicketReference repository=""
 revision="fba0eaa5d60603721d7b4653e3efacbfb3613bd2"
 Fixed #28298 -- Prevented a primary key alteration from adding a foreign
 key constraint if db_constraint=False.
 }}}

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

Re: [Django] #28298: Alter field adds constaint on column db_constraint=False

[Django]

#28298: Alter field adds constaint on column db_constraint=False
---+
 Reporter:  Josh Schneier  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"7765d3ba9b02d612f7c466f5ca0ea8fba1405372" 7765d3b]:
 {{{
 #!CommitTicketReference repository=""
 revision="7765d3ba9b02d612f7c466f5ca0ea8fba1405372"
 [1.11.x] Fixed #28298 -- Prevented a primary key alteration from adding a
 foreign key constraint if db_constraint=False.

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

Re: [Django] #21961: Add support for database-level cascading options

[Django]

#21961: Add support for database-level cascading options
-+-
 Reporter:  Christophe Pettus|Owner:  Nick
 |  Stefan
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Nick Stefan):

 postgresql and mysql are fine. However, for SQLite to use ON DELETE, we
 would need a new OPTIONS flag. Something like:

 {{{
 settings.DATABASES.["default"]["OPTIONS"]["PRAGMA_foreign_keys"] = True
 }}}


 (which would then lead to the database wrapper running the correct SQL:
 https://sqlite.org/foreignkeys.html#fk_enable)

 If I add the pragma flag, the test suite fails quite a few tests (50+).
 Therefore, SQLite PRAGMA foreign keys, seems to be a bigger and separate
 scope. It does have its own ticket here
 https://code.djangoproject.com/ticket/14204. So postgresql and mysql are
 it, for now.

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

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

Re: [Django] #28201: Make CharField/TextField prohibit null characters

[Django]

#28201: Make CharField/TextField prohibit null characters
-+-
 Reporter:  CM Lubinski  |Owner:  Alejandro
 Type:   |  Zamora Fonseca
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  1.11
 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 Alejandro Zamora Fonseca):

 Added default null characters validation to CharField and TextField in
 order to avoid raising errors on database layer. Added test for both
 fields. Tested on PostgreSQL, MySQL, and SQLite backends.

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

Re: [Django] #26818: Make the Django admin CSS responsive

[Django]

#26818: Make the Django admin CSS responsive
---+
 Reporter:  Henrique Chehad|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin, responsive  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  1
---+
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #28298: Alter field adds constaint on column db_constraint=False

[Django]

#28298: Alter field adds constaint on column db_constraint=False
---+
 Reporter:  Josh Schneier  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham):

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

Re: [Django] #25375: Paginator generates suboptimal queries

[Django]

#25375: Paginator generates suboptimal queries
-+-
 Reporter:  Alexandru|Owner:  nobody
  Mărășteanu |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Stefan Wehrmeyer):

 The Paginator needs to make two queries: the count query and the query for
 the page objects.

 If the queryset you use in your Paginator satisfies
 
[https://github.com/django/django/blob/0af14b2eaa0bf0821a8aacc8486489a1eb348397/django/db/models/sql/query.py#L412-L413
 one of these conditions] the count query will run as a subquery, so this
 query:

 {{{
 SELECT COUNT(*) FROM (SELECT ...);
 }}}

 instead of
 {{{
 SELECT COUNT(*) AS "__count" FROM ...;
 }}}

 In my case the first query takes double the amount of time of the second
 query.

 The row count can be independent of annotations. So if you make the
 Paginator do the count query on a queryset without annotations (resulting
 in a more performant count query) and then doing the actual pagination
 with the annotated queryset may result in a small performance win.

 Annotations can influence row count (e.g. when filtering by annotation)
 and you still may have `groupby()` or `distinct()` on your queryset that
 influences counts and forces a count with a subquery. So I'm not sure if
 there's a general way for the Paginator (or any `.count()` call) to run
 the more performant query.

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

Re: [Django] #16870: CSRF too strict when no referer is present

[Django]

#16870: CSRF too strict when no referer is present
+--
 Reporter:  rtux|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  CSRF|  Version:  master
 Severity:  Normal  |   Resolution:  wontfix
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Tim Graham ):

 In [changeset:"0af14b2eaa0bf0821a8aacc8486489a1eb348397" 0af14b2]:
 {{{
 #!CommitTicketReference repository=""
 revision="0af14b2eaa0bf0821a8aacc8486489a1eb348397"
 Refs #16870 -- Doc'd that CSRF protection requires the Referer header.
 }}}

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

Re: [Django] #27833: prefetch_related fails with SQLite when used with 1000 parent records

[Django]

#27833: prefetch_related fails with SQLite when used with 1000 parent records
-+-
 Reporter:  Jason Barnabe|Owner:  Raphael
 |  Michel
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #28201: Make CharField/TextField prohibit null characters

[Django]

#28201: Make CharField/TextField prohibit null characters
-+-
 Reporter:  CM Lubinski  |Owner:  Alejandro
 Type:   |  Zamora Fonseca
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  1.11
 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 Alejandro Zamora Fonseca):

 * owner:  (none) => Alejandro Zamora Fonseca
 * status:  new => assigned


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

Re: [Django] #17697: Implement a new property as list type (like extra_argument) into the ListView class

[Django]

#17697: Implement a new property as list type (like extra_argument) into the
ListView class
-+-
 Reporter:  sylock   |Owner:  Adrien
 |  Lemaire
 Type:  New feature  |   Status:  closed
Component:  Generic views|  Version:  1.3
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  extra_context| Triage Stage:  Design
  generic views listview |  decision needed
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 I accepted a ticket for this in #28331.

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

Re: [Django] #28331: Add an extra_context attribute to class-based generic views that use ContextMixin (e.g. TemplateView) (was: extra_context argument on TemplateView.as_view)

[Django]

#28331: Add an extra_context attribute to class-based generic views that use
ContextMixin (e.g. TemplateView)
--+
 Reporter:  Jeremy|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Generic views |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Generic views
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 This was also suggested in #17697 but the ticket triagers didn't
 understand the suggestion. The suggestion seems okay to me. I think it
 would involve modifying
 
[https://github.com/django/django/blob/8cb1b1fd8e529d1896daeb089ea726109e0ba4f7/django/views/generic/base.py#L22-L25
 ContextMixin.get_context_data()].

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

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

Re: [Django] #28332: Diamond multiple inheritance example in docs gives a clashing field check error (was: Cannot get diamond multiple inheritance example to work)

[Django]

#28332: Diamond multiple inheritance example in docs gives a clashing field 
check
error
---+
 Reporter:  Luc Saffre |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.11
 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 Tim Graham):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 It looks like the example in the documentation (added in #22442) never
 worked. I tested back to Django 1.7 and the check error is the same. If it
 cannot be fixed, perhaps it should be removed.

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

Re: [Django] #26223: Squashing migrations with preserve_default=False keeps the default

[Django]

#26223: Squashing migrations with preserve_default=False keeps the default
-+-
 Reporter:  Bartek Wójcicki  |Owner:  Vytis
 |  Banaitis
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

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