Re: [Django] #30393: Add validation of target argument in startapp command.

[Django]

#30393: Add validation of target argument in startapp command.
-+-
 Reporter:  oliver   |Owner:  oliver
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"fc9566d42daf28cdaa25a5db1b5ade253ceb064f" fc9566d]:
 {{{
 #!CommitTicketReference repository=""
 revision="fc9566d42daf28cdaa25a5db1b5ade253ceb064f"
 Fixed #30393 -- Added validation of startapp's directory option.
 }}}

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

Re: [Django] #29338: Can't use OuterRef in union Subquery

[Django]

#29338: Can't use OuterRef in union Subquery
-+-
 Reporter:  Matthew Pava |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Asif Saifuddin Auvi):

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

Re: [Django] #28408: Incorrect error message with QuerySet.update() that requires a join on an annotated F expression

[Django]

#28408: Incorrect error message with QuerySet.update() that requires a join on 
an
annotated F expression
-+-
 Reporter:  Kevin Marsh  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  annotate, F, update  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Asif Saifuddin Auvi):

 * needs_docs:  1 => 0


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

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

Re: [Django] #30351: Migration auth.0011_update_proxy_permissions fails for models recreated as a proxy.

[Django]

#30351: Migration auth.0011_update_proxy_permissions fails for models recreated 
as
a proxy.
-+-
 Reporter:  Julien Enselme   |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  2.2
 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 Carlton Gibson):

 * owner:  (none) => Carlton Gibson
 * status:  new => assigned


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

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

Re: [Django] #30351: Migration auth.0011_update_proxy_permissions fails for models recreated as a proxy.

[Django]

#30351: Migration auth.0011_update_proxy_permissions fails for models recreated 
as
a proxy.
-+-
 Reporter:  Julien Enselme   |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  2.2
 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 Carlton Gibson):

 I'll make a patch for this.

 I'll see about raising a suitable warning from the migration but we
 already warn in the release notes for this to audit permissions: my
 initial thought was that re-using the permission would be OK. (I see
 Arthur's comment. Other thoughts?)

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

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

Re: [Django] #30318: Add new system check message when custom error handler 'path.to.view' cannot be imported

[Django]

#30318: Add new system check message when custom error handler 'path.to.view'
cannot be imported
-+-
 Reporter:  Alasdair Nicol   |Owner:  Alasdair
 |  Nicol
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  2.2
  checks)|
 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 felixxm):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #30351: Migration auth.0011_update_proxy_permissions fails for models recreated as a proxy.

[Django]

#30351: Migration auth.0011_update_proxy_permissions fails for models recreated 
as
a proxy.
-+-
 Reporter:  Julien Enselme   |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  2.2
 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 Arthur Rio):

 Being my first contribution I wanted to be super (super) careful with
 security concerns, but given the existing warning in the release notes for
 auditing prior to update, I agree that re-using the permission feels
 pretty safe and would remove overhead for people running into this
 scenario.

 Thanks for taking this on Carlton, I'd be happy to 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/066.3529f406f4f51c348529f00226c9f9d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30397: Allow app_label and class to be specified in the name argument for indexes and constraints.

[Django]

#30397: Allow app_label and class to be specified in the name argument for 
indexes
and constraints.
-+-
 Reporter:  felixxm  |Owner:  Can
 |  Sarıgöl
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * owner:  nobody => Can Sarıgöl
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/11279 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/065.b5e868fec2b10582ba4ecbc5f3663137%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30396: Add a system check for uniqueness of partial indexes and constraints names.

[Django]

#30396: Add a system check for uniqueness of partial indexes and constraints 
names.
-+-
 Reporter:  felixxm  |Owner:  Can
 Type:   |  Sarıgöl
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

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

Re: [Django] #30318: Add new system check message when custom error handler 'path.to.view' cannot be imported

[Django]

#30318: Add new system check message when custom error handler 'path.to.view'
cannot be imported
-+-
 Reporter:  Alasdair Nicol   |Owner:  Alasdair
 |  Nicol
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  2.2
  checks)|
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"a5accc0368c6575b55976c06af36ed399c85c781" a5accc0]:
 {{{
 #!CommitTicketReference repository=""
 revision="a5accc0368c6575b55976c06af36ed399c85c781"
 Fixed #30318 -- Added check for importability of arguments of custom error
 handler views.

 Thanks to Jon on Stack Overflow for reporting the issue.
 }}}

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

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

Re: [Django] #30318: Add new system check message when custom error handler 'path.to.view' cannot be imported

