Re: [Django] #30017: Django should assume port 443 for https in django.utils.http.is_same_domain()

2018-12-12 Thread Django
#30017: Django should assume port 443 for https in
django.utils.http.is_same_domain()
---+--
 Reporter:  Ruslan Dautkhanov  |Owner:  (none)
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  2.1
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

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


Comment:

 As per the Stack Overflow question linked, the issue here is a wrong Nginx
 configuration.


 {{{
 proxy_set_header X-Forwarded-Host $host:$server_port;
 }}}

 You just want to be using `$host`, and drop the `$server_port` bit.

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


Re: [Django] #30019: Add __class_getitem__ method to managers and querysets

2018-12-12 Thread Django
#30019: Add __class_getitem__ method to managers and querysets
-+-
 Reporter:  Maxim Kurnikov   |Owner:  Greg W
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (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:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Maxim.

 I'm going to close this as needsinfo right now. Not because I'm against it
 but because it's part of the wider discussion around Type Hinting in
 Django.


 I see you posted to the Django-Developers thread about this:
 https://groups.google.com/d/topic/django-developers/trTEbURFhEY/discussion

 Can I ask you to add your effort there? I think there's a group of people
 who are there or there-abouts with this: as ever, it just needs a bit of a
 nudge.
 (There was talk of a DEP, of a working groups, of... — we just need to get
 there.)

 Thanks.

 I'll post there to try and re-liven it.

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

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


[Django] #30036: Code example for using Paginator in a view makes redundant imports

2018-12-12 Thread Django
#30036: Code example for using Paginator in a view makes redundant imports
+
   Reporter:  bhch  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  2.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The code example in this section:
 [https://docs.djangoproject.com/en/2.1/topics/pagination/#using-paginator-
 in-a-view Using Paginator in a view] imports `EmptyPage` and
 `PageNotAnInteger` unnecessarily since `Paginator.get_page()` handles
 these exceptions internally.

 I had to spend some time figuring out why these were imported and never
 used. I even thought the code example might be incomplete, until I checked
 the source code.

 I think it's better to remove these imports as they leave the reader
 confused.

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

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


Re: [Django] #30036: Code example for using Paginator in a view makes redundant imports

2018-12-12 Thread Django
#30036: Code example for using Paginator in a view makes redundant imports
--+
 Reporter:  bhch  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 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 Carlton Gibson):

 Thanks Greg. I already have a patch ready. I just wanted to see if the OP
 wanted to make a contribution...

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


Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

2018-12-12 Thread Django
#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

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


Comment:

 I can't reproduce this.

 * For a superuser `list_editable` is working as expected.
 * For a user with view-only permissions on the admin, `list_editable`
 fields are **not** presented as form widgets. (As expected.)
* Any POST data submitted is not processed.
 * Same adding `has_change_permission()` to always return `False`
   * For superuser and view-only user, fields are not presented as
 editable.

 I'm going to close as-is. If you can provide an example project
 reproducing this (perhaps with a frozen requirements files so we can see
 the exact Django version) I'm happy to look again.

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

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


Re: [Django] #30034: Shows wrong user on list_display in LogEntryAdmin

2018-12-12 Thread Django
#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  logentry,| Triage Stage:
  logentryadmin, list_display,   |  Unreviewed
  wrong user |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi.

 You need to reduce this down to a minimal example showing Django is at
 fault.

 There's really not enough info here for me to see what you issue could be.
 Without a reproduce it's hard to see how we could push this forward.

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


Re: [Django] #30036: Code example for using Paginator in a view makes redundant imports

2018-12-12 Thread Django
#30036: Code example for using Paginator in a view makes redundant imports
--+
 Reporter:  bhch  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Yep. Thanks. Would you like to make a PR for these changes, whilst they're
 fresh in your mind?

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


Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

2018-12-12 Thread Django
#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 Can you put this into a project or a test case, so we can see it in
 action?

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


Re: [Django] #30036: Code example for using Paginator in a view makes redundant imports

2018-12-12 Thread Django
#30036: Code example for using Paginator in a view makes redundant imports
--+
 Reporter:  bhch  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.1
 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 GitHub ):

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


