Re: [Django] #29653: Using GenericRelation.related_query_name through an inherited abstract class crashes

[Django]

#29653: Using GenericRelation.related_query_name through an inherited abstract
class crashes
-+-
 Reporter:  Lauri Kainulainen|Owner:  Ramiro
 |  Morales
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  2.1
  contrib.contenttypes   |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ramiro Morales):

 * has_patch:  0 => 1


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

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

Re: [Django] #29653: Using GenericRelation.related_query_name through an inherited abstract class crashes

[Django]

#29653: Using GenericRelation.related_query_name through an inherited abstract
class crashes
-+-
 Reporter:  Lauri Kainulainen|Owner:  Ramiro
 |  Morales
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  2.1
  contrib.contenttypes   |
 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 Ramiro Morales):

 * status:  new => assigned
 * owner:  nobody => Ramiro Morales


Comment:

 Replying to [comment:2 Ramiro Morales]:
 > Additionally, the test case added in the commit which introduced the
 regression (4ab027b94409e6415b774797bf9d3593da9d9ea8 to fix #28988) isn't
 actually testing the originally reported scenario. The `Place` model
 containig the `GeneridRelation` field isn't using MTI.

 Scrap this comment. I misread the #28988 ticket.

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

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

Re: [Django] #29653: Using GenericRelation.related_query_name through an inherited abstract class crashes

[Django]

#29653: Using GenericRelation.related_query_name through an inherited abstract
class crashes
--+
 Reporter:  Lauri Kainulainen |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  2.1
 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 Ramiro Morales):

 Additionally, the test case added in the commit which introduced the
 regression (4ab027b94409e6415b774797bf9d3593da9d9ea8 to fix #28988) isn't
 actually testing the originally reported scenario. The `Place` model
 containig the `GeneridRelation` field isn't using MTI.

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

Re: [Django] #29650: Changes in refresh_from_db method

[Django]

#29650: Changes in refresh_from_db method
-+-
 Reporter:  Thomas Berdy |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  refresh_from_db  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Can you simplify your steps to reproduce with some minimal models and
 without `MyCustomSerializer` and the deepcopy stuff? It's difficult to
 tell exactly what's happening in  your code. Ideally, you could also
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/#bisecting-a-regression bisect] to find the commit where the
 behavior changed. 136bf5c2142ae3261669d02e2dd050c3141f7f2f perhaps.

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

Re: [Django] #29651: MemoryError while deleting object with huge amount of related objects

[Django]

#29651: MemoryError while deleting object with huge amount of related objects
-+-
 Reporter:  Sven R. Kunze|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:  duplicate
 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 Tim Graham):

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


Old description:

> It seems like Django admin is loading all related objects into memory
> while deleting via admin interface.
>
> Can we make deleting related objects iteratively (applying signals etc.)?
>

> SO question on this topic I found so far:
> https://stackoverflow.com/questions/31477723/how-to-prevent-django-from-
> loading-objects-in-memory-when-using-delete
>
> Related ticket:
> https://code.djangoproject.com/ticket/10919

New description:

 It seems like Django admin is loading all related objects into memory
 while deleting via admin interface.

 Can we make deleting related objects iteratively (applying signals etc.)?


 SO question on this topic I found so far:
 https://stackoverflow.com/questions/31477723/how-to-prevent-django-from-
 loading-objects-in-memory-when-using-delete

 Related ticket #10919

--

Comment:

 I'd consider this a duplicate of #10919. Even if the solution ends up
 different than that ticket's title, the underlying issue is the same, I
 think. If you have a solution to offer that doesn't address the related
 ticket, feel free to reopen.

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

Re: [Django] #29653: Using GenericRelation.related_query_name through an inherited abstract class crashes (was: Using GenericRelation.related_query_name through an inherited abstract class breaks when

[Django]

#29653: Using GenericRelation.related_query_name through an inherited abstract
class crashes
--+
 Reporter:  Lauri Kainulainen |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  2.1
 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 Tim Graham):

 * cc: robwa (added)
 * stage:  Unreviewed => Accepted
 * severity:  Normal => Release blocker


Comment:

 Bisected to 4ab027b94409e6415b774797bf9d3593da9d9ea8.

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

Re: [Django] #29652: Document that Django 2.1 dropped compatbility with py-bcrypt

[Django]

