date:20170519

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

2017-05-19 Thread Django

#28210: `._state.adding` behaviour and model inheritance
-+-
 Reporter:  Ivaylo Donchev   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"f2b8fa1763116a9b8fbe7791a4b009c95cf8c0b1" f2b8fa17]:
 {{{
 #!CommitTicketReference repository=""
 revision="f2b8fa1763116a9b8fbe7791a4b009c95cf8c0b1"
 [1.11.x] Fixed #28210 -- Fixed Model._state.adding on MTI parent model
 after saving child model.

 Regression in 38575b007a722d6af510ea46d46393a4cda9ca29.

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

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

2017-05-19 Thread Django

#28210: `._state.adding` behaviour and model inheritance
-+-
 Reporter:  Ivaylo Donchev   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"59ab1b2683b6c090dc409d9eb8303aadbd590c04" 59ab1b26]:
 {{{
 #!CommitTicketReference repository=""
 revision="59ab1b2683b6c090dc409d9eb8303aadbd590c04"
 Fixed #28210 -- Fixed Model._state.adding on MTI parent model after saving
 child model.

 Regression in 38575b007a722d6af510ea46d46393a4cda9ca29.
 }}}

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

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

Re: [Django] #373: Add support for multiple-column primary keys

2017-05-19 Thread Django

#373: Add support for multiple-column primary keys
-+-
 Reporter:  Jacob|Owner:  Michal
 |  Petrucha
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Schuyler Duveen):

 * cc: sky@… (added)


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

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

Re: [Django] #28212: Allow customizing the port that LiveServerTestCase uses

2017-05-19 Thread Django

#28212: Allow customizing the port that LiveServerTestCase uses
--+
 Reporter:  Robert Rollins|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  1.11
 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 Robert Rollins):

 * Attachment "allow_assigning_port-with-test.patch" added.


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

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

Re: [Django] #28212: Allow customizing the port that LiveServerTestCase uses

2017-05-19 Thread Django

Comment (by Robert Rollins):

Well that was much less painful than I expected! I've had some pretty
harrowing experiences trying to set up and run other app's test suites in
the past, but Django's was a breeze!

Here's a new patch with the code change and a test I wrote. Unfortunately,
I don't really know what to do about exceptions thrown during the test
(like what
`LiveServerPort.test_port_bind` does), so the test code isn't complete.
But I think it exercises the relevant code changes, at least.

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

Re: [Django] #18332: No generic way to get database backend version

2017-05-19 Thread Django

#18332: No generic way to get database backend version
-+-
 Reporter:  apollovy@…   |Owner:
 |  vanessagomes
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Michiel Beijen):

 I created a pull request here:

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

 I took the old patch attached to this ticket and brushed it up a bit. To
 the original SQLite implementation I added PostgreSQL, MySQL and Oracle
 implementations.

 We also no longer return a namedtuple but a dict instead because it feels
 more in line with the rest of Django.

 The thing I'm unsure about is if it would not be better to have the
 'vendor' be the 'vendor' and a 'type' that can indicate the type. For
 instance for MySQL there is MySQL and MariaDB with each their own version
 numbering schemes.

 This provides an option
 {{{
 get_backend_info()
 }}}
 that allows you to retrieve the database type (vendor) and version, as a
 tuple.


 {{{
 >>> from django.db import connection
 >>> connection.backend_info()
 {'vendor': 'postgresql', 'version': (9, 6, 2)}
 }}}

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

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

[Django] #28226: Remove use of deprecated ''.join() pattern

2017-05-19 Thread Django

#28226: Remove use of deprecated ''.join() pattern
+
   Reporter:  James Bennett |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  HTTP handling |Version:  master
   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 |
+
 From Lennart Regebro's PyCon 2017 talk: we're using this in
 django/http/multipartparser.py where it's no longer necessary
 (concatenation is now faster on every version of Python we support).

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

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

2017-05-19 Thread Django

#28210: `._state.adding` behaviour and model inheritance
-+-
 Reporter:  Ivaylo Donchev   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #28224: Use more specific exception testing in Django's tests (was: Test suite exception catching is not always specific)

2017-05-19 Thread Django

#28224: Use more specific exception testing in Django's tests
--+
 Reporter:  Mads Jensen   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  exception classes | 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):

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

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

2017-05-19 Thread Django

