[Django] #27048: Clear cached_property on refresh_from_db

[Django]

#27048: Clear cached_property on refresh_from_db
-+-
 Reporter:  jarekwg  |  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |Version:  master
 Severity:  Normal   |   Keywords:  cached_property
 |  refresh_from_db
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Should `cached_property`-decorated stuff get wiped when we call
 `.refresh_from_db()`?

 I found [https://medium.com/@fdemmer/django-cached-property-on-models-
 f4673de33990#.vc5atqt0n this related article] on the matter.

 From a usage perspective, it seems like we wouldn't ever want cached
 properties to persist through a `refresh_from_db()` call, as ideally we'd
 like to think `mymodel.refresh_from_db()` is shorthand synonymous to
 `mymodel = MyModel.objects.get(pk=mymodel.pk)`.

 However, from an implementation perspective, maybe this would result in a
 rabbit hole that tries to pull through other stuff, like #26514.

 Basically this ticket picks at:
Note that only fields of the model are reloaded from the database.
 Other database dependent values such as annotations are not reloaded.`

 I have a feeling this might be a conscious design decision, but in case it
 isn't, 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/050.7afd3e0cdcb3685d62100195a21fe520%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18682: Make the deletion of stale content types safer

[Django]

#18682: Make the deletion of stale content types safer
-+-
 Reporter:  aaugustin|Owner:  Florian
 Type:   |  Apolloner 
  Cleanup/optimization   |   Status:  closed
Component:   |  Version:  1.3
  contrib.contenttypes   |
 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:"e2dfa81ff7489d97700604d634adacf1384af184" e2dfa81f]:
 {{{
 #!CommitTicketReference repository=""
 revision="e2dfa81ff7489d97700604d634adacf1384af184"
 Refs #18682 -- Edited explanation in stale content type deletion.

 Follow up to 8db889eaf7dce0cb715b075be32047c1b1b316da.
 }}}

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

Re: [Django] #26947: Support appending the 'preload' directive to the HSTS header

[Django]

#26947: Support appending the 'preload' directive to the HSTS header
---+
 Reporter:  edmorley   |Owner:  edmorley
 Type:  New feature|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords:  hsts preload   | 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:"7399fee6c3bb7eded1ecf5855d71520db299d79d" 7399fee6]:
 {{{
 #!CommitTicketReference repository=""
 revision="7399fee6c3bb7eded1ecf5855d71520db299d79d"
 Refs #26947 -- Added a deployment system check for SECURE_HSTS_PRELOAD.
 }}}

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

Re: [Django] #26947: Support appending the 'preload' directive to the HSTS header

[Django]

#26947: Support appending the 'preload' directive to the HSTS header
---+
 Reporter:  edmorley   |Owner:  edmorley
 Type:  New feature|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords:  hsts preload   | 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:"3c2447dd13e495d57700ca8447896acd8504" 3c2447dd]:
 {{{
 #!CommitTicketReference repository=""
 revision="3c2447dd13e495d57700ca8447896acd8504"
 Fixed #26947 -- Added an option to enable the HSTS header preload
 directive.
 }}}

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

Re: [Django] #26957: Inconsistency between doc and code: authenticate() when user.is_active == False

[Django]

#26957: Inconsistency between doc and code: authenticate() when user.is_active 
==
False
--+
 Reporter:  ericls|Owner:  an0o0nym
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.auth  |  Version:  1.10
 Severity:  Normal|   Resolution:  fixed
 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 ):

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


Comment:

 In [changeset:"c52350bc6c0ce4e146db696d3a9772b6b9dc554f" c52350b]:
 {{{
 #!CommitTicketReference repository=""
 revision="c52350bc6c0ce4e146db696d3a9772b6b9dc554f"
 [1.10.x] Fixed #26957 -- Corrected authenticate() docs regarding
 User.is_active.

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

Re: [Django] #26957: Inconsistency between doc and code: authenticate() when user.is_active == False

[Django]

#26957: Inconsistency between doc and code: authenticate() when user.is_active 
==
False
--+
 Reporter:  ericls|Owner:  an0o0nym
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.auth  |  Version:  1.10
 Severity:  Normal|   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"c412aaca735c7cc1c766b85c1512f9ff434ce63a" c412aac]:
 {{{
 #!CommitTicketReference repository=""
 revision="c412aaca735c7cc1c766b85c1512f9ff434ce63a"
 Fixed #26957 -- Corrected authenticate() docs regarding User.is_active.
 }}}

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

Re: [Django] #27047: Popup inlines

[Django]

#27047: Popup inlines
---+--
 Reporter:  olivierdalang  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  master
 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
---+--
Changes (by timgraham):

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


Comment:

 Thanks for the idea, but it would be better to make a proposal like this
 on the DevelopersMailingList as that's where larger design decisions like
 this happen. I think a proof of concept would likely be needed to give a
 better idea of what's involved before we could accept a ticket. I'm also
 interested to see if this could be (at least initially) implemented as a
 third-party app. That would help gauge whether it's popular enough to
 justify including it in Django itself. 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/071.19139cdf1d315f628dba33d4d85c3ac1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27047: Popup inlines

[Django]

#27047: Popup inlines
---+
 Reporter:  olivierdalang  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hi,

 Currently, Django has StackedInline and TabularInline.

 TabularInlines work very well if you have many related models with few and
 simple fields.
 StackedInlies work very well if you have few related models with more and
 bigger fields.

 But when you have related models with a lot of required fields, and you
 have a lot of relations, those two UI are not practical.

 What about adding a third Inline subclass, which could be called
 "PopupInline".

 It would look much like the tabular inline, but all the fields would be
 readonly, and adding and editing relations would happen in a popup.

 I guess we could reuse some code used for RelatedWidgets, where the same
 thing happen : you can edit a relation in a popup, and when you finish,
 you're back to the main form, which is dynamically updated.

 I think it would be quite consistent with the rest of django admin, both
 in terms of user experience and in terms of code logic.
 It also replace nested inlines in some cases (which aren't supported yet,
 and are probably much more complex to implement).

 Let me know what you think !

 Olivier

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

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

[Django]

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+
 Reporter:  stevejalim |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  sqlite nose| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by jasonm):

 I also see this issue (Django 1.9.9, OSX, Python 2.7.11) and confirm that
 updating from OSX built-in sqlite3 3.8.5 to homebrew sqlite3 3.14.0 fixes
 this issue, as well as fixes the sqlite repro case detailed in
 https://www.sqlite.org/src/info/7f7f8026eda38

 My shell notes:
 https://gist.github.com/jasonm/5aa9406c88e29e3d550c1b42f9435cf2

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

Re: [Django] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
---+
 Reporter:  pixelcort  |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  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:  1
---+
Changes (by olivierdalang):

 * cc: olivier.dalang@… (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/067.ed10e0856ddeb9f9d9fa9cde09033654%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27044: `apps` passed to post_migrate_signal should contain migrated appconfigs even when no migration has been applied to them

[Django]

#27044: `apps` passed to post_migrate_signal should contain migrated appconfigs
even when no migration has been applied to them
-+
 Reporter:  tkhyn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.10
 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):

 Thanks for the follow  up @tkhyn,

 In this case I suspect the bug lies `MigrationExecutor`, it might be
 related to #26647.

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

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

Re: [Django] #27044: `apps` passed to post_migrate_signal should contain migrated appconfigs even when no migration has been applied to them

[Django]

#27044: `apps` passed to post_migrate_signal should contain migrated appconfigs
even when no migration has been applied to them
-+
 Reporter:  tkhyn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.10
 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 tkhyn):

 Thanks @charettes.

 > The fact applications with no migrations are present in `apps` on the
 first `migrate` run but not on subsequent ones look like a bug to me.

 Note that on subsequent runs it's not `app`'config that is missing in the
 `pre_migrate_apps` ' app configs, but actually `contenttypes`'config.

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

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

Re: [Django] #27044: `apps` passed to post_migrate_signal should contain migrated appconfigs even when no migration has been applied to them

[Django]

#27044: `apps` passed to post_migrate_signal should contain migrated appconfigs
even when no migration has been applied to them
-+
 Reporter:  tkhyn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.10
 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 charettes):

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


Comment:

 Hi tkhyn,

 I can't look at this in details in the next few days but
 `update_contenttypes` should definitively be running for applications
 without migrations.

 The fact applications with no migrations are present in `apps` on the
 first `migrate` run but not on subsequent ones look like a bug to me.

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

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

Re: [Django] #21278: Using dumpdata to create unit test fixtures causes duplicate foreign keys for auth permissions. Excluding auth causes other referenced auth models to be missing.

[Django]

#21278: Using dumpdata to create unit test fixtures causes duplicate foreign 
keys
for auth permissions.  Excluding auth causes other referenced auth models
to be missing.
--+
 Reporter:  ellisd23@…|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.5
 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 powderflask):

 Here is a KEY insight that seems obvious now, but busted my *** for a
 couple hours:

 if your models contain an M2M relation (e.g., auth.Group,
 auth.Permission), do NOT dump the M2M table (e.g., auth.group_permissions)
 into your test fixture! Otherwise, the M2M table will be populated once
 when the related objects are created, and then AGAIN when the M2M data is
 loaded from the fixture, thus causing an integrity error like the one
 reported here.

 This mistake is SO easy to make and SUCH a bugger to track down, it might
 be worth a word of warning in the docs about creating test fixtures?

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

Re: [Django] #27044: `apps` passed to post_migrate_signal should contain migrated appconfigs even when no migration has been applied to them

[Django]

#27044: `apps` passed to post_migrate_signal should contain migrated appconfigs
even when no migration has been applied to them
+--
 Reporter:  tkhyn   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by tkhyn):

 I should have added that using `migrate --run-syncdb` does not change the
 outcome (which can be expected when looking at the `migrate` management
 command implementation as it has no influence on the apps instance that is
 passed to the `post_migrate` signal)

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

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

Re: [Django] #27044: `apps` passed to post_migrate_signal should contain migrated appconfigs even when no migration has been applied to them

[Django]

#27044: `apps` passed to post_migrate_signal should contain migrated appconfigs
even when no migration has been applied to them
+--
 Reporter:  tkhyn   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by tkhyn):

 Thanks for the reply,

 You could try and run the test suite for the app (I haven't pushed the
 changes to fix all the Django 2.0 warnings though so the suite will fail),
 or more simply use a minimal project in an environment with Django 1.10
 installed:

 {{{
 hg clone https://bitbucket.org/tkhyn/dj10_syncdb
 cd dj10_syncdb
 hg update a7614832e38a7f8f21cf474dc328c295a9d8fc3c
 }}}

 In this state, the sample project has one unmigrated app `app` with one
 model `MyModel`. Lets migrate.

 {{{
 manage.py migrate
 }}}

 The django_content_type table now looks like:

 || id || app_label || model ||
 || 1 || admin || logentry ||
 || 2 || auth || permission ||
 || 3 || auth || user ||
 || 4 || auth || group ||
 || 5 || contenttypes || contenttype ||
 || 6 || sessions || session ||
 || 7 || app || mymodel ||

 ... and everything is ok so far. Let's add a new model to our unmigrated
 app.

 {{{
 hg update dfd8067076c1ceb7d9a1ae48ddc27c0dfd64044c
 manage.py migrate
 }}}

 The django_content_type table has not changed. There should be a new line
 in django_content_type (app_label = app and model = mysecondmodel), and
 it's not there because the ``update_contenttypes`` cannot proceed further
 than line 102 when `migrate` is called a second time.

 A possible solution would be to transform `app` into a migrated app (I
 haven't checked it though), but given that it worked ok in django 1.9.9 I
 see this as a regression.

 Feel free to let me know if you require additional info on 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/063.f8de8917ee2cdd682a2881b5cbd61506%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27044: `apps` passed to post_migrate_signal should contain migrated appconfigs even when no migration has been applied to them

[Django]

#27044: `apps` passed to post_migrate_signal should contain migrated appconfigs
even when no migration has been applied to them
+--
 Reporter:  tkhyn   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.10
 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 charettes):

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

Re: [Django] #27019: DiscoverRunner does not restore old settings.DEBUG value in teardown

[Django]

#27019: DiscoverRunner does not restore old settings.DEBUG value in teardown
-+-
 Reporter:  cjerdonek|Owner:  cjerdonek
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"7f9fd42b9316e4beddb690bae61940e940281805" 7f9fd42]:
 {{{
 #!CommitTicketReference repository=""
 revision="7f9fd42b9316e4beddb690bae61940e940281805"
 Fixed #27019 -- Made teardown_test_environment() restore the old DEBUG.
 }}}

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

Re: [Django] #26957: Inconsistency between doc and code: authenticate() when user.is_active == False

[Django]

#26957: Inconsistency between doc and code: authenticate() when user.is_active 
==
False
--+
 Reporter:  ericls|Owner:  an0o0nym
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.auth  |  Version:  1.10
 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 an0o0nym):

 Pull request created at [https://github.com/django/django/pull/7059].

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

Re: [Django] #27045: Document that AUTH_PASSWORD_VALIDATORS doesn't apply to create_user() and create_superuser()

[Django]

#27045: Document that AUTH_PASSWORD_VALIDATORS doesn't apply to create_user() 
and
create_superuser()
-+-
 Reporter:  chris-griffin|Owner:  timgraham
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  AUTH_PASSWORD_VALIDATORS   |  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:"3fff7d3abb295a7622fa6f4ab6ca6719b48beb9a" 3fff7d3a]:
 {{{
 #!CommitTicketReference repository=""
 revision="3fff7d3abb295a7622fa6f4ab6ca6719b48beb9a"
 [1.10.x] Fixed #27045 -- Documented that AUTH_PASSWORD_VALIDATORS aren't
 applied at the model level.

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

Re: [Django] #27045: Document that AUTH_PASSWORD_VALIDATORS doesn't apply to create_user() and create_superuser()

[Django]

#27045: Document that AUTH_PASSWORD_VALIDATORS doesn't apply to create_user() 
and
create_superuser()
-+-
 Reporter:  chris-griffin|Owner:  timgraham
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  AUTH_PASSWORD_VALIDATORS   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"796cc620269bcefa36e7bbf5f1a63855f00b8ea8" 796cc62]:
 {{{
 #!CommitTicketReference repository=""
 revision="796cc620269bcefa36e7bbf5f1a63855f00b8ea8"
 Fixed #27045 -- Documented that AUTH_PASSWORD_VALIDATORS aren't applied at
 the model level.
 }}}

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

Re: [Django] #25809: PostgreSQL 9.5 BRIN Index support in contrib.postgres

[Django]

#25809: PostgreSQL 9.5 BRIN Index support in contrib.postgres
--+
 Reporter:  auvipy|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
--+

Comment (by auvipy):

 Replying to [comment:4 timgraham]:
 > This can likely move forward now that the framework for class-based
 indexes is in master.

 exactly. will this be part of gsoc?

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

Re: [Django] #27046: http.request does not support ipv6-formatted ipv4 addresses

[Django]

#27046: http.request does not support ipv6-formatted ipv4 addresses
---+
 Reporter:  lfaraone   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  HTTP handling  |Version:  1.9
 Severity:  Normal | Resolution:
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by lfaraone):

 * Attachment "0001-Add-support-for-IPv6-formatted-IPv4-addresses.patch"
 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/066.b5dcc76c3afe61efb280d63d78225adc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27046: http.request does not support ipv6-formatted ipv4 addresses

[Django]

#27046: http.request does not support ipv6-formatted ipv4 addresses
---+
 Reporter:  lfaraone   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  HTTP handling  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 Forwarded from [https://bugs.launchpad.net/ubuntu/+source/python-
 django/+bug/1611923 LP: #1611923] reported by LaMont Jones

 Addresses of the form ":::169.254.169.254" are perfectly valid, but
 not supported by django's http.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/051.fce3cda690b57f7a6a48c2703271ca60%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27045: Document that AUTH_PASSWORD_VALIDATORS doesn't apply to create_user() and create_superuser()

[Django]

#27045: Document that AUTH_PASSWORD_VALIDATORS doesn't apply to create_user() 
and
create_superuser()
-+-
 Reporter:  chris-griffin|Owner:  timgraham
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  AUTH_PASSWORD_VALIDATORS   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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

Re: [Django] #27039: ModelFields with 'default' value set and 'required'=False in form does not use default value

[Django]

#27039: ModelFields with 'default' value set and 'required'=False in form does 
not
use default value
-+-
 Reporter:  devbis   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  default non- | Triage Stage:  Accepted
  required modelform |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 No, IMHO `{'f': ''}` should really end up with the field being assigned
 the empty string, if possible. Quoting (and agreeing with) you: `if a user
 removes that value and submits a blank form, Django shouldn't transform it
 back to the default`.

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

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

Re: [Django] #26903: support date and timestamp containment within postgres range field

[Django]

#26903: support date and timestamp containment within postgres range field
--+
 Reporter:  ar45  |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  rangefield| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Simon suggests adding tests with timezone aware values.

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

Re: [Django] #26909: Allow UserAttributeSimilarityValidator to validate against properties

[Django]

#26909: Allow UserAttributeSimilarityValidator to validate against properties
-+-
 Reporter:  kierenpitts  |Owner:
 Type:   |  andrewnester
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"4591cf3fd88fb13325ffce91279eae38e38c61cb" 4591cf3]:
 {{{
 #!CommitTicketReference repository=""
 revision="4591cf3fd88fb13325ffce91279eae38e38c61cb"
 Fixed #26909 -- Allowed UserAttributeSimilarityValidator to validate
 against model properties.
 }}}

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

Re: [Django] #25809: PostgreSQL 9.5 BRIN Index support in contrib.postgres

[Django]

#25809: PostgreSQL 9.5 BRIN Index support in contrib.postgres
--+
 Reporter:  auvipy|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 timgraham):

 * stage:  Someday/Maybe => Accepted


Comment:

 This can likely move forward now that the framework for class-based
 indexes is in 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.71a1a7d16d7abd8f8fb0ac0bdb540734%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26993: Increase the length of the User model's last_name field to 100 characters (was: Increase the length of the User model's last_name field to allow more of the world to use it)

[Django]

#26993: Increase the length of the User model's last_name field to 100 
characters
--+
 Reporter:  mbox  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  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 timgraham):

 * stage:  Someday/Maybe => Accepted


Comment:

 Consensus on the mailing list suggests that 100 characters is sufficient.

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

Re: [Django] #26982: Allow easy removal of "novalidate" in admin

[Django]

#26982: Allow easy removal of "novalidate" in admin
---+-
 Reporter:  nrogers64  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Someday/Maybe
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by timgraham):

 * type:  Uncategorized => New feature
 * component:  Uncategorized => contrib.admin
 * stage:  Unreviewed => Someday/Maybe


Comment:

 Bumping to Someday/Maybe pending the answer to the above question and a
 use case for removing `novalidate` if the concerns are indeed still valid.
 It would likely be appropriate to raise this on the DevelopersMailingList
 for discussion.

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

Re: [Django] #27008: Add manage.py test --debug option

[Django]

#27008: Add manage.py test --debug option
---+-
 Reporter:  cjerdonek  |Owner:  cjerdonek
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  1.10
 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 cjerdonek):

 * has_patch:  0 => 1


Comment:

 I added a pull request for this
 [https://github.com/django/django/pull/7060 here].

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

Re: [Django] #26844: Formset's validate_min doesn't work correctly with empty forms

[Django]

#26844: Formset's validate_min doesn't work correctly with empty forms
---+-
 Reporter:  wimfeijen  |Owner:  mpatibandla
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Ready for checkin
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f5c6295797b8332134fd89e0209a18a1d1d45e0c" f5c6295]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5c6295797b8332134fd89e0209a18a1d1d45e0c"
 Fixed #26844 -- Made formset's validate_min validation ignore empty forms.
 }}}

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

Re: [Django] #26844: Formset's validate_min doesn't work correctly with empty forms (was: Formset's validate_min doesn't work correctly with deleted forms)

[Django]

#26844: Formset's validate_min doesn't work correctly with empty forms
---+-
 Reporter:  wimfeijen  |Owner:  mpatibandla
 Type:  Bug|   Status:  assigned
Component:  Forms  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Ready for checkin
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


Comment:

 The issue here turns out to be empty forms be included in the form count.

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

Re: [Django] #27044: `apps` passed to post_migrate_signal should contain migrated appconfigs even when no migration has been applied to them

[Django]

#27044: `apps` passed to post_migrate_signal should contain migrated appconfigs
even when no migration has been applied to them
+--
 Reporter:  tkhyn   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.10
 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
+--

Old description:

> Hi,
>
> I noticed that when one runs `migrate` without arguments (implicitly
> migrating all apps), the `apps` instance passed to
> `emit_post_migrate_signal`
> (https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L221
> [here]) contains the migrated apps' configurations only in the first run.
>
> On subsequent runs, the `plan` list
> ([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L136
> here]) is empty and `post_migrate_apps` is set to `pre_migrate_apps`
> ([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L197
> here]), i.e. the unmigrated apps.
>
> For example, when calling `migrate` with the `contenttypes` app enabled,
> this means that after the first run `update_contenttypes`
> ([https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L89
> here]) is passed an `apps` instance with `contenttypes` missing. The
> consequence is that `update_contenttypes` can not go further than
> [https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L102
> this line].
>
> To temporarily fix the issue and correctly trigger the
> `post_migrate_signal` so that the content types are properly updated each
> time `migrate` is called (and not only the first time), I need to run
> `flush` just after `migrate`. I don't think it should not be needed to
> run `flush` simply to correctly trigger the `post_migrate_signal` that
> will update the content types.
>
> It worked fine in Django 1.9.9 as no project state apps instance is
> passed to `emit_post_migrate_signal`, and `update_contenttypes` uses the
> global `apps` instance.
>
> I don't really know enough about the recent developments regarding apps
> management in Django, so I'm not sure what should be done to solve this
> issue. Thanks in advance if somebody has the time to look at it.
>
> ''Context: I'm testing a reusable django app
> ([https://bitbucket.org/tkhyn/django-gm2m django-gm2m]) which test suite
> includes migration tests for a number of mini test apps with different
> models (see [https://bitbucket.org/tkhyn/django-
> gm2m/src/63af327624a45c5aed110546d3d705a6b1bf7c2b/tests/?at=release
> here]). Whenever I switch to another mini-app, the database needs not
> only to be flushed but also re-migrated and the contenttypes need to be
> updated !''

New description:

 Hi,

 I noticed that when one runs `migrate` without arguments (implicitly
 migrating all apps), the `apps` instance passed to
 `emit_post_migrate_signal`
 
[https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L221
 here]) contains the migrated apps' configurations only in the first run.

 On subsequent runs, the `plan` list
 
([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L136
 here]) is empty and `post_migrate_apps` is set to `pre_migrate_apps`
 
([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L197
 here]), i.e. the unmigrated apps.

 For example, when calling `migrate` with the `contenttypes` app enabled,
 this means that after the first run `update_contenttypes`
 
([https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L89
 here]) is passed an `apps` instance with `contenttypes` missing. The
 consequence is that `update_contenttypes` can not go further than
 
[https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L102
 this line].

 To temporarily fix the issue and correctly trigger the
 `post_migrate_signal` so that the content types are properly updated each
 time `migrate` is called (and not only the first time), I need to run
 `flush` just after `migrate`. I don't think it should not be needed to run
 `flush` simply to correctly trigger the `post_migrate_signal` that will
 update the content types.

 It worked fine in Django 1.9.9 as no project state apps instance is passed
 to `emit_post_migrate_signal`, and `update_contenttypes` uses the global
 `apps` instance.

 I don't really know enough about the recent developments regarding apps
 management in Django, so I'm not sure what should be done to 

Re: [Django] #26909: Allow UserAttributeSimilarityValidator to validate against properties (was: UserAttributeSimilarityValidator has hardcoded reference to 'username' causing error in password reset

[Django]

#26909: Allow UserAttributeSimilarityValidator to validate against properties
-+-
 Reporter:  kierenpitts  |Owner:
 Type:   |  andrewnester
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  1.9
 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 timgraham):

 * needs_better_patch:  0 => 1
 * type:  Bug => Cleanup/optimization


Comment:

 Left some comments for improvement on the 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/069.090c9bca503df5d6a864c9704f262352%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26098: Support Geodjango admin widgets on SSL

[Django]

#26098: Support Geodjango admin widgets on SSL
-+
 Reporter:  fmalina  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  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 timgraham):

 * needs_better_patch:  0 => 1
 * stage:  Someday/Maybe => Accepted


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

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

Re: [Django] #27045: Document that AUTH_PASSWORD_VALIDATORS doesn't apply to create_user() and create_superuser() (was: create_user and create_superuser do not enforce AUTH_PASSWORD_VALIDATORS)

[Django]

#27045: Document that AUTH_PASSWORD_VALIDATORS doesn't apply to create_user() 
and
create_superuser()
-+-
 Reporter:  chris-griffin|Owner:  timgraham
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  AUTH_PASSWORD_VALIDATORS   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * component:  Core (Management commands) => Documentation
 * needs_tests:   => 0
 * owner:  nobody => timgraham
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Old description:

> According to this [https://groups.google.com/forum/#!searchin/django-
> users/AUTH_PASSWORD_VALIDATORS$20create_user%7Csort:relevance/django-
> users/3nL4cImH1Ls/JPVdlUX9CAAJ thread], the create_user method does not
> enforce the password validators which I ran into while trying to unittest
> my validation settings. This seems quite dangerous especially since most
> validation in django is normally on the model level and many developers
> like myself may assume these management commands would enforce these
> settings.

New description:

 According to this [https://groups.google.com/forum/#!searchin/django-
 users/AUTH_PASSWORD_VALIDATORS$20create_user%7Csort:relevance/django-
 users/3nL4cImH1Ls/JPVdlUX9CAAJ thread], the `create_user()` method does
 not enforce the password validators which I ran into while trying to
 unittest my validation settings. This seems quite dangerous especially
 since most validation in django is normally on the model level and many
 developers like myself may assume these methods would enforce these
 settings.

--

Comment:

 Here's a documentation [https://github.com/django/django/pull/7057 PR] to
 clarify the design decision about 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/071.462f53eb93aa3b5e710879d6d440783e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26973: i18n template tag loading error when setting show_indexes=True for views.static.serve

[Django]

#26973: i18n template tag loading error when setting show_indexes=True for
views.static.serve
--+
 Reporter:  MikiSoft  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  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 Tim Graham ):

 In [changeset:"025498531714d4c3c82724493754f7b2b4ca329a" 02549853]:
 {{{
 #!CommitTicketReference repository=""
 revision="025498531714d4c3c82724493754f7b2b4ca329a"
 [1.10.x] Fixed #26973 -- Fixed views.static.serve() crash with
 show_indexes enabled.

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

Re: [Django] #26973: i18n template tag loading error when setting show_indexes=True for views.static.serve

[Django]

#26973: i18n template tag loading error when setting show_indexes=True for
views.static.serve
--+
 Reporter:  MikiSoft  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  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 GitHub ):

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


Comment:

 In [changeset:"1e32e1cc951ac9bada52aa20a9523acc7cc6ecb3" 1e32e1c]:
 {{{
 #!CommitTicketReference repository=""
 revision="1e32e1cc951ac9bada52aa20a9523acc7cc6ecb3"
 Fixed #26973 -- Fixed views.static.serve() crash with show_indexes
 enabled.
 }}}

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

Re: [Django] #25931: ContentTypes population doesn't work with backwards migrations

[Django]

#25931: ContentTypes population doesn't work with backwards migrations
--+
 Reporter:  amosonn   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.contenttypes  |  Version:  1.9
 Severity:  Normal|   Resolution:  fixed
 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):

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


Comment:

 I believe this is fixed in Django 1.10 due to #24075. After `./manage.py
 migrate myapp 0001 # backwards` in bug1, you'll now get a prompt to delete
 stale content types. In bug 2, at `./print_cts.py # note that CT of First
 is missing.` - CT of first is no longer missing.

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

Re: [Django] #26098: Support Geodjango admin widgets on SSL

[Django]

#26098: Support Geodjango admin widgets on SSL
-+-
 Reporter:  fmalina  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by blueyed):

 * has_patch:  0 => 1


