Re: [Django] #26028: Improve instructions for overriding Django templates

[Django]

#26028: Improve instructions for overriding Django templates
---+
 Reporter:  pydanny|Owner:  phildini
 Type:  New feature|   Status:  assigned
Component:  Documentation  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by berkerpeksag):

 * cc: berker.peksag@… (added)
 * needs_better_patch:  0 => 1


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

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

Re: [Django] #26744: Accept-Language header parsing accepts some invalid q values

[Django]

#26744: Accept-Language header parsing accepts some invalid q values
-+-
 Reporter:  vytisb   |Owner:  vytisb
 Type:  Bug  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * component:  Utilities => Internationalization


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

Re: [Django] #26746: Accept-Language header parsing incorrectly transforms q=0 into q=1

[Django]

#26746: Accept-Language header parsing incorrectly transforms q=0 into q=1
--+
 Reporter:  vytisb|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * component:  Utilities => Internationalization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 The fallback to "1.0" is present since the `Accept-Language` parsing was
 introduced in 842a771e0527c36a9bcb3984057bb30903e71af3 (tests added in the
 next commit: a14256aade963929743aa09e0834f5fc4072f772).

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

Re: [Django] #26744: Accept-Language header parsing accepts some invalid q values

[Django]

#26744: Accept-Language header parsing accepts some invalid q values
---+--
 Reporter:  vytisb |Owner:  vytisb
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
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:"f1b38842afc50a51b7e6d180ddebbf7c48067e46" f1b38842]:
 {{{
 #!CommitTicketReference repository=""
 revision="f1b38842afc50a51b7e6d180ddebbf7c48067e46"
 Fixed #26744 -- Fixed a typo in regex for Accept-Language header parsing.
 }}}

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

Re: [Django] #26745: Add the ability to customize user creation in the createsuperuser command (was: Add the possibilty to extend the createsuper user command)

[Django]

#26745: Add the ability to customize user creation in the createsuperuser 
command
--+--
 Reporter:  Lyra2108  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 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 timgraham):

 Of course a signal could check the `is_superuser` attribute and act
 accordingly. Whether or not the use case also applies to superusers
 created in other ways is of course another question.

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

Re: [Django] #26747: Use more specific assertions in tests

[Django]

#26747: Use more specific assertions in tests
--+
 Reporter:  jdufresne |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * component:  Uncategorized => Core (Other)
 * stage:  Unreviewed => Accepted


Comment:

 As noted on the PR, I'm not convinced about the merits of
 `assertTrue`/`False` rather than `assertEqual(val, True)` since such the
 former pass if bool(val) is `True`/`False` which might be too loose.

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

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

Re: [Django] #26729: TabularInline not respecting form's custom label and help text if set in form's __init__ method

[Django]

#26729: TabularInline not respecting form's custom label and help text if set in
form's __init__ method
---+
 Reporter:  nrogers64  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by timgraham):

 I'd agree with that analysis. Did you look into why it works for
 `StackedInline`.

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

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

Re: [Django] #26731: UnicodeDecodeError when writing unicode to stdout of management command

[Django]

#26731: UnicodeDecodeError when writing unicode to stdout of management command
-+-
 Reporter:  dhobbs   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.8
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Tests aren't passing on Windows.

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

Re: [Django] #26736: SpatialReference crashes when initialized with WKT containining unicode characters

[Django]

#26736: SpatialReference crashes when initialized with WKT containining unicode
characters
+-
 Reporter:  sir-sigurd  |Owner:  sir-sigurd
 Type:  Bug |   Status:  closed
Component:  GIS |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"6928ad184e19795705790d536a7e7d7774da307d" 6928ad18]:
 {{{
 #!CommitTicketReference repository=""
 revision="6928ad184e19795705790d536a7e7d7774da307d"
 Fixed #26736 -- Fixed crashes in SpatialReference with non-ASCII
 characters.
 }}}

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

Re: [Django] #26743: DeserializationError local variable 'pk' referenced before assignment (which hides real error)

[Django]

#26743: DeserializationError local variable 'pk' referenced before assignment
(which hides real error)
--+
 Reporter:  lakinwecker   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * stage:  Unreviewed => Accepted


Comment:

 I guess it's probably a legitimate bug, but if someone cannot reproduce it
 upon investigation, feel free to close as "needsinfo".

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

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

Re: [Django] #26729: TabularInline not respecting form's custom label and help text if set in form's __init__ method

[Django]