#28210: `._state.adding` behaviour and model inheritance
-+-
 Reporter:  Ivaylo Donchev   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Tim Graham):

 * has_patch:  0 => 1


Comment:

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

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

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

Re: [Django] #28225: Credentials of the Admin login form are stored browser due autocomplete was enabled by default.

2017-05-19 Thread Django

#28225: Credentials of the Admin login form are stored browser due autocomplete 
was
enabled by default.
+--
 Reporter:  Pablo Catalina  |Owner:  nobody
 Type:  Uncategorized   |   Status:  closed
Component:  contrib.admin   |  Version:  1.11
 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:

 I don't believe that browsers storing login credentials is a security
 issue. By the way, security issues should be
 [https://docs.djangoproject.com/en/dev/internals/security/#reporting-
 security-issues reported to the security team] rather than in this ticket
 tracker.

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

Re: [Django] #28017: Add option to specify a different secret to PasswordResetTokenGenerator

2017-05-19 Thread Django

#28017: Add option to specify a different secret to PasswordResetTokenGenerator
--+--
 Reporter:  Jann Haber|Owner:  Jann Haber
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by Jann Haber):

 * needs_better_patch:  1 => 0


Comment:

 I updated the PR according to Tim's comments. Thank you for the review!

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

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

[Django] #28225: Credentials of the Admin login form are stored browser due autocomplete was enabled by default.

2017-05-19 Thread Django

#28225: Credentials of the Admin login form are stored browser due autocomplete 
was
enabled by default.
-+
   Reporter:  xkill  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  contrib.admin  |Version:  1.11
   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 credentials are stored on browser cache.

 It is a security issue or vulnerability

 CVSS 2 = 1.9 (AV:L/AC:M/Au:N/C:P/I:N/A:N)

 A variable on the configuration of the django application can be set to
 enable or disable autocompletion on the login form of the admin interface.

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

Re: [Django] #28222: Django 1.11 update_or_create field validation results in different behaviours between create and update_or_create

2017-05-19 Thread Django

#28222: Django 1.11 update_or_create field validation results in different
behaviours between create and update_or_create
-+-
 Reporter:  Alex Mykyta  |Owner:  Alex
 |  Mykyta
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.11 | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> This is an issue related to #27118. Anthony King commented on it but that
> issue is closed so I am opening a new one. The field validation
> introduced in 1.11 `update_or_create` will throw a `FieldError` if a
> `defaults` argument contains a value that is set through an
> `@property.setter` on that model. On the other hand `create` continues to
> function correctly. Ideally they'd behave consistently.
>
> Here is an example https://dpaste.de/UORC