Comment:

 In [changeset:"a394289b58b1773c4959ed768fdb325c91b2b589" a394289b]:
 {{{
 #!CommitTicketReference repository=""
 revision="a394289b58b1773c4959ed768fdb325c91b2b589"
 Fixed #30036 -- Removed unused imports in pagination example.
 }}}

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

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


Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

2018-12-12 Thread Django
#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by ksl):

 Sorry, my bad.

 The situation is actually more complex but boils down to the fact that
 `has_change_permission` is called with `obj=None`.
 This does not allow individual objects (rows) in the changelist to be
 editable while others are not: either the whole changelist is editable or
 it's not. Or am I missing something 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/061.5cdc24b0b13baf0e76b7a6bdb9dfdb42%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30036: Code example for using Paginator in a view makes redundant imports

2018-12-12 Thread Django
#30036: Code example for using Paginator in a view makes redundant imports
--+
 Reporter:  bhch  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 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 Greg W):

 I'll take it if OP doesn't want to do it.

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

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


Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

2018-12-12 Thread Django
#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 Happy to look at a project if you can provide one but just glancing at the
 code, it looks like a programming error: you’re going to need to look at
 the `request.user` to see what you should return. Otherwise you’ve
 overridden the default implementation, which protects against this sort of
 thing.

 You should probably be calling `super()` before your own logic, and only
 continuing if that returns `True`.

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


Re: [Django] #30035: many to many through table not recognisable in custom migration

2018-12-12 Thread Django
#30035: many to many through table not recognisable in custom migration
-+-
 Reporter:  jainmickey   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  2.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  many to many,| Triage Stage:
  through|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 It's unfortunately impossible to determine if Django is at fault with the
 little details you provided so far.

 The fact that you mention writing a custom migration without providing it
 makes it likely that the issue lies there.

 Please note that simply adding a `through` to a `ManyToManyField` or
 manually adding an `AlterField` to add the through is not working yet
 #23034.

 If you have any details that proves that Django is at fault and that this
 report is not a duplicate of #23034 please provide them and reopen this
 issue.

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

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


[Django] #30037: RemoteUserBackend should pass request into configure_user()

2018-12-12 Thread Django
#30037: RemoteUserBackend should pass request into configure_user()
-+-
   Reporter:  Joshua |  Owner:  nobody
  Cannon |
   Type:  New| Status:  new
  feature|
  Component: |Version:  2.1
  contrib.auth   |
   Severity:  Normal |   Keywords:  RemoteUserBackend
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Clients that wish to populate a user's information by subclassing
 {{{RemoteUserBackend}}} and overriding {{{configure_user}}} find
 themselves a bit restricted on what they can configure. If a client wants
 to fill out the user's first name and last name using HTTP headers, there
 is no easy solution for them.

 Instead, the request should also be sent to {{{configure_user}}} (or
 something similar that wouldn't break compatibility).

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

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


Re: [Django] #11593: Incomplete support for app-level testing

2018-12-12 Thread Django
#11593: Incomplete support for app-level testing
-+-
 Reporter:  Masklinn |Owner:  Raphael
 |  Kimmig
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  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 Raphael Kimmig):

 * owner:  nobody => Raphael Kimmig
 * status:  new => assigned


Comment:

 This ticket is really old, but I'd still love to see some progress here.
 I've been thinking about this a bit lately and below are my thoughts so
 far.
 We probably don't need to write a lot of code here, but rather add some
 documentation to the advanced tutorial as well as the advanced testing
 documentation.

 From what I can see there are a few common things that should be
 documented.

 1. How to run tests in a stand alone application (this requires settings).
 2. How to manage settings for running tests in a stand alone application.
 3. How to set up views/urls/middleware ... for tests.
 4. How to add models specifically for tests inside applications.


 For 1, 2 and 3. there are several solutions, to get started I'd probably
 describe
 how to use `django-admin test` to run the tests with a custom
 `test_settings.py`
 file.

 For 4. there is a simple solution if the app doesn't provide any models
 itself.
 In that case one can simply disable migrations for the app in the test
 settings.
 Ideally I'd like to try implementing a `@test_model` decorator as
 suggested in
 https://code.djangoproject.com/ticket/7835 which would also solve the
 general
 case.

 I'd love to have the documentation for reusable apps contain (directly, or
 via links
 to the testing docs) all the information required to not only create an
 app, but also
 make sure it has working tests.

 I'll try to expand the relevant docs over the next few days. If anyone has
 some
 input on the matter I'd be glad to hear it.

 Did I miss any obvious work in that area? Maybe even somewhere in the
 documentation?
 Do you have any suggestions on how specific aspects should be solved?

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