#29652: Document that Django 2.1 dropped compatbility with py-bcrypt
-+-
 Reporter:  Jens-Wolfhard|Owner:  nobody
  Schicke-Uffmann|
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  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:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"42f194b8582649756b9c85906326834e6365d0a3" 42f194b]:
 {{{
 #!CommitTicketReference repository=""
 revision="42f194b8582649756b9c85906326834e6365d0a3"
 [2.1.x] Refs #29652 -- Fixed typo in docs/releases/2.1.txt.

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

Re: [Django] #29652: Document that Django 2.1 dropped compatbility with py-bcrypt

[Django]

#29652: Document that Django 2.1 dropped compatbility with py-bcrypt
-+-
 Reporter:  Jens-Wolfhard|Owner:  nobody
  Schicke-Uffmann|
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  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:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"d0928d6454d0b649663820e45d915016a2d9b001" d0928d64]:
 {{{
 #!CommitTicketReference repository=""
 revision="d0928d6454d0b649663820e45d915016a2d9b001"
 Refs #29652 -- Fixed typo in docs/releases/2.1.txt.
 }}}

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

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

Re: [Django] #29652: Document that Django 2.1 dropped compatbility with py-bcrypt

[Django]

#29652: Document that Django 2.1 dropped compatbility with py-bcrypt
-+-
 Reporter:  Jens-Wolfhard|Owner:  nobody
  Schicke-Uffmann|
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  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:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"2fa36719a8fb39f2c2162f9e6430db00c6bc8412" 2fa3671]:
 {{{
 #!CommitTicketReference repository=""
 revision="2fa36719a8fb39f2c2162f9e6430db00c6bc8412"
 Fixed #29652 -- Doc'd removal of py-bcrypt 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/066.f7ee46d83a4b4ad147ae84c6aad95ee5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29652: Document that Django 2.1 dropped compatbility with py-bcrypt

[Django]

#29652: Document that Django 2.1 dropped compatbility with py-bcrypt
-+-
 Reporter:  Jens-Wolfhard|Owner:  nobody
  Schicke-Uffmann|
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  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:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"548a2d3c1fc273f770e616f5ef0593f79867a5a4" 548a2d3c]:
 {{{
 #!CommitTicketReference repository=""
 revision="548a2d3c1fc273f770e616f5ef0593f79867a5a4"
 [2.1.x] Fixed #29652 -- Doc'd removal of py-bcrypt compatibility.

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

Re: [Django] #29652: Document that Django 2.1 dropped compatbility with py-bcrypt (was: BCryptSHA256PasswordHasher fails to encode())

[Django]

#29652: Document that Django 2.1 dropped compatbility with py-bcrypt
-+-
 Reporter:  Jens-Wolfhard|Owner:  nobody
  Schicke-Uffmann|
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  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:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Django 1.9 also broke compatibility with py-bcrypt in #26016. At the time
 (3 years ago), we restored compatibility but I don't see a need to do so
 at this point since it looks like py-bcrypt is unmaintained. I'll document
 that in the release notes.

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

Re: [Django] #29647: "Please correct the error below." when saving edit model form with inline formset and space at the end of primary key value

[Django]

#29647: "Please correct the error below." when saving edit model form with 
inline
formset and space at the end of primary key value
---+--
 Reporter:  Alex Uralov|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  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 Tim Graham):

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


Comment:

 Yes, I can reproduce with those steps. Thanks. Inspecting the errors
 manually, I see `[{'attribute': ['The inline value did not match the
 parent instance.']}]`. I think the root cause is that the trailing space
 is stripped in the parent instance but not for the child instance. I don't
 think this is a bug in Django but it could be considered a duplicate of
 #2259 in that the primary key probably shouldn't be editable in the first
 place. I think you could fix that using `ModelAdmin.readonly_fields`.

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

Re: [Django] #10768: Allow for Admin Actions to be applied to an empty QuerySet

[Django]

#10768: Allow for Admin Actions to be applied to an empty QuerySet
-+-
 Reporter:  andrepleblanc@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  actions  | Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Humberto Yances):

 Replying to [comment:6 Karen Tracey]:
 > Performing an action on an empty query set should do nothing.  Therefore
 there is no point in calling the action with an empty query set.  (If the
 action did something other than nothing, that would be surprising;
 enabling such surprises in the admin UI seems like a Bad Idea.)  #12281
 covers the case of issuing a message that something needs to be selecting
 before you can successfully perform an action.  We should fix #12281 and
 reject this one.


 == Actions that don't act on specific items are a fundamentally different

 I would not state this in such an absolute way, and preclude users the
 option to make their own wrong choices…

 Limited to django, I'm not particularly experienced, I seldom contribute
 to django programs. Now in the current assignment we need to import data
 from external sources (openstreetmap, wubook), and we either need to
 refresh a subset of our already existing items, or we want to import
 things from scratch. The code in the two cases is obviously the same. The
 "import from scratch" we run on an empty selection, and our initial
 workaround was really terrible, that is remove everything, add a fake new
 object, select it, then run the action.

 I'm looking into the object-tools, and I have several perplexities: one is
 that it looks quite a bit more work to add them; two is that I need to
 program my actions elsewhere, while they do fundamentally the same thing;
 three is that the action I need depends on the table I'm in, it's
 definitely not a generic tool.

 so while we can't activate the action on an empty selection, I'm afraid
 I'm going to register the same action twice, where one will just invoke
 the other with an empty selection, simply by-passing this django check

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

Re: [Django] #29652: BCryptSHA256PasswordHasher fails to encode()

[Django]

#29652: BCryptSHA256PasswordHasher fails to encode()
--+--
 Reporter:  Drahflow  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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:  1 |UI/UX:  0
--+--

Comment (by Drahflow):

 Not my choice of bcrypt implementation. The project where I observed the
 problem is ancient and had it lying around in requirements.txt. Switching
 to bcrypt 3.1.4 solves the problem for me.

 Not sure if it's worthwhile to support a seamless upgrade from Django
 2.0.7 to Django 2.1 for the other implementation.

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

Re: [Django] #29652: BCryptSHA256PasswordHasher fails to encode()

[Django]

#29652: BCryptSHA256PasswordHasher fails to encode()
--+--
 Reporter:  Drahflow  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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:  1 |UI/UX:  0
--+--

Comment (by Drahflow):

 Name: py-bcrypt
 Version: 0.4
 Summary: bcrypt password hashing and key derivation
 Home-page: https://code.google.com/p/py-bcrypt

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

[Django] #29653: Using GenericRelation.related_query_name through an inherited abstract class breaks when upgrading from django 1.10 to 2.1.0

[Django]

#29653: Using GenericRelation.related_query_name through an inherited abstract
class breaks when upgrading from django 1.10 to 2.1.0
+
   Reporter:  luopio|  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.contenttypes  |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 |
+
 We upgraded a production app from 1.10 to 2.1.0 today and ran into an
 interesting issue. Our previous models (trimmed for readability):

 {{{
 class Event(models.Model):
 class Meta:
 ordering = ['time']
 target_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
 target_id = models.PositiveIntegerField()
 target = GenericForeignKey('target_type', 'target_id')
 time = models.DateTimeField()

 class EventTarget(models.Model):
 class Meta:
 abstract = True
 events = GenericRelation(Event, 'target_id', 'target_type',
 related_query_name='targets')

 class WorkOrder(EventTarget):
  [...]
 }}}

 Worked fine previously, but in Django 2 we got this:
 {{{
 In [1]: from workorders.models import *

 In [2]: e = WorkOrder.objects.first().events.first()

 In [3]: e.targets
 ---
 AttributeErrorTraceback (most recent call
 last)
  in ()
 > 1 e.targets

 AttributeError: 'Event' object has no attribute 'targets'
 }}}

 If we move the GenericRelation directly inside the model it works:

 {{{
 [...]
 class WorkOrder(models.Model):
 events = GenericRelation(Event, 'target_id', 'target_type',
 related_query_name='targets')
 [...]
 }}}

 {{{
 In [1]: from workorders.models import *

 In [2]: e = WorkOrder.objects.first().events.first()

 In [3]: e.targets
 Out[3]:
 
.RelatedManager
 at 0x7f5f9df2af60>
 }}}

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

Re: [Django] #29652: BCryptSHA256PasswordHasher fails to encode()

[Django]

#29652: BCryptSHA256PasswordHasher fails to encode()
--+--
 Reporter:  Drahflow  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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:  1 |UI/UX:  0
--+--

Comment (by Tim Graham):

 What version of bcrypt are you using? I don't see the crash with bcrypt
 3.1.4 as `bcrypt.hashpw()` returns a bytestring.

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

Re: [Django] #29570: Add check that MEDIA_URL is not inside STATIC_URL.

[Django]

#29570: Add check that MEDIA_URL is not inside STATIC_URL.
--+
 Reporter:  Alejandro Dubrovsky   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (System checks)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Herbert Fortes):

 * cc: Herbert Fortes (added)


Comment:

 Hi,

 I ran the tests (./runtests.py)  without a problem.

 I have one minor suggestion. Instead of `\` use `()` to break a line:
 {{{#!python
 if (settings.MEDIA_URL and settings.STATIC_URL and
 settings.MEDIA_URL.startswith(settings.STATIC_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/063.15f13df716e5780ed1f46d19ec46440a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29652: BCryptSHA256PasswordHasher fails to encode()

[Django]

#29652: BCryptSHA256PasswordHasher fails to encode()
--+--
 Reporter:  Drahflow  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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:  1 |UI/UX:  0
--+--
Changes (by Drahflow):

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

Re: [Django] #29652: BCryptSHA256PasswordHasher fails to encode()

[Django]

#29652: BCryptSHA256PasswordHasher fails to encode()
--+--
 Reporter:  Drahflow  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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:  1 |UI/UX:  0
--+--
Description changed by Drahflow:

Old description:

> The BCryptSHA256PasswordHasher became more picky in what kind of data it
> accepts. This broke existing code which subclassed the
> BCryptSHA256PasswordHasher and hashes the result of some other
> computation.
>
> {{{
> #!/usr/bin/env python
>
> from django.contrib.auth.hashers import BCryptSHA256PasswordHasher
>
> hasher = BCryptSHA256PasswordHasher()
> hasher.encode('secret', hasher.salt())
> }}}
> results in
> {{{
> Traceback (most recent call last):
>   File "issue.py", line 6, in 
> hasher.encode('secret', hasher.salt())
>   File "/mnt/crypt/drahflow/.virtualenvs/NDA/lib/python3.6/site-
> packages/django/contrib/auth/hashers.py", line 417, in encode
> return "%s$%s" % (self.algorithm, data.decode('ascii'))
> AttributeError: 'str' object has no attribute 'decode'
> }}}
>
> The bug was introduced in:
> https://github.com/django/django/commit/16c5a334ff3ad9d8b3cd1314562c7af20a2a7c7d
> Other hashers might be affected, I didn't check.

New description:

 The BCryptSHA256PasswordHasher tries to decode the result of
 bcrypt.hashpw, which however is already a str (and not bytes).

 {{{
 #!/usr/bin/env python

 from django.contrib.auth.hashers import BCryptSHA256PasswordHasher

 hasher = BCryptSHA256PasswordHasher()
 hasher.encode('secret', hasher.salt())
 }}}
 results in
 {{{
 Traceback (most recent call last):
   File "issue.py", line 6, in 
 hasher.encode('secret', hasher.salt())
   File "/mnt/crypt/drahflow/.virtualenvs/NDA/lib/python3.6/site-
 packages/django/contrib/auth/hashers.py", line 417, in encode
 return "%s$%s" % (self.algorithm, data.decode('ascii'))
 AttributeError: 'str' object has no attribute 'decode'
 }}}

 The bug was introduced in:
 
https://github.com/django/django/commit/16c5a334ff3ad9d8b3cd1314562c7af20a2a7c7d
 Other hashers might be affected, I didn't check.

--

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

Re: [Django] #29652: BCryptSHA256PasswordHasher fails to encode()

[Django]

#29652: BCryptSHA256PasswordHasher fails to encode()
--+--
 Reporter:  Drahflow  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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:  1 |UI/UX:  0
--+--
Changes (by Herbert Fortes):

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

Re: [Django] #29652: BCryptSHA256PasswordHasher fails to encode()

[Django]

#29652: BCryptSHA256PasswordHasher fails to encode()
--+--
 Reporter:  Drahflow  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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:  1 |UI/UX:  0
--+--
Description changed by Drahflow:

Old description:

> {{{
> #!/usr/bin/env python
>
> from django.contrib.auth.hashers import BCryptSHA256PasswordHasher
>
> hasher = BCryptSHA256PasswordHasher()
> hasher.encode('secret', hasher.salt())
> }}}
> results in
> {{{
> Traceback (most recent call last):
>   File "issue.py", line 6, in 
> hasher.encode('secret', hasher.salt())
>   File "/mnt/crypt/drahflow/.virtualenvs/NDA/lib/python3.6/site-
> packages/django/contrib/auth/hashers.py", line 417, in encode
> return "%s$%s" % (self.algorithm, data.decode('ascii'))
> AttributeError: 'str' object has no attribute 'decode'
> }}}
>
> The bug was introduced in:
> https://github.com/django/django/commit/16c5a334ff3ad9d8b3cd1314562c7af20a2a7c7d
> Other hashers might be affected, I didn't check.

New description:

 The BCryptSHA256PasswordHasher became more picky in what kind of data it
 accepts. This broke existing code which subclassed the
 BCryptSHA256PasswordHasher and hashes the result of some other
 computation.

 {{{
 #!/usr/bin/env python

 from django.contrib.auth.hashers import BCryptSHA256PasswordHasher

 hasher = BCryptSHA256PasswordHasher()
 hasher.encode('secret', hasher.salt())
 }}}
 results in
 {{{
 Traceback (most recent call last):
   File "issue.py", line 6, in 
 hasher.encode('secret', hasher.salt())
   File "/mnt/crypt/drahflow/.virtualenvs/NDA/lib/python3.6/site-
 packages/django/contrib/auth/hashers.py", line 417, in encode
 return "%s$%s" % (self.algorithm, data.decode('ascii'))
 AttributeError: 'str' object has no attribute 'decode'
 }}}

 The bug was introduced in:
 
https://github.com/django/django/commit/16c5a334ff3ad9d8b3cd1314562c7af20a2a7c7d
 Other hashers might be affected, I didn't check.

--

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

[Django] #29652: BCryptSHA256PasswordHasher fails to encode()

[Django]

#29652: BCryptSHA256PasswordHasher fails to encode()
+
   Reporter:  Drahflow  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.auth  |Version:  2.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 {{{
 #!/usr/bin/env python

 from django.contrib.auth.hashers import BCryptSHA256PasswordHasher

 hasher = BCryptSHA256PasswordHasher()
 hasher.encode('secret', hasher.salt())
 }}}
 results in
 {{{
 Traceback (most recent call last):
   File "issue.py", line 6, in 
 hasher.encode('secret', hasher.salt())
   File "/mnt/crypt/drahflow/.virtualenvs/NDA/lib/python3.6/site-
 packages/django/contrib/auth/hashers.py", line 417, in encode
 return "%s$%s" % (self.algorithm, data.decode('ascii'))
 AttributeError: 'str' object has no attribute 'decode'
 }}}

 The bug was introduced in:
 
https://github.com/django/django/commit/16c5a334ff3ad9d8b3cd1314562c7af20a2a7c7d
 Other hashers might be affected, I didn't check.

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

[Django] #29651: MemoryError while deleting object with huge amount of related objects

[Django]

#29651: MemoryError while deleting object with huge amount of related objects
+
   Reporter:  Sven R. Kunze |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.admin |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 |
+
 It seems like Django admin is loading all related objects into memory
 while deleting via admin interface.

 Can we make deleting related objects iteratively (applying signals etc.)?


 SO question on this topic I found so far:
 https://stackoverflow.com/questions/31477723/how-to-prevent-django-from-
 loading-objects-in-memory-when-using-delete

 Related ticket:
 https://code.djangoproject.com/ticket/10919

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

Re: [Django] #29623: DurationField's overflow error message fails to translate

[Django]

#29623: DurationField's overflow error message fails to translate
-+-
 Reporter:  Jannis Leidel|Owner:  Markus
 |  Holtermann
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.1
 Severity:  Release blocker  |   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:"730173d1c5cf210d8e3bd951fa49f64b9bc561ca" 730173d1]:
 {{{
 #!CommitTicketReference repository=""
 revision="730173d1c5cf210d8e3bd951fa49f64b9bc561ca"
 Fixed #29623 -- Fixed translation failure of DurationField's "overflow"
 error message.
 }}}

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

Re: [Django] #29623: DurationField's overflow error message fails to translate

[Django]

#29623: DurationField's overflow error message fails to translate
-+-
 Reporter:  Jannis Leidel|Owner:  Markus
 |  Holtermann
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.1
 Severity:  Release blocker  |   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
-+-

Comment (by Tim Graham ):

 In [changeset:"e3be4e94d1bc38f9aac087a40eebd0a46c3dacea" e3be4e9]:
 {{{
 #!CommitTicketReference repository=""
 revision="e3be4e94d1bc38f9aac087a40eebd0a46c3dacea"
 [2.1.x] Fixed #29623 -- Fixed translation failure of DurationField's
 "overflow" error message.

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

[Django] #29650: Changes in refresh_from_db method

[Django]

#29650: Changes in refresh_from_db method
-+-
   Reporter:  Thomas |  Owner:  nobody
  Berdy  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  2.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  refresh_from_db
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 After updating to Django 2.1 from Django 2.0.7, I noticed one of my tests
 failed. After further investigation, I figured out the problem was coming
 from **refresh_from_db** method. Here is my test:

 {{{
 s = MyCustomSerializer()
 order = s.create(copy.deepcopy(order_data))

 # Check shipping_address exists
 assert order.shipping_address

 order_data["shipping_address"]["city"] = "Sevran"
 s.update(order, copy.deepcopy(order_data))
 order.refresh_from_db()

 # Check order's shipping_address has been updated
 assert order.shipping_address.city == "Sevran"
 }}}

 Here you can find the definition (light version) of the Order model:

 {{{
 class Order(TimeStampedModel):
 shipping_address = models.ForeignKey(
 "order.ShippingAddress", null=True, blank=True,
 verbose_name=_("Shipping Address"), on_delete=models.SET_NULL
 )
 }}}

 Before 2.1, **refresh_from_db** refresh the whole object and the objects
 linked by foreign key.
 Now it seems that only the first-level object is refreshed.
 Is it normal ? Maybe you can mention it in the release notes.

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

Re: [Django] #29648: Incorrect escaping when using subqueries inside datetime truncation functions

[Django]

#29648: Incorrect escaping when using subqueries inside datetime truncation
functions
-+-
 Reporter:  Raphael Michel   |Owner:  Raphael
 |  Michel
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Subqueries Datetime  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Raphael Michel):

 Replying to [comment:6 Tim Graham]:
 > There's the option create your own `Trunc` functions rather than
 patching Django's.

 Thank you, I didn't think of 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/066.e750eb6f56da881efdc3fdfccaeaa9a0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29649: admin readonly_fields with unique_together raises IntegrityError

[Django]

#29649: admin readonly_fields with unique_together raises IntegrityError
-+-
 Reporter:  harmv|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  unique_together  | Triage Stage:
  IntegrityError |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * component:  Uncategorized => 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/063.9b757a02016fcf93baecac3ec34824a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #13091: admin list_editable with unique_together raises Integrity Error

[Django]

#13091: admin list_editable with unique_together raises Integrity Error
-+-
 Reporter:  Sławek Ehlert|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  list_editable| Triage Stage:  Accepted
  unique_together IntegrityError |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Same issue pops up in #29649, where a `unique_together` field is excluded
 from the form via `read_only_fields`

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

Re: [Django] #29649: admin readonly_fields with unique_together raises IntegrityError

[Django]

#29649: admin readonly_fields with unique_together raises IntegrityError
-+-
 Reporter:  harmv|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  2.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  unique_together  | Triage Stage:
  IntegrityError |  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:   => duplicate


Comment:

 I think this is a duplicate of #13091.

 Yes it's slightly different in that it's using `read_only_fields` but the
 bottom line is that the error is caused by the form not being able to
 validate a `unique_together` constraint where one of the fields is
 excluded. (That's the underlying issue from #13091.)

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

Re: [Django] #29649: admin readonly_fields with unique_together raises IntegrityError

[Django]

#29649: admin readonly_fields with unique_together raises IntegrityError
-+-
 Reporter:  harmv|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  unique_together  | Triage Stage:
  IntegrityError |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by harmv:

Old description:

> I'm getting an IntegrityError when editing a model in the admin, when one
> of the fields of a unique_together pair is in readonly_fields
>
> === example
> {{{
> #models.py
> class Foo(models.Model):
> a = models.IntegerField()
> b = models.IntegerField()
>
> class Meta:
> unique_together = (('a', 'b'), )
>
> #admin.py
> class FooAdmin(admin.ModelAdmin):
> list_display = ('id', 'a', 'b')
> readonly_fields = ('b', )
> }}}
>

>
> === steps to reproduce
>
> In django shell create two instances
> {{{
> >>> from data.models import Foo
> >>> Foo.objects.create(a=1,b=1)
> 
> >>> Foo.objects.create(a=2,b=1)
> 
> }}}
>
> Then in the admin edit Foo object 1 and change a to 2.  (introducing a
> duplicate)
>
> === expected result
> A form validation error in the admin: {{{Foo with this A and B already
> exists.}}}
>
> === actual result
> A server 500 error (IntegrityError)
>
> {{{
> IntegrityError at /admin/data/foo/3/change/
> duplicate key value violates unique constraint
> "data_foo_a_b_ac92595b_uniq"
> DETAIL:  Key (a, b)=(1, 1) already exists.
> }}}
>
> === notes
>
> When removing the {{{readonly_fields}}} from the admin, all works as
> expected.
>
> Maybe related to #13091  (similar issue when list_editable is used
> instead of readonly_fields)

New description:

 I'm getting an IntegrityError when editing a model in the admin, when one
 of the fields of a unique_together pair is in readonly_fields

 === example
 {{{
 #models.py
 class Foo(models.Model):
 a = models.IntegerField()
 b = models.IntegerField()

 class Meta:
 unique_together = (('a', 'b'), )

 #admin.py
 class FooAdmin(admin.ModelAdmin):
 list_display = ('id', 'a', 'b')
 readonly_fields = ('b', )
 }}}



 === steps to reproduce

 In django shell create two instances
 {{{
 >>> from data.models import Foo
 >>> Foo.objects.create(a=1,b=1)
 
 >>> Foo.objects.create(a=2,b=1)
 
 }}}

 Then in the admin edit Foo object 2 and change a 2 -> 1.  (introducing a
 duplicate)

 === expected result
 A form validation error in the admin: {{{Foo with this A and B already
 exists.}}}

 === actual result
 A server 500 error (IntegrityError)

 {{{
 IntegrityError at /admin/data/foo/2/change/
 duplicate key value violates unique constraint
 "data_foo_a_b_ac92595b_uniq"
 DETAIL:  Key (a, b)=(1, 1) already exists.
 }}}

 === notes

 When removing the {{{readonly_fields}}} from the admin, all works as
 expected.

 Maybe related to #13091  (similar issue when list_editable is used instead
 of readonly_fields)

--

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

Re: [Django] #29649: admin readonly_fields with unique_together raises IntegrityError

[Django]

#29649: admin readonly_fields with unique_together raises IntegrityError
-+-
 Reporter:  harmv|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  unique_together  | Triage Stage:
  IntegrityError |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by harmv:

Old description:

> I'm getting an IntegrityError when editing a model in the admin, when one
> of the fields of a unique_together pair is in readonly_fields
>
> === example
> {{{
> #models.py
> class Foo(models.Model):
> a = models.IntegerField()
> b = models.IntegerField()
>
> class Meta:
> unique_together = (('a', 'b'), )
>
> #admin.py
> class FooAdmin(admin.ModelAdmin):
> list_display = ('id', 'a', 'b')
> readonly_fields = ('b', )
> }}}
>

>
> === steps to reproduce
>
> In django shell create two instances
> {{{
> >>> from data.models import Foo
> >>> Foo.objects.create(a=1,b=1)
> 
> >>> Foo.objects.create(a=2,b=1)
> 
> }}}
>
> Then in the admin edit Foo object 1 and change a to 2.  (introducing a
> duplicate)
>
> === expected result
> A form validation error in the admin: "Foo with this A and B already
> exists."
>
> === actual result
> A server 500 error (IntegrityError)
>
> {{{
> IntegrityError at /admin/data/foo/3/change/
> duplicate key value violates unique constraint
> "data_foo_a_b_ac92595b_uniq"
> DETAIL:  Key (a, b)=(1, 1) already exists.
> }}}
>
> === notes
>
> When removing the ```readonly_fields``` from the admin, all works as
> expected.
>
> Maybe related to #13091  (similar issue when list_editable is used
> instead of readonly_fields)

New description:

 I'm getting an IntegrityError when editing a model in the admin, when one
 of the fields of a unique_together pair is in readonly_fields

 === example
 {{{
 #models.py
 class Foo(models.Model):
 a = models.IntegerField()
 b = models.IntegerField()

 class Meta:
 unique_together = (('a', 'b'), )

 #admin.py
 class FooAdmin(admin.ModelAdmin):
 list_display = ('id', 'a', 'b')
 readonly_fields = ('b', )
 }}}



 === steps to reproduce

 In django shell create two instances
 {{{
 >>> from data.models import Foo
 >>> Foo.objects.create(a=1,b=1)
 
 >>> Foo.objects.create(a=2,b=1)
 
 }}}

 Then in the admin edit Foo object 1 and change a to 2.  (introducing a
 duplicate)

 === expected result
 A form validation error in the admin: {{{Foo with this A and B already
 exists.}}}

 === actual result
 A server 500 error (IntegrityError)

 {{{
 IntegrityError at /admin/data/foo/3/change/
 duplicate key value violates unique constraint
 "data_foo_a_b_ac92595b_uniq"
 DETAIL:  Key (a, b)=(1, 1) already exists.
 }}}

 === notes

 When removing the {{{readonly_fields}}} from the admin, all works as
 expected.

 Maybe related to #13091  (similar issue when list_editable is used instead
 of readonly_fields)

--

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

[Django] #29649: admin readonly_fields with unique_together raises IntegrityError

[Django]

#29649: admin readonly_fields with unique_together raises IntegrityError
-+-
   Reporter:  harmv  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  2.0
  Uncategorized  |   Keywords:  unique_together
   Severity:  Normal |  IntegrityError
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm getting an IntegrityError when editing a model in the admin, when one
 of the fields of a unique_together pair is in readonly_fields

 === example
 {{{
 #models.py
 class Foo(models.Model):
 a = models.IntegerField()
 b = models.IntegerField()

 class Meta:
 unique_together = (('a', 'b'), )

 #admin.py
 class FooAdmin(admin.ModelAdmin):
 list_display = ('id', 'a', 'b')
 readonly_fields = ('b', )
 }}}



 === steps to reproduce

 In django shell create two instances
 {{{
 >>> from data.models import Foo
 >>> Foo.objects.create(a=1,b=1)
 
 >>> Foo.objects.create(a=2,b=1)
 
 }}}

 Then in the admin edit Foo object 1 and change a to 2.  (introducing a
 duplicate)

 === expected result
 A form validation error in the admin: "Foo with this A and B already
 exists."

 === actual result
 A server 500 error (IntegrityError)

 {{{
 IntegrityError at /admin/data/foo/3/change/
 duplicate key value violates unique constraint
 "data_foo_a_b_ac92595b_uniq"
 DETAIL:  Key (a, b)=(1, 1) already exists.
 }}}

 === notes

 When removing the ```readonly_fields``` from the admin, all works as
 expected.

 Maybe related to #13091  (similar issue when list_editable is used instead
 of readonly_fields)

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

Re: [Django] #29643: Hashing list in Q objects when using __in lookup

[Django]

#29643: Hashing list in Q objects when using __in lookup
-+-
 Reporter:  rhyre|Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  2.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  hash, tuple, list,   | Triage Stage:  Ready for
  drf|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"2bf766cedca413826d599ac190fd6715429616f6" 2bf766ce]:
 {{{
 #!CommitTicketReference repository=""
 revision="2bf766cedca413826d599ac190fd6715429616f6"
 [2.1.x] Fixed #29643 -- Fixed crash when combining Q objects with __in
 lookups and lists.

 Regression in fc6528b25ab1834be1a478b405bf8f7ec5cf860c.
 Backport of 9fee229874367beafd532dad6d0f9ff9676ded0b 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/063.4749fb693f0f95c72046b32e59fb4ff1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29643: Hashing list in Q objects when using __in lookup

[Django]

#29643: Hashing list in Q objects when using __in lookup
-+-
 Reporter:  rhyre|Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  2.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  hash, tuple, list,   | Triage Stage:  Ready for
  drf|  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:"9fee229874367beafd532dad6d0f9ff9676ded0b" 9fee2298]:
 {{{
 #!CommitTicketReference repository=""
 revision="9fee229874367beafd532dad6d0f9ff9676ded0b"
 Fixed #29643 -- Fixed crash when combining Q objects with __in lookups and
 lists.

 Regression in fc6528b25ab1834be1a478b405bf8f7ec5cf860c.
 }}}

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

Re: [Django] #29647: "Please correct the error below." when saving edit model form with inline formset and space at the end of primary key value

[Django]

#29647: "Please correct the error below." when saving edit model form with 
inline
formset and space at the end of primary key value
---+--
 Reporter:  Alex Uralov|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 Alex Uralov):

 Replying to [comment:1 Tim Graham]:
 > I can't reproduce this given the models and admin you provided. Which
 version of Django are you using? Starting
 [https://docs.djangoproject.com/en/dev/releases/1.9/#miscellaneous in
 Django 1.9]:
 >  CharField now strips input of leading and trailing whitespace by
 default. This can be disabled by setting the new strip argument to False.
 >
 > The behavior I see when editing an `Attribute` whose `name` contains a
 trailing space is that a new instance is created because primary keys
 aren't editable as described in #2259.

 I use Django==2.0.8. Could you reproduce this by steps:
 1) Create a new Attribute item without spaces. For example 'test'
 2) Change the name (primary key) of the attribute via db query. UPDATE
 "public"."MODULE_attribute" SET "name" = 'test ' WHERE "name" = 'test'
 3) Open Django admin panel and try to append any AttributeValue to 'test '
 attribute.
 4) I get the error message "Please correct the error below."

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