Comment:

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

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

[Django] #27045: create_user and create_superuser do not enforce AUTH_PASSWORD_VALIDATORS

[Django]

#27045: create_user and create_superuser do not enforce AUTH_PASSWORD_VALIDATORS
-+-
 Reporter:  chris-griffin|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Management |Version:  1.9
  commands)  |   Keywords:
 Severity:  Normal   |  AUTH_PASSWORD_VALIDATORS
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 According to this [https://groups.google.com/forum/#!searchin/django-
 users/AUTH_PASSWORD_VALIDATORS$20create_user%7Csort:relevance/django-
 users/3nL4cImH1Ls/JPVdlUX9CAAJ thread], the create_user method does not
 enforce the password validators which I ran into while trying to unittest
 my validation settings. This seems quite dangerous especially since most
 validation in django is normally on the model level and many developers
 like myself may assume these management commands would enforce these
 settings.

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

Re: [Django] #26960: Allow user login after password reset

[Django]

#26960: Allow user login after password reset
--+
 Reporter:  jordij|Owner:  jordij
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  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 Tim Graham ):

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


Comment:

 In [changeset:"0814566bf1212c9d63982a7107693108b73394df" 0814566b]:
 {{{
 #!CommitTicketReference repository=""
 revision="0814566bf1212c9d63982a7107693108b73394df"
 Fixed #26960 -- Added PasswordResetConfirmView option to automatically log
 in after a reset.
 }}}

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