[Django]

#30318: Add new system check message when custom error handler 'path.to.view'
cannot be imported
-+-
 Reporter:  Alasdair Nicol   |Owner:  Alasdair
 |  Nicol
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  2.2
  checks)|
 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 Mariusz Felisiak ):

 In [changeset:"3c3df7db8e5ce7882d6a8379fc2d0f82330114f1" 3c3df7db]:
 {{{
 #!CommitTicketReference repository=""
 revision="3c3df7db8e5ce7882d6a8379fc2d0f82330114f1"
 [2.2.x] Fixed #30318 -- Added check for importability of arguments of
 custom error handler views.

 Thanks to Jon on Stack Overflow for reporting the issue.

 Backport of a5accc0368c6575b55976c06af36ed399c85c781 from master
 }}}

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

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

Re: [Django] #30400: Improve typography of user facing strings.

[Django]

#30400: Improve typography of user facing strings.
-+-
 Reporter:  Jon Dufresne |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   Status:  assigned
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
-+-

Comment (by Claude Paroz):

 As for me, #30184 is hopefully not the last word on this issue. Preventing
 all users from having good typographic output (that is real readability
 improvements) just because some systems will not make the effort to
 transition to UTF-8 is not fair.
 As we are wrapping those outputs anyway, I think that we should be able to
 detect the output encoding, and add some ascii simplification/conversion
 when the output does not support UTF-8.

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

Re: [Django] #30399: Use Python stdlib html.escape() to in django.utils.html.escape()

[Django]

#30399: Use Python stdlib html.escape() to in django.utils.html.escape()
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

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

[Django] #30402: Django default_site admin configuration doesn't register anything

[Django]

#30402: Django default_site admin configuration doesn't register anything
-+
   Reporter:  Destroy666x|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  2.2
   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  |
-+
 Steps:
 1. I have project X with app Y, which has admin folder with site.py and
 multiple specific_model.py.
 2. In site.py I extend AdminSite with SocialAuthAdminSite.
 3. In specific_model.py files I use admin.site.register(Model, ModelAdmin)
 4. In project/apps.py I extend AdminConfig with SocialAuthAdminConfig
 which has default_site = 'X.Y.admin.site.SocialAuthAdminSite'
 5. In settings I load X.apps.SocialAuthAdminConfig

 Expected:
 Admin classes for models should be registered like they were before I made
 edits to use default_site (before I just assigned the site to a variable
 and used that).

 Actual:
 Admin classes for models are not registered. The customized admin works
 otherwise though.

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

Re: [Django] #30402: Django default_site admin configuration doesn't register anything

[Django]

#30402: Django default_site admin configuration doesn't register anything
---+--
 Reporter:  Destroy666x|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Destroy666x:

Old description:

> Steps:
> 1. I have project X with app Y, which has admin folder with site.py and
> multiple specific_model.py.
> 2. In site.py I extend AdminSite with SocialAuthAdminSite.
> 3. In specific_model.py files I use admin.site.register(Model,
> ModelAdmin)
> 4. In project/apps.py I extend AdminConfig with SocialAuthAdminConfig
> which has default_site = 'X.Y.admin.site.SocialAuthAdminSite'
> 5. In settings I load X.apps.SocialAuthAdminConfig
>
> Expected:
> Admin classes for models should be registered like they were before I
> made edits to use default_site (before I just assigned the site to a
> variable and used that).
>
> Actual:
> Admin classes for models are not registered. The customized admin works
> otherwise though.