#26729: TabularInline not respecting form's custom label and help text if set in
form's __init__ method
---+
 Reporter:  nrogers64  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 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 czpython):

 * Attachment "26729.diff" added.


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

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

Re: [Django] #26729: TabularInline not respecting form's custom label and help text if set in form's __init__ method

[Django]

#26729: TabularInline not respecting form's custom label and help text if set in
form's __init__ method
---+
 Reporter:  nrogers64  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by czpython):

 I've done a little digging on this.
 The problem is that the field labels need to be resolved before rendering
 the forms and so currently Django will look at the
 {{{base_fields}}} attribute of the formset form class instead of creating
 an instance of the form class. This means that the {{{__init__}}} method
 is never called when generating the table headers and so no modifications
 there will be considered.

 As a solution we would create a throw away instance of the formset form
 class and fetch the field from its {{{fields}}} attribute but I don't like
 the idea of creating an empty form instance without the developer having a
 way to modify its initialization arguments.

 I've attached a path for the suggested solution.

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

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

Re: [Django] #26747: Use more specific assertions in tests

[Django]

#26747: Use more specific assertions in tests
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jdufresne):

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


Comment:

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

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

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

[Django] #26747: Use more specific assertions in tests

[Django]

#26747: Use more specific assertions in tests
--+
 Reporter:  jdufresne |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Like #23620. I found more patterns that could use more specific
 assertions.

 Example patterns:

 {{{
 #!python
 self.assertEqual(expression, False)
 self.assertEqual(expression, True)
 self.assertEqual(expression, None)
 self.assertNotEqual(expression, None)
 }}}

 Will change these to:

 {{{
 #!python
 self.assertFalse(expression)
 self.assertTrue(expression)
 self.assertIsNone(expression)
 self.assertIsNotNone(expression)
 }}}

 Python docs on assertions: https://docs.python.org/3/library/unittest.html
 #assert-methods

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

[Django] #26746: Accept-Language header parsing incorrectly transforms q=0 into q=1

[Django]

#26746: Accept-Language header parsing incorrectly transforms q=0 into q=1
+
 Reporter:  vytisb  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Utilities   |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Given an Accept-Language header `en;q=0`, `parse_accept_lang_header`
 returns `[('en', 1.0)]`, which makes `en` the most preferable language in
 this case.
 According to [https://tools.ietf.org/html/rfc7231#section-5.3.1 RFC 7231],
 this should not happen.

 Also interesting that we have
 
[https://github.com/django/django/blob/bb7bb379e8cd91a91336946829519d64e919a1d2/tests/i18n/tests.py#L1318
 a test for this behavior].

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

Re: [Django] #26677: Run i18n tests on disposable FS tree instead of source code

[Django]

#26677: Run i18n tests on disposable FS tree instead of source code
-+-
 Reporter:  ramiro   |Owner:  ramiro
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  tests isolation  | Triage Stage:  Ready for
  i18n serializemixin unit unittest  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ramiro Morales ):

 In [changeset:"bb7bb379e8cd91a91336946829519d64e919a1d2" bb7bb37]:
 {{{
 #!CommitTicketReference repository=""
 revision="bb7bb379e8cd91a91336946829519d64e919a1d2"
 Refs #26677 -- Simplified i18n test cleanups.

 The fact that we aren't dealing with the Django source tree anymore
 allows us to drop several tearDown()/addCleanup() calls that were
 concerned with removing apiece files/dirs/symlinks created by test
 cases, as we are covered by the removal of the parent temporary tree
 anyways.

 Thanks Tim Graham for advice and 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/064.997cb5850231c3eb89d9306c7a95df73%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26745: Add the possibilty to extend the createsuper user command

[Django]

#26745: Add the possibilty to extend the createsuper user command
--+--
 Reporter:  Lyra2108  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 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 apollo13):

 I am not particularly fond of either solution.

  * Signal registration is global and would happen for every user not just
 the superuser
  * A custom manager seems overkill if all you want is to add some data
 somewhere and do not have your own user model
  * Overriding the command is still work but probably the best solution
 suggested

 Another option: Stuff something onto AppConfig and make create_superuser
 use
 `apps.get_app_config(get_user_model()._meta.app_label).create_superuser`
 which by default just be (ie if not defined):
 ```
 UserModel._default_manager.db_manager(database).create_superuser(**user_data)
 ```

 I think pre/post are overkill, someone customizing that can as well just
 write the create_superuser line too.

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