Re: [Django] #26951: AuthenticationForm bug when USERNAME_FIELD is an IntegerField

[Django]

#26951: AuthenticationForm bug when USERNAME_FIELD is an IntegerField
--+
 Reporter:  gavinwahl |Owner:  alexyer
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  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:  1 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"975a76a96428bcc9da43d87e3f8433f498da2d68" 975a76a9]:
 {{{
 #!CommitTicketReference repository=""
 revision="975a76a96428bcc9da43d87e3f8433f498da2d68"
 Fixed #26951 -- Allowed AuthenticationForm to work with a username of 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.7b553c508f7b9ac9e1468f8bb3f8e484%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26840: Extract database teardown from DiscoverRunner, to better support third-party test runners

[Django]

#26840: Extract database teardown from DiscoverRunner, to better support third-
party test runners
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  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 timgraham):

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

Re: [Django] #27039: ModelFields with 'default' value set and 'required'=False in form does not use default value

[Django]

#27039: ModelFields with 'default' value set and 'required'=False in form does 
not
use default value
-+-
 Reporter:  devbis   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  default non- | Triage Stage:  Accepted
  required modelform |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Makes sense to me, however, on older Django versions, `{'f': ''}` as the
 data also results in an instance with the model field default rather than
 an empty string. Do you feel the behavior should be restored for that case
 as well?

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

Re: [Django] #27044: `apps` passed to post_migrate_signal should contain migrated appconfigs even when no migration has been applied to them (was: `apps` passed to post_migrate_signal should have acce

[Django]

#27044: `apps` passed to post_migrate_signal should contain migrated appconfigs
even when no migration has been applied to them
+--
 Reporter:  tkhyn   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

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

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

Re: [Django] #27044: `apps` passed to post_migrate_signal should have access to migrated apps even when no migration has been applied to them

[Django]

#27044: `apps` passed to post_migrate_signal should have access to migrated apps
even when no migration has been applied to them
+--
 Reporter:  tkhyn   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.10
 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 tkhyn):

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


Old description:

> Hi,
>
> I noticed that when one runs `migrate` without arguments (implicitly
> migrating all apps), the `apps` instance passed to
> `emit_post_migrate_signal`
> (https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L221
> [here]) contains the migrated apps' configurations only in the first run.
>
> On subsequent runs, the `plan` list
> ([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L136
> here]) is empty and `post_migrate_apps` is set to `pre_migrate_apps`
> ([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L197
> here]), i.e. the unmigrated apps.
>
> For example, when calling `migrate` with the `contenttypes` app enabled,
> this means that `update_contenttypes`
> ([https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L89
> here]) is passed an `apps` instance with `contenttypes` missing. The
> consequence is that `update_contenttypes` can not go further than
> [https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L102
> this line].
>
> To temporarily fix the issue and correctly trigger the
> `post_migrate_signal` so that the content types are properly updated, I
> need to run `flush` just after `migrate`. I don't think it should not be
> needed to run `flush` simply to correctly trigger the
> `post_migrate_signal` that will update the content types.
>
> It worked fine in Django 1.9.9 as no project state apps instance is
> passed to `emit_post_migrate_signal`, and `update_contenttypes` uses the
> global `apps` instance.
>
> I don't really know enough about the recent developments regarding apps
> management in Django, so I'm not sure what should be done to solve this
> issue. Thanks in advance if somebody has the time to look at it.
>
> ''Context: I'm testing a reusable django app
> ([https://bitbucket.org/tkhyn/django-gm2m django-gm2m]) which test suite
> includes migration tests for a number of mini test apps with different
> models (see [https://bitbucket.org/tkhyn/django-
> gm2m/src/63af327624a45c5aed110546d3d705a6b1bf7c2b/tests/?at=release
> here]). Whenever I switch to another mini-app, the database needs not
> only to be flushed but also re-migrated and the contenttypes need to be
> updated !.''

New description:

 Hi,

 I noticed that when one runs `migrate` without arguments (implicitly
 migrating all apps), the `apps` instance passed to
 `emit_post_migrate_signal`
 
(https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L221
 [here]) contains the migrated apps' configurations only in the first run.

 On subsequent runs, the `plan` list
 
([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L136
 here]) is empty and `post_migrate_apps` is set to `pre_migrate_apps`
 
([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L197
 here]), i.e. the unmigrated apps.

 For example, when calling `migrate` with the `contenttypes` app enabled,
 this means that after the first run `update_contenttypes`
 
([https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L89
 here]) is passed an `apps` instance with `contenttypes` missing. The
 consequence is that `update_contenttypes` can not go further than
 
[https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L102
 this line].

 To temporarily fix the issue and correctly trigger the
 `post_migrate_signal` so that the content types are properly updated each
 time `migrate` is called (and not only the first time), I need to run
 `flush` just after `migrate`. I don't think it should not be needed to run
 `flush` simply to correctly trigger the `post_migrate_signal` that will
 update the content types.

 It worked fine in Django 1.9.9 as no project state apps instance is passed
 to `emit_post_migrate_signal`, and `update_contenttypes` uses the global
 `apps` instance.

 I don't really know enough about the recent developments regarding apps
 management in Django, so I'm not sure what 

[Django] #27044: `apps` passed to post_migrate_signal should have access to migrated apps even when no migration has been applied to them

[Django]

#27044: `apps` passed to post_migrate_signal should have access to migrated apps
even when no migration has been applied to them
+
 Reporter:  tkhyn   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.10
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Hi,

 I noticed that when one runs `migrate` without arguments (implicitly
 migrating all apps), the `apps` instance passed to
 `emit_post_migrate_signal`
 
(https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L221
 [here]) contains the migrated apps' configurations only in the first run.

 On subsequent runs, the `plan` list
 
([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L136
 here]) is empty and `post_migrate_apps` is set to `pre_migrate_apps`
 
([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L197
 here]), i.e. the unmigrated apps.

 For example, when calling `migrate` with the `contenttypes` app enabled,
 this means that `update_contenttypes`
 
([https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L89
 here]) is passed an `apps` instance with `contenttypes` missing. The
 consequence is that `update_contenttypes` can not go further than
 
[https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L102
 this line].

 To temporarily fix the issue and correctly trigger the
 `post_migrate_signal` so that the content types are properly updated, I
 need to run `flush` just after `migrate`. I don't think it should not be
 needed to run `flush` simply to correctly trigger the
 `post_migrate_signal` that will update the content types.

 It worked fine in Django 1.9.9 as no project state apps instance is passed
 to `emit_post_migrate_signal`, and `update_contenttypes` uses the global
 `apps` instance.

 I don't really know enough about the recent developments regarding apps
 management in Django, so I'm not sure what should be done to solve this
 issue. Thanks in advance if somebody has the time to look at it.

 ''Context: I'm testing a reusable django app ([https://bitbucket.org/tkhyn
 /django-gm2m django-gm2m]) which test suite includes migration tests for a
 number of mini test apps with different models (see
 [https://bitbucket.org/tkhyn/django-
 gm2m/src/63af327624a45c5aed110546d3d705a6b1bf7c2b/tests/?at=release
 here]). Whenever I switch to another mini-app, the database needs not only
 to be flushed but also re-migrated and the contenttypes need to be updated
 !.''

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

Re: [Django] #27039: ModelFields with 'default' value set and 'required'=False in form does not use default value

[Django]

#27039: ModelFields with 'default' value set and 'required'=False in form does 
not
use default value
-+-
 Reporter:  devbis   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  default non- | Triage Stage:  Accepted
  required modelform |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 If a user removes the value in a form, the form should receive `{'f':
 ''}`, not an empty dict. I still think we should fix the regression.

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

Re: [Django] #22669: bulk_create with empty model fields fails on oracle

[Django]

#22669: bulk_create with empty model fields fails on oracle
-+-
 Reporter:  sns1081@…|Owner:  mnach
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  QuerySet.bulk_create   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mnach):

 * owner:   => mnach
 * cc: mnach@… (added)
 * 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/075.a982f5405379012929fcc6992fa8f26d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.