New description:

 Steps:
 1. I have project X with app Y, which has admin folder with site.py and
 multiple specific_model.py.
 2. In site.py I extend AdminSite with SocialAuthAdminSite.
 3. In specific_model.py files I use admin.site.register(Model, ModelAdmin)
 4. In project/apps.py I extend AdminConfig with SocialAuthAdminConfig
 which has default_site = 'X.Y.admin.site.SocialAuthAdminSite'
 5. In settings I load X.apps.SocialAuthAdminConfig (tried at the
 beginnning, end, etc. - I don't think it matters)

 Expected:
 Admin classes for models should be registered like they were before I made
 edits to use default_site (before I just assigned the site to a variable
 and used that).

 Actual:
 Admin classes for models are not registered. The customized admin works
 otherwise though.

--

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

Re: [Django] #30400: Improve typography of user facing strings.

[Django]

#30400: Improve typography of user facing strings.
-+-
 Reporter:  Jon Dufresne |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   Status:  assigned
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
-+-

Comment (by Nick Pope):

 Agreed - It seems a shame that we can't have nice things because the
 Windows Command Prompt has been neglected for so long.

 There is an interesting [https://bit.ly/2GBAJY6 article] on how this is
 already being fixed, but it will take time until the majority of users do
 not have a broken command prompt.

 I was already looking into sprucing up some of the command output and was
 considering the exact same possibility of substituting some ASCII
 alternatives on terminals that do not support UTF-8. Give me a few weeks
 and I'll resurrect my branch for this to see if there is a possible way
 forward.

 In the meantime, we should stick with the policy of not supporting unicode
 in shell output.

 Also, out of interest, we only support Python 3.6+ for Django 3.0 which
 includes [https://docs.python.org/3/whatsnew/3.6.html#pep-528-change-
 windows-console-encoding-to-utf-8 PEP 528] and
 [https://docs.python.org/3/whatsnew/3.6.html#pep-529-change-windows-
 filesystem-encoding-to-utf-8 PEP 529] and this may mean that issues such
 as #30184 and #30324 become a thing of the past anyway. I haven't tested
 this to make sure though, and the ability to disable unicode shell output
 would be a good idea anyway.

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

Re: [Django] #30399: Use Python stdlib html.escape() to in django.utils.html.escape()

[Django]

#30399: Use Python stdlib html.escape() to in django.utils.html.escape()
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Super. Thanks all!

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

Re: [Django] #30399: Use Python stdlib html.escape() to in django.utils.html.escape()

[Django]

#30399: Use Python stdlib html.escape() to in django.utils.html.escape()
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 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 Carlton Gibson ):

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


Comment:

 In [changeset:"8d76443aba863b75ad3b1392ca7e1d59bad84dc4" 8d76443a]:
 {{{
 #!CommitTicketReference repository=""
 revision="8d76443aba863b75ad3b1392ca7e1d59bad84dc4"
 Fixed #30399 -- Changed django.utils.html.escape()/urlize() to use
 html.escape()/unescape().
 }}}

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

Re: [Django] #30400: Improve typography of user facing strings.

[Django]

#30400: Improve typography of user facing strings.
-+-
 Reporter:  Jon Dufresne |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   Status:  assigned
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
-+-

Comment (by Carlton Gibson):

 +1 there. We should be able to push users forward at this point in
 history.

 Not exactly the same issue but we had a user on Django Dev hitting a
 unicode error on macOS too, which means they’d set a non-unicode locale
 (for unknown reason). I feel like we should be able to emit a decent
 warning in this kind of case linking to a doc explaining what they need to
 do. (I’ve found myself on servers with broken/primitive locales plenty of
 times too… similar would help there.)

 Anyhow, that’s just emoting at this point.

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

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

Re: [Django] #30388: inspectdb generates unique ForeignKey instead of OneToOneField.

[Django]

#30388: inspectdb generates unique ForeignKey instead of OneToOneField.
-+-
 Reporter:  Ville Skyttä |Owner:  Ville
 Type:   |  Skyttä
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"85676979a4845fa9b586ec42d4ddbdb9f28b7cc8" 85676979]:
 {{{
 #!CommitTicketReference repository=""
 revision="85676979a4845fa9b586ec42d4ddbdb9f28b7cc8"
 Refs #30388 -- Added release note for
 0f22671ecb7e9555300fd2d6cb7bf6dc61735d07.
 }}}

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

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

[Django] #30403: Test namespace packages discover fails to load module

[Django]