New description:

 This is an issue related to #27118. Anthony King commented on it but that
 issue is closed so I am opening a new one. The field validation introduced
 in 1.11 `update_or_create` will throw a `FieldError` if a `defaults`
 argument contains a value that is set through an `@property.setter` on
 that model. On the other hand `create` continues to function correctly.
 Ideally they'd behave consistently.

 Here is an example.
 {{{
 # create works, update_or_create does not. Should neither work?
 class Choice(models.Model):
 poll = models.ForeignKey(Poll)
 choice_text = models.CharField(max_length=200)
 votes = models.IntegerField(default=0)

 _credit = models.DecimalField('Credit', decimal_places = 5,
 max_digits=11, null=True)

 @property
 def credit(self):
 return 0 if self._credit is None else self._credit

 @credit.setter
 def credit(self, value):
 self._credit = value


 In [7]: mk = Choice.objects.create(credit=123.3, poll_id=1)

 In [8]: mk
 Out[8]: 

 In [9]: mk.__dict__
 Out[9]:
 {'_credit': 123.3,
  '_state': ,
  'choice_text': u'',
  'id': 2,
  'poll_id': 1,
  'votes': 0}

 In [10]: ok = Choice.objects.update_or_create(defaults={'credit':123.3},
 poll_id=1)
 ---
 FieldErrorTraceback (most recent call
 last)
  in ()
 > 1 ok = Choice.objects.update_or_create(defaults={'credit':123.3},
 poll_id=1)

 /usr/local/lib/python2.7/site-packages/django/db/models/manager.pyc in
 manager_method(self, *args, **kwargs)
  83 def create_method(name, method):
  84 def manager_method(self, *args, **kwargs):
 ---> 85 return getattr(self.get_queryset(), name)(*args,
 **kwargs)
  86 manager_method.__name__ = method.__name__
  87 manager_method.__doc__ = method.__doc__

 /usr/local/lib/python2.7/site-packages/django/db/models/query.pyc in
 update_or_create(self, defaults, **kwargs)
 474 """
 475 defaults = defaults or {}
 --> 476 lookup, params = self._extract_model_params(defaults,
 **kwargs)
 477 self._for_write = True
 478 with transaction.atomic(using=self.db):

 /usr/local/lib/python2.7/site-packages/django/db/models/query.pyc in
 _extract_model_params(self, defaults, **kwargs)
 530 "Invalid field name(s) for model %s: '%s'." % (
 531 self.model._meta.object_name,
 --> 532 "', '".join(sorted(invalid_params)),
 533 ))
 534 return lookup, params

 FieldError: Invalid field name(s) for model Choice: 'credit'.
 }}}

--

Comment (by Alex Mykyta):

 Whoops. Sorry, still figuring out the contribution process.

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

[Django] #28224: Test suite exception catching is not always specific

2017-05-19 Thread Django

#28224: Test suite exception catching is not always specific
-+-
   Reporter:  Mads   |  Owner:  nobody
  Jensen |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Core   |Version:  master
  (Other)|
   Severity:  Normal |   Keywords:  exception classes
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `tests/requests/tests.py` contains some less specific tests. Actually,
 it's `DisallowedHost` that's being raised instead for all of these cases.
 Isn't it better in general to test for the actual exception class?
 Probably there are other cases of tests like this that could be made more
 specific.

 {{{
 with self.assertRaises(SuspiciousOperation):
 }}}

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

Re: [Django] #24747: Allow transforms in order_by

2017-05-19 Thread Django

#24747: Allow transforms in order_by
-+-
 Reporter:  Ben Buchwald |Owner:  Matthew
 |  Wilkes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Matthew Wilkes):

 * owner:  nobody => Matthew Wilkes
 * status:  new => assigned


Comment:

 I'm having a go at this between talks at PyCon.

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

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

2017-05-19 Thread Django

#28210: `._state.adding` behaviour and model inheritance
-+-
 Reporter:  Ivaylo Donchev   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Tim, I think the reporter was referring to form validation generating a
 `form.errors` along the dict he provided.

 Unique field validation relies on the `_state.adding` flag to determine
 [https://github.com/django/django/blob/master/django/db/models/base.py#L1013
 whether or not it should run].

 An appropriate test in this case would be along the lines of

 {{{#!python
 child = Child.objects.create()
 self.assertFalse(child.parent_ptr._state.adding)
 }}}

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

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

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

2017-05-19 Thread Django

#28210: `._state.adding` behaviour and model inheritance
-+-
 Reporter:  Ivaylo Donchev   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Let's say we have the following models:
> {{{
> class User(models.Model):
> email = models.CharField(max_length=255, unique=True)
> password = models.CharField(max_length=32,
> widget=forms.PasswordInput)
>
> class Admin(User):
> pass
>
> class ThirdPartyUser(User):
> pass
> }}}
>
> Steps to reproduce:
> 1. {{{ admin = Admin.objects.create(email='ad...@admin.com') }}}
>

> This will create an Admin instance and User instance, with
> `admin.user_ptr._state.adding == True`
>
> 2. {{{ ThirdPartyUser.objects.create(user_ptr = admin.user_ptr) }}}
>

> This will raise the following error `{'email': ['User with this Email
> address already exists.'], 'id': ['User with this ID already exists.'] }`
> When the admin is created, the `admin.user_ptr._state.adding` is True,
> but admin._state.adding is False (as it is already created).
> If we set {{{ admin.user_ptr._state.adding = False }}}, step 2 is passing
> without errors.

New description:

 Let's say we have the following models:
 {{{
 class User(models.Model):
 email = models.CharField(max_length=255, unique=True)
 password = models.CharField(max_length=32)

 class Admin(User):
 pass

 class ThirdPartyUser(User):
 pass
 }}}

 Steps to reproduce:
 1. {{{ admin = Admin.objects.create(email='ad...@admin.com') }}}


 This will create an Admin instance and User instance, with
 `admin.user_ptr._state.adding == True`

 2. {{{ ThirdPartyUser.objects.create(user_ptr = admin.user_ptr) }}}


 This will raise the following error `{'email': ['User with this Email
 address already exists.'], 'id': ['User with this ID already exists.'] }`
 When the admin is created, the `admin.user_ptr._state.adding` is True, but
 admin._state.adding is False (as it is already created).
 If we set {{{ admin.user_ptr._state.adding = False }}}, step 2 is passing
 without errors.

--

Comment (by Tim Graham):

 I can't reproduce using the steps described in the description. How does
 `ThirdPartyUser.objects.create()` raise a dictionary? Please clarify.

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

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

Re: [Django] #28223: Form not always picklable due to template renderer (was: Form not always picklable)

2017-05-19 Thread Django

#28223: Form not always picklable due to template renderer
--+
 Reporter:  Claude Paroz  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

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

Re: [Django] #28222: Django 1.11 update_or_create field validation results in different behaviours between create and update_or_create

2017-05-19 Thread Django

#28222: Django 1.11 update_or_create field validation results in different
behaviours between create and update_or_create
-+-
 Reporter:  Alex Mykyta  |Owner:  Alex
 |  Mykyta
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.11 | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Ready for checkin => Accepted


Comment:

 Please move the pastebin content (which expires in 1 day) to the ticket's
 description.

 The "Ready for checkin" status is set by a patch reviewer, not the patch
 author.

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

Re: [Django] #28222: Django 1.11 update_or_create field validation results in different behaviours between create and update_or_create

2017-05-19 Thread Django

#28222: Django 1.11 update_or_create field validation results in different
behaviours between create and update_or_create
-+-
 Reporter:  Alex Mykyta  |Owner:  Alex
 |  Mykyta
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.11 | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alex Mykyta):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Ready for checkin


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

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

Re: [Django] #28205: Document that ModelAdmin.prepopulated_fields only works on empty forms

2017-05-19 Thread Django

#28205: Document that ModelAdmin.prepopulated_fields only works on empty forms
-+-
 Reporter:  Ju   |Owner:  James
 Type:   |  Seden Smith
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  prepopulated_fields  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by James Seden Smith):

 * status:  new => assigned
 * owner:  nobody => James Seden Smith


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

[Django] #28223: Form not always picklable

2017-05-19 Thread Django

#28223: Form not always picklable
+
   Reporter:  Claude Paroz  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Forms |Version:  1.11
   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'm confronted with a random pickling issue with some forms in Django
 1.11.
 The error is :  `PicklingError: Can't pickle : attribute
 lookup __builtin__.function failed`

 I tracked the pickling error to the
 Form.renderer.engine.engine.template_libraries dict.

 I can more or less reproduce (different error message, but hopefully same
 cause) with:
 {{{
 from django.forms.renderers import get_default_renderer
 import pickle
 renderer = get_default_renderer()
 renderer.engine
 pickle.dumps(renderer)

 PicklingError: Can't pickle : it's not the same object as
 django.contrib.admin.templatetags.admin_urls.add_preserved_filters
 }}}

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

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

Re: [Django] #373: Add support for multiple-column primary keys

Re: [Django] #28212: Allow customizing the port that LiveServerTestCase uses

Re: [Django] #28212: Allow customizing the port that LiveServerTestCase uses

Re: [Django] #18332: No generic way to get database backend version

[Django] #28226: Remove use of deprecated ''.join() pattern

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

Re: [Django] #28224: Use more specific exception testing in Django's tests (was: Test suite exception catching is not always specific)

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

Re: [Django] #28225: Credentials of the Admin login form are stored browser due autocomplete was enabled by default.

Re: [Django] #28017: Add option to specify a different secret to PasswordResetTokenGenerator

[Django] #28225: Credentials of the Admin login form are stored browser due autocomplete was enabled by default.

Re: [Django] #28222: Django 1.11 update_or_create field validation results in different behaviours between create and update_or_create

[Django] #28224: Test suite exception catching is not always specific

Re: [Django] #24747: Allow transforms in order_by

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

Re: [Django] #28223: Form not always picklable due to template renderer (was: Form not always picklable)

Re: [Django] #28222: Django 1.11 update_or_create field validation results in different behaviours between create and update_or_create

Re: [Django] #28222: Django 1.11 update_or_create field validation results in different behaviours between create and update_or_create

Re: [Django] #28205: Document that ModelAdmin.prepopulated_fields only works on empty forms

[Django] #28223: Form not always picklable

23 matches

Site Navigation

Mail list logo

Footer information