Re: [Django] #30026: Using collapse class in ModelAdmin fieldset while using the same media file in ModelAdmin's and its inline's form causes wrong media ordering

2018-12-12 Thread Django
#30026: Using collapse class in ModelAdmin fieldset while using the same media 
file
in ModelAdmin's and its inline's form causes wrong media ordering
-+--
 Reporter:  Krzysztof Socha  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Carlton Gibson):

 Hi Krzysztof.

 Do you have a fix in mind?

 I ask because I'm not sure it qualifies for a backport and if it's already
 fixed in master it'll be gone for v2.2...

 It might be that it's just a `wontfix` at this point.

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


Re: [Django] #30036: Code example for using Paginator in a view makes redundant imports

2018-12-12 Thread Django
#30036: Code example for using Paginator in a view makes redundant imports
--+
 Reporter:  bhch  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.1
 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
--+

Comment (by Carlton Gibson ):

 In [changeset:"8d741bd88fa6bd14327f6fa791017d0773b41cf2" 8d741bd]:
 {{{
 #!CommitTicketReference repository=""
 revision="8d741bd88fa6bd14327f6fa791017d0773b41cf2"
 [2.1.x] Fixed #30036 -- Removed unused imports in pagination example.

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


Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

2018-12-12 Thread Django
#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Simon Charette):

 That looks like a duplicate of #15759 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/061.46b6b4f1cd1e48e42f7560c6d0d8819b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23004: Cleanse entries from request.META in debug views

2018-12-12 Thread Django
#23004: Cleanse entries from request.META in debug views
-+
 Reporter:  Daniel Hahler|Owner:  maxsond
 Type:  New feature  |   Status:  assigned
Component:  Error reporting  |  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 maxsond):

 * needs_better_patch:  1 => 0


Comment:

 [https://github.com/django/django/pull/10748|​PR] updated for the current
 master branch and with a test for
 ExceptionReporterFilter.get_safe_request_meta.

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


Re: [Django] #23004: Cleanse entries from request.META in debug views

2018-12-12 Thread Django
#23004: Cleanse entries from request.META in debug views
-+
 Reporter:  Daniel Hahler|Owner:  maxsond
 Type:  New feature  |   Status:  assigned
Component:  Error reporting  |  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 maxsond):

 * owner:  Ryan Castner => maxsond


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


Re: [Django] #30017: Django should assume port 443 for https in django.utils.http.is_same_domain()

2018-12-12 Thread Django
#30017: Django should assume port 443 for https in
django.utils.http.is_same_domain()
---+--
 Reporter:  Ruslan Dautkhanov  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Ruslan Dautkhanov):

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


Comment:

 Hi Carlton,

 If Django assume that port 443 is default for httpS, then it'll not fail
 Referer check in this case.

 https://web.site.com/
 and
 https://web.site.com:443/
 are the same thing, but not for Django referer check.

 What we did in nginx is a workaround.

 Real problem is on Django side.

 Thank you!
 Ruslan

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


[Django] #30038: New shortcut: redirect_with_params()

2018-12-12 Thread Django
#30038: New shortcut: redirect_with_params()
-+
   Reporter:  agustin bacigalup  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Uncategorized  |Version:  2.1
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 I'd like to contribute to Django by adding a shorcut, similar to
 `django.shortcuts.redirect` but also appends request's GET parameters. I
 found myself using it a lot, and I wonder if it's useful for the
 community. If so, should I fork Django on Github and submit a pull
 request?

 {{{
 def redirect_with_params(request, to, *args, **kwargs):
 """
 Same as `django.shortcuts.redirect` but recieves a `request` as first
 parameter.
 """
 response = redirect(to, *args, **kwargs)
 url = response.url
 params = request.GET.urlencode()
 if params:
 url = "%s?%s" % (response.url, params)
 return response.__class__(url)
 }}}

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

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


Re: [Django] #30038: New shortcut: redirect_with_params()

2018-12-12 Thread Django
#30038: New shortcut: redirect_with_params()
---+--
 Reporter:  agustin bacigalup  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by agustin bacigalup:

Old description:

> I'd like to contribute to Django by adding a shorcut, similar to
> `django.shortcuts.redirect` but also appends request's GET parameters. I
> found myself using it a lot, and I wonder if it's useful for the
> community. If so, should I fork Django on Github and submit a pull
> request?
>
> {{{
> def redirect_with_params(request, to, *args, **kwargs):
> """
> Same as `django.shortcuts.redirect` but recieves a `request` as first
> parameter.
> """
> response = redirect(to, *args, **kwargs)
> url = response.url
> params = request.GET.urlencode()
> if params:
> url = "%s?%s" % (response.url, params)
> return response.__class__(url)
> }}}

New description:

 I'd like to contribute to Django by adding a shorcut, similar to
 `django.shortcuts.redirect` but also appends request's GET parameters. I
 found myself using it a lot, and I wonder if it's useful for the
 community. If so, should I fork Django on Github and submit a pull
 request?

 {{{
 def redirect_with_params(request, to, *args, **kwargs):
 """
 Same as `django.shortcuts.redirect` but recieves a `request` as first
 parameter.
 It preserves the GET parameters from the `request` in the URL
 redirected.
 """
 response = redirect(to, *args, **kwargs)
 url = response.url
 params = request.GET.urlencode()
 if params:
 url = "%s?%s" % (response.url, params)
 return response.__class__(url)
 }}}

--

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


Re: [Django] #30037: RemoteUserBackend should pass request into configure_user()

2018-12-12 Thread Django
#30037: RemoteUserBackend should pass request into configure_user()
---+
 Reporter:  Joshua Cannon  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  RemoteUserBackend  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Simon Charette):

 * version:  2.1 => master
 * stage:  Unreviewed => Accepted