#30403: Test namespace packages discover fails to load module
-+-
   Reporter:  Jonny  |  Owner:  nobody
  Fuller |
   Type:  Bug| Status:  new
  Component:  Testing|Version:  2.2
  framework  |
   Severity:  Normal |   Keywords:  namespace packages
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello friends. Test discovery with namespaced
 [https://packaging.python.org/guides/packaging-namespace-packages/
 packages] fails when selecting a subpackage because of the way unittest
 discover evaluates paths. A reproducible example repository and full
 documentation can be found
 [https://github.com/JonnyWaffles/djangonamespacetestfail here]. However,
 if you test the entire namespace, or a specific test module, everything
 works.

 I'm not sure what the solution is, but it may have something to do with
 how the test runner calls discover.

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

Re: [Django] #30403: Test namespace packages discover fails to load module

[Django]

#30403: Test namespace packages discover fails to load module
+--
 Reporter:  Jonny Fuller|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Testing framework   |  Version:  2.2
 Severity:  Normal  |   Resolution:
 Keywords:  namespace packages  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by Jonny Fuller:

Old description:

> Hello friends. Test discovery with namespaced
> [https://packaging.python.org/guides/packaging-namespace-packages/
> packages] fails when selecting a subpackage because of the way unittest
> discover evaluates paths. A reproducible example repository and full
> documentation can be found
> [https://github.com/JonnyWaffles/djangonamespacetestfail here]. However,
> if you test the entire namespace, or a specific test module, everything
> works.
>
> I'm not sure what the solution is, but it may have something to do with
> how the test runner calls discover.

New description:

 Hello friends. Test discovery with namespaced
 [https://packaging.python.org/guides/packaging-namespace-packages/
 packages] fails when selecting a subpackage because of the way unittest
 discover evaluates paths. A reproducible example repository and full
 documentation can be found
 [https://github.com/JonnyWaffles/djangonamespacetestfail here]. However,
 if you test the entire namespace, or a specific test module, everything
 works.

 I'm not sure what the solution is, but it may have something to do with
 how the test runner calls discover.

  I tried the same situation with just the normal Python unittest
 module discovery and it still occurs. Looks like this may be a Python
 problem and not a Django problem.

--

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

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

Re: [Django] #30386: Admin foreign key widgets don't quote keys.

[Django]

#30386: Admin foreign key widgets don't quote keys.
+
 Reporter:  Joshua Goodwin  |Owner:  zeynel
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by zeynel):

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

Re: [Django] #26552: `TransactionTestCase.serialized_rollback` fails to restore objects due to ordering constraints

[Django]

#26552: `TransactionTestCase.serialized_rollback` fails to restore objects due 
to
ordering constraints
---+
 Reporter:  Aymeric Augustin   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Fabio Caritas Barrionuevo da Luz):

 * cc: Fabio Caritas Barrionuevo da Luz (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.e267eb7f08cf338fa9e0d83d4e891cde%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30404: Docs: "Using a model formset in a view" example does not handle the case where validation fails on POST

[Django]

#30404: Docs: "Using a model formset in a view" example does not handle the case
where validation fails on POST
---+
   Reporter:  Stephen G Tuggy  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Documentation|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|
---+
 The URL is here:
 [https://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-a
 -model-formset-in-a-view] The 2.2 and 1.8 documentation versions suffer
 from the same problem (and probably every other version in between).

 You will notice that the Method-Based View `manage_authors` handles the
 case where `request.method == 'POST'` and `formset.is_valid()`, but
 **not** the case where `request.method == 'POST'` and `formset` is not
 valid. As a result, newbies (like myself) following this example may not
 implement this case either. Then, if the data POSTed to this view passes
 client-side validation but not server-side validation, the user will get
 an error message:

 `The view '...' didn't return an HttpResponse object. It returned None
 instead`

 See this StackOverflow post, for example:
 [https://stackoverflow.com/questions/50202477/the-view-blog-views-post-
 list-didnt-return-an-httpresponse-object-it-returned?rq=1] And this post:
 [https://www.freecodecamp.org/forum/t/didnt-return-an-httpresponse-object-
 it-returned-none-instead/216155/2]

 As far as I have been able to determine, the correct code behavior in this
 situation is pretty much the same as what you do for a GET: Construct a
 context dictionary, starting with RequestContext, then return the result
 of rendering the formset once more. One caveat: Make sure your template
 has a spot to display non-field errors.

 Is this correct? Thank you for your attention.

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

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

Re: [Django] #30231: Field's verbose_name is ignored in FilteredSelectMultiple widget for inlines created with "Add another" button

[Django]

#30231: Field's verbose_name is ignored in FilteredSelectMultiple widget for
inlines created with "Add another" button
-+-
 Reporter:  Florian Schuler  |Owner:  Teresa
 |  Partida
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Teresa Partida):

 Hi! I submitted a new patch with the changes Florian made and the Selenium
 test
 https://github.com/django/django/pull/11282

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

[Django] #30405: IndexError in _get_lines_from_file when module does not match file contents (via loader)

[Django]

#30405: IndexError in _get_lines_from_file when module does not match file 
contents
(via loader)
---+
   Reporter:  Daniel Hahler|  Owner:  (none)
   Type:  Bug  | Status:  new
  Component:  Error reporting  |Version:  2.2
   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|
---+
 {{{
 self = 
 filename = '…/project/.venv/lib/python3.7/site-packages/pdb.py'
 lineno = 230
 context_lines = 7
 loader = <_frozen_importlib_external.SourceFileLoader object at
 0x7f2a73609278>
 module_name = 'pdb'

 [23]
 …/Vcs/django/django/core/handlers/exception.py(90)response_for_exception()
 -> response = handle_uncaught_exception(request,
 get_resolver(get_urlconf()), sys.exc_info())
 [24]
 …/Vcs/django/django/core/handlers/exception.py(125)handle_uncaught_exception()
 -> return debug.technical_500_response(request, *exc_info)
 [25]   …/Vcs/django/django/views/debug.py(94)technical_500_response()
 -> html = reporter.get_traceback_html()
 [26]   …/Vcs/django/django/views/debug.py(333)get_traceback_html()
 -> c = Context(self.get_traceback_data(), use_l10n=False)
 [27]   …/Vcs/django/django/views/debug.py(264)get_traceback_data()
 -> frames = self.get_traceback_frames()
 [28]   …/Vcs/django/django/views/debug.py(427)get_traceback_frames()
 -> filename, lineno, 7, loader, module_name,

  385 try:
  386 context_line = source[lineno]
  387 except:
  388 __import__('pdb').set_trace()
  389  -> post_context = source[lineno + 1:upper_bound]
  390
  391 return lower_bound, pre_context, context_line,
 post_context
 (Pdb++) source
 ['# this file is needed to hijack pdb without eggs', 'import os.path',
 "pdb_path = os.path.join(os.path.dirname(os.path.dirname(__file__)),
 'pdb.py')", 'with open(pdb_path) as f:', "exec(compile(f.read(),
 pdb_path, 'exec'))"]
 }}}

 It uses the loader
 
(https://github.com/django/django/blob/47885278c669dd7a13a4c3ff7e58e1cbe88af385/django/views/debug.py#L351),
 which picks up the `pth`, and then the contents does not match the
 expected line number.

 I think it should maybe always use the given filename?!

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

Re: [Django] #30404: "Using a model formset in a view" example doesn't handle invalid formset. (was: Docs: "Using a model formset in a view" example does not handle the case where validation fails on

[Django]

#30404: "Using a model formset in a view" example doesn't handle invalid 
formset.
-+-
 Reporter:  Stephen G Tuggy  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 |  worksforme
 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 felixxm):

 * status:  new => closed
 * resolution:   => worksforme
 * type:  Bug => Cleanup/optimization


Comment:

 Thanks for the report, however this code works for me. Please notice that
 `return` is outside `if ... else` block, so it is called even when form is
 invalid:
 {{{ #!python
 if request.method == 'POST':
 ...
 else:
 ...
 return render(request, 'manage_authors.html', {'formset': formset})
 }}}
 Maybe some indentation issue?

 Please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels].

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