Comment:

 Now that `authenticate` gets passed `request` I don't see a reason why
 this can't be done for `configure_user`.

 I guess we could reuse `configure_user(request, user)` with a deprecation
 shim that warns about a `configure_user(user)` signature through `inspect`
 reflection just like when the `request` argument was introduced to
 `authenticate` in #25187.

 Here's an example:

 
https://github.com/django/django/commit/4b9330ccc04575f9e5126529ec355a450d12e77c
 #diff-82ec6fd74a1cab41408fbf5bf0998f58R73

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


Re: [Django] #28690: django.utils.http.parse_http_date two digit year check is incorrect

2018-12-12 Thread Django
#28690: django.utils.http.parse_http_date two digit year check is incorrect
-+--
 Reporter:  Mads Jensen  |Owner:  Tameesh Biswas
 Type:  Bug  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+--

Comment (by Tameesh Biswas):

 I've just picked up from the previous PR and opened a new PR here:
 https://github.com/django/django/pull/10749
 It adds regression tests in the first commit that pass without applying
 the fix and adds the fix with another test-case that only passes with the
 fix applied.
 Could you please review the changes?

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


Re: [Django] #30037: RemoteUserBackend should pass request into configure_user()

2018-12-12 Thread Django
#30037: RemoteUserBackend should pass request into configure_user()
---+
 Reporter:  Joshua Cannon  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  RemoteUserBackend  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Greg W):

 Is this as simple as adding {{{request}}} to {{{configure_user(user)}}}
 and updating the documentation regarding the change?  If so, I can take
 it.

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

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


Re: [Django] #30020: Support reading null values for numeric fields on Shapefile import via LayerMapping