Re: [Django] #30403: Test namespace packages discover fails to load module. (was: Test namespace packages discover fails to load module)

[Django]

#30403: Test namespace packages discover fails to load module.
+--
 Reporter:  Jonny Fuller|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Testing framework   |  Version:  2.2
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  namespace packages  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by felixxm):

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


Comment:

 Thanks for the report, however it is not an issue in Django. IMO
 `namespace/__init__.py` is missing. `touch namespace/__init__.py` fixed
 all issues for me.

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

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

Re: [Django] #30312: Admin app has too hard a dependency on sessions app

[Django]

#30312: Admin app has too hard a dependency on sessions app
-+-
 Reporter:  Aarni Koskela|Owner:  Aarni
 Type:   |  Koskela
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  2.2
 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 felixxm):

 * severity:  Normal => Release blocker


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

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

Re: [Django] #30402: Django default_site admin configuration doesn't register anything

[Django]

#30402: Django default_site admin configuration doesn't register anything
+--
 Reporter:  Przemek Pawlas  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:  worksforme
 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 felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => worksforme


Comment:

 Thanks for the report, however it works for me. Can you take a look at
 [https://docs.djangoproject.com/en/2.2/ref/contrib/admin/#overriding-the-
 default-admin-site overriding-the-default-admin-site] documentation  and
 double-check all steps? You can also check how we use it in our
 [https://github.com/django/django/tree/master/tests/admin_default_site
 test suite].

 Please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels] if you will have further questions.

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

Re: [Django] #30312: Admin app has too hard a dependency on sessions app

[Django]

#30312: Admin app has too hard a dependency on sessions app
-+-
 Reporter:  Aarni Koskela|Owner:  Aarni Koskela
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.2
 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 felixxm):

 * type:  Cleanup/optimization => Bug
 * severity:  Normal => Release blocker


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

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