2018-12-12 Thread Django
#30020: Support reading null values for numeric fields on Shapefile import via
LayerMapping
-+-
 Reporter:  Kathryn Killebrew|Owner:  Kathryn
 |  Killebrew
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  GIS, GEOS,   | Triage Stage:  Accepted
  LayerMapping   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Kathryn Killebrew):

 * owner:  nobody => Kathryn Killebrew
 * 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/073.6ff5b1a81e7783dccc22bcbe4cf844c0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30034: Shows wrong user on list_display in LogEntryAdmin

2018-12-12 Thread Django
#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  logentry,| Triage Stage:
  logentryadmin, list_display,   |  Unreviewed
  wrong user |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Muslu Y.):

 * Attachment "admin_admin_logentry_2228_change.png" 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/071.782952eeeda2ea52e0c0c6a9b2ab5066%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30034: Shows wrong user on list_display in LogEntryAdmin

2018-12-12 Thread Django
#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  logentry,| Triage Stage:
  logentryadmin, list_display,   |  Unreviewed
  wrong user |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Muslu Y.):

 * Attachment "admin_app_model_1593_history.png" 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/071.b3241147950ebc74bcd0f97454bf98d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30034: Shows wrong user on list_display in LogEntryAdmin

2018-12-12 Thread Django
#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  logentry,| Triage Stage:
  logentryadmin, list_display,   |  Unreviewed
  wrong user |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Muslu Y.):

 * Attachment "admin_admin_logentry.png" 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/071.680ddc7f148c2dbb8d0cd4073bb659f7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30034: Shows wrong user on list_display in LogEntryAdmin

2018-12-12 Thread Django
#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  logentry,| Triage Stage:
  logentryadmin, list_display,   |  Unreviewed
  wrong user |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Muslu Y.:

Old description:

> Hi all;
>
> Logs are listed wrongly at list records on page (list_display -
> change_list.html).
>
> For example;
> Wrong user (username:muslu) in **/admin/admin/logentry/**
> True user (username:admin) in **/admin/admin/logentry/1/change/**
>

> {{{
> class LogEntryAdmin(admin.ModelAdmin):
> list_display = ['content_type', 'user', 'object_repr', 'action_time']
> list_filter = ['user', 'content_type']
> }}}
>

>
> Django: 2.1.3
> settings.AUTH_USER_MODEL: default
> DATABASE_ROUTERS: at this system we are using 2 projects on different
> servers but we are accessing both project from one SQL server. So we use
> only one SQL user table. (Users are same for all projects.)
> (router.AuthRouter)

New description:

 Hi;

 This is my admin.py in custom application.

 admin.py:

 {{{

 from django.contrib.admin.models import LogEntry

 class LogEntryAdmin(admin.ModelAdmin):
 list_display = ['content_type', 'user', 'object_id', 'object_repr',
 'action_time']
 date_hierarchy = 'action_time'
 list_filter = ['user', 'content_type']
 ordering =  ['-action_time']

 def has_add_permission(self, request):
 return False

 def has_change_permission(self, request, obj=None):
 return False

 def has_delete_permission(self, request, obj=None):
 return False

 admin.site.register(LogEntry,LogEntryAdmin)

 }}}


 If I checked **/admin/app/model/1593/history/** and
 **/admin/admin/logentry/** on model's history, It's showing wrong user who
 changed record.

 But when I entering **/admin/admin/logentry/2228/change/** then It's
 showing True user in page.

 I added screen shots.

--

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


[Django] #30039: Inconsistency error after unapplying squash migration.

2018-12-12 Thread Django
#30039: Inconsistency error after unapplying squash migration.
-+-
   Reporter:  Shehzad-   |  Owner:  nobody
  Ahmed  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.1
  layer (models, ORM)|   Keywords:  Squash migration,
   Severity:  Normal |  replaces, rolled back(UN-applied)
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Just for reminder: Migrations contain parent migrations called
 dependencies. So when an parent migration is rolled back all of its
 successors are also rolled back. For the consistency django make record of
 all applied and rolled back(unapplied) migrations. Now before any new
 migration is applied consistency is checked.

 Just for reminder: In Case when a squash migration is created, a list
 inside it is maintained which tracks all migrations it replaced called
 replaces.

 Problem: when a squash migration is rolled back all its replaces(which can
 be dependencies or depended on other migrations) are marked UN-applied but
 squash migration migration it-self does not record UN-applied. Since the
 operation of rolling back squash migration becomes completed. But Then
 when new migrate operation is performed, it causes inconsistency error e.g
 below:

 "django.db.migrations.exceptions.InconsistentMigrationHistory: Migration
 compliance.0007_auto_20180329_1238_squashed_0026_auto_20180815_0741 is
 applied before its dependency
 survey.0092_prospectfarmerviewlinkcompliancelink on database '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/056.7844ee7ebb53b574e84738f10cbbb6df%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30034: Shows wrong user on list_display in LogEntryAdmin

2018-12-12 Thread Django
#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  logentry,| Triage Stage:
  logentryadmin, list_display,   |  Unreviewed
  wrong user |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi Muslu.

 There's still not enough to show Django is at fault here. `LogEntry`
 objects have a `user_id` field. That points to a user.


 You originally had this in your description:

 {{{
 Django: 2.1.3
 19  settings.AUTH_USER_MODEL: default
 20  DATABASE_ROUTERS: at this system we are using 2 projects
 on different servers but we are accessing both project from one SQL
 server. So we use only one SQL user table. (Users are same for all
 projects.) (router.AuthRouter)
 }}}

 As soon as you mention this I suspect you're somehow NOT routing to the
 same users table each time. (But you need to investigate that: this isn't
 a support channel.)

 Happy to look at this if you can create a minimal project (using
 `startproject` and adding just what you need to) that reproduces the error
 and shows Django is at fault.

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


Re: [Django] #30018: Regression for selenium tests & inaccurate Content-Length

2018-12-12 Thread Django
#30018: Regression for selenium tests & inaccurate Content-Length
--+
 Reporter:  Xavier Fernandez  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  HTTP handling |  Version:  2.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


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

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


Re: [Django] #30014: Initialising disabled ModelChoiceField yields 'Select a valid choice'-error despite initialised option being valid

2018-12-12 Thread Django
#30014: Initialising disabled ModelChoiceField yields 'Select a valid 
choice'-error
despite initialised option being valid
-+-
 Reporter:  thoha|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  forms, disabled  | Triage Stage:
  field, error, to_field_name|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Can you reduce this to a minimal example?

 As far as I can see the underlying behaviour between `disabled` and
 `initial` is correct:

 {{{
 >>> from django import forms
 >>>
 >>> class AForm(forms.Form):
 ... c = forms.ChoiceField(choices=(("a","A"), ("b", "B")),
 disabled=True)
 ...
 >>> a_form = AForm(data={}, initial={"c":"a"})
 >>> a_form.is_bound
 True
 >>> a_form.is_valid()
 True
 >>> a_form.errors
 {}
 >>> a_form.cleaned_data
 {'c': 'a'}
 }}}

 Thus there must be something more particular about your case.

 Happy to review if we can pin that down.

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


Re: [Django] #30018: Regression for selenium tests & inaccurate Content-Length

2018-12-12 Thread Django
#30018: Regression for selenium tests & inaccurate Content-Length
-+-
 Reporter:  Xavier Fernandez |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * type:  Bug => Cleanup/optimization


Comment:

 Let's accept this on the "if it is easy to implement" basis. Otherwise we
 can `wontfix`.

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


Re: [Django] #30024: The test client request methods should raise an error when passed None as a data value

2018-12-12 Thread Django
#30024: The test client request methods should raise an error when passed None 
as a
data value
---+
 Reporter:  Jon Dufresne   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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 Carlton Gibson):

 * stage:  Unreviewed => Accepted


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

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


Re: [Django] #30024: The test client request methods should raise an error when passed None as a data value

2018-12-12 Thread Django
#30024: The test client request methods should raise an error when passed None 
as a
data value
---+--
 Reporter:  Jon Dufresne   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 I think this is fair. There's no case where `None` is the right thing to
 use. (As Jon says, **maybe** `'None'` if you really mean that.)

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


Re: [Django] #30004: Set default FILE_UPLOAD_PERMISSION to 0o644. (was: Document TemporaryUploadedFile potential permission issues)

2018-12-12 Thread Django
#30004: Set default FILE_UPLOAD_PERMISSION to 0o644.
--+
 Reporter:  Evgeny Arshinov   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Thus far, no great objections on the mailing list to adjusting the
 FILE_UPLOAD_PERMISSION default. Thus I'm going to rename this and
 ''Accept'' on that basis.

 A PR would need to:

 * Adjust the default.
 * Add a Breaking Change note to `releases/2.2.txt` (on the assumption we
 can get it in for then.) — This should include a ''set to `None` to
 restore previous behaviour' type comment.
 * Adjust the references in the settings docs and deployment checklist.
 * Make sure any other references are adjusted.

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


Re: [Django] #30004: Set default FILE_UPLOAD_PERMISSION to 0o644.

2018-12-12 Thread Django
#30004: Set default FILE_UPLOAD_PERMISSION to 0o644.
--+
 Reporter:  Evgeny Arshinov   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 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 Evgeny Arshinov):

 Replying to [comment:5 Carlton Gibson]:
 > Thus far, no great objections on the mailing list to adjusting the
 FILE_UPLOAD_PERMISSION default. Thus I'm going to rename this and
 ''Accept'' on that basis.

 Thank you! Hopefully, this change will prevent confusion and unpleasant
 surprises for Django users in the future.

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


Re: [Django] #30035: many to many through table not recognisable in custom migration

2018-12-12 Thread Django
#30035: many to many through table not recognisable in custom migration
-+-
 Reporter:  jainmickey   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  many to many,| Triage Stage:
  through|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by jainmickey:

Old description:

> I have a model `A` having field `b` as many to many. I wanted to make `b`
> default through table's default id field to be UUID.
> If I do that using through table, the admin interface changes to Inline
> and I don't want that. So, I tried writing a custom migration to do that.
>
> If I am checking the default intermediate table using `apps.get_model` it
> exists but when I use the same table in migrations it gives me error:
>
> ```
> File "./manage.py", line 19, in 
> execute_from_command_line(sys.argv)
>   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
> packages/django/core/management/__init__.py", line 371, in
> execute_from_command_line
> utility.execute()
>   File "/Users/mj/.virtualenvs/
> proj/lib/python3.6/site-packages/django/core/management/__init__.py",
> line 365, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
> packages/django/core/management/base.py", line 288, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
> packages/django/core/management/base.py", line 335, in execute
> output = self.handle(*args, **options)
>   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
> packages/django/core/management/commands/migrate.py", line 200, in handle
> fake_initial=fake_initial,
>   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
> packages/django/db/migrations/executor.py", line 117, in migrate
> state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
> fake_initial=fake_initial)
>   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
> packages/django/db/migrations/executor.py", line 147, in
> _migrate_all_forwards
> state = self.apply_migration(state, migration, fake=fake,
> fake_initial=fake_initial)
>   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
> packages/django/db/migrations/executor.py", line 244, in apply_migration
> state = migration.apply(state, schema_editor)
>   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
> packages/django/db/migrations/migration.py", line 112, in apply
> operation.state_forwards(self.app_label, project_state)
>   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
> packages/django/db/migrations/operations/fields.py", line 70, in
> state_forwards
> state.models[app_label,
> self.model_name_lower].fields.append((self.name, field))
> KeyError: ('app', 'A_b')
> ```

New description:

 I have a model `A` having field `b` as many to many. I wanted to make `b`
 default through table's default id field to be UUID.
 If I do that using through table, the admin interface changes to Inline
 and I don't want that. So, I tried writing a custom migration to do that.

 If I am checking the default intermediate table using `apps.get_model` it
 exists but when I use the same table in migrations it gives me error:

 {{{

 File "./manage.py", line 19, in 
 execute_from_command_line(sys.argv)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/core/management/__init__.py", line 371, in
 execute_from_command_line
 utility.execute()
   File "/Users/mj/.virtualenvs/
 proj/lib/python3.6/site-packages/django/core/management/__init__.py", line
 365, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/core/management/base.py", line 288, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/core/management/base.py", line 335, in execute
 output = self.handle(*args, **options)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/core/management/commands/migrate.py", line 200, in handle
 fake_initial=fake_initial,
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/db/migrations/executor.py", line 117, in migrate
 state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
 fake_initial=fake_initial)
   File 

Re: [Django] #30034: Shows wrong user on list_display in LogEntryAdmin

2018-12-12 Thread Django
#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  logentry,| Triage Stage:
  logentryadmin, list_display,   |  Unreviewed
  wrong user |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Muslu Y.):

 * Attachment "DeepinEkranGörüntüsü_alan-seç_20181212150939.png" 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/071.c47a27d9e2e375f2a6a253e9079a71d2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30034: Shows wrong user on list_display in LogEntryAdmin

2018-12-12 Thread Django
#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  logentry,| Triage Stage:
  logentryadmin, list_display,   |  Unreviewed
  wrong user |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Muslu Y.):

 * Attachment "DeepinEkranGörüntüsü_alan-seç_20181212151005.png" 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/071.039ac61327846c0c30d3c75afee374ec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #30034: Shows wrong user on list_display in LogEntryAdmin

2018-12-12 Thread Django
#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
   Reporter:  Muslu Y.   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  2.1
  contrib.admin  |   Keywords:  logentry,
   Severity:  Normal |  logentryadmin, list_display, wrong
   Triage Stage: |  user
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi all;

 Logs are listed wrongly at list records on page (list_display -
 change_list.html).

 For example;
 Wrong user (username:muslu) in **/admin/admin/logentry/**
 True user (username:admin) in **/admin/admin/logentry/1/change/**


 {{{
 class LogEntryAdmin(admin.ModelAdmin):
 list_display = ['content_type', 'user', 'object_repr', 'action_time']
 list_filter = ['user', 'content_type']
 }}}



 Django: 2.1.3
 settings.AUTH_USER_MODEL: default
 DATABASE_ROUTERS: at this system we are using 2 projects on different
 servers but we are accessing both project from one SQL server. So we use
 only one SQL user table. (Users are same for all projects.)
 (router.AuthRouter)

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


[Django] #30035: many to many through table not recognisable in custom migration

2018-12-12 Thread Django
#30035: many to many through table not recognisable in custom migration
-+-
   Reporter: |  Owner:  nobody
  jainmickey |
   Type:  Bug| Status:  new
  Component: |Version:  2.0
  Migrations |   Keywords:  many to many,
   Severity:  Normal |  through
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have a model `A` having field `b` as many to many. I wanted to make `b`
 default through table's default id field to be UUID.
 If I do that using through table, the admin interface changes to Inline
 and I don't want that. So, I tried writing a custom migration to do that.

 If I am checking the default intermediate table using `apps.get_model` it
 exists but when I use the same table in migrations it gives me error:

 ```
 File "./manage.py", line 19, in 
 execute_from_command_line(sys.argv)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/core/management/__init__.py", line 371, in
 execute_from_command_line
 utility.execute()
   File "/Users/mj/.virtualenvs/
 proj/lib/python3.6/site-packages/django/core/management/__init__.py", line
 365, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/core/management/base.py", line 288, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/core/management/base.py", line 335, in execute
 output = self.handle(*args, **options)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/core/management/commands/migrate.py", line 200, in handle
 fake_initial=fake_initial,
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/db/migrations/executor.py", line 117, in migrate
 state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
 fake_initial=fake_initial)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/db/migrations/executor.py", line 147, in
 _migrate_all_forwards
 state = self.apply_migration(state, migration, fake=fake,
 fake_initial=fake_initial)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/db/migrations/executor.py", line 244, in apply_migration
 state = migration.apply(state, schema_editor)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/db/migrations/migration.py", line 112, in apply
 operation.state_forwards(self.app_label, project_state)
   File "/Users/mj/.virtualenvs/proj/lib/python3.6/site-
 packages/django/db/migrations/operations/fields.py", line 70, in
 state_forwards
 state.models[app_label,
 self.model_name_lower].fields.append((self.name, field))
 KeyError: ('app', 'A_b')
 ```

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

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