date:20220121

Re: [Django] #32088: Django Database Sessions - Can't Retrieve expire_date from request.session (SessionStore)

2022-01-21 Thread Django

#32088: Django Database Sessions - Can't Retrieve expire_date from 
request.session
(SessionStore)
-+-
 Reporter:  Nate Pinchot |Owner:  Pallav
 |  Parikh
 Type:  New feature  |   Status:  new
Component:  contrib.sessions |  Version:  dev
 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 ahmadkhalili):

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


Comment:

 Replying to [comment:14 Carlton Gibson]:
 > HI Nate, yes, thanks.
 >
 > In the end I think that's something you should add to a custom backend.
 There's no reason you can't store the value in load, as you suggest, but
 in 15 years it's not been needed and adding complexity to the API here
 isn't something I think we should do for such a niche case.
 >
 I have this problem too, i wanted create new ticket but when i found this
 ticket it's made me happy. suppose we use database backend session, my
 experience to face this problem:

 {{{
 from datetime import datetime
 from django.contrib.sessions.backends.db import SessionStore

 my_session = SessionStore()
 # there is no session key specified, means we want create new db session
 probably
 session.get_expiry_date()
 # get_expiry_date() func tell us new created sessions expiration time(it
 is now in django 4, 14 day), that is logical and expected

 # we have specific session key means we want work on our db session and
 don't want new
 my_session = SessionStore('some_session_key')

 # get_expiry_date() always return new created sessions expiration time (14
 days after .now())
 if my_session.get_expiry_date() < datetime.now(): # so this is fail
 my_session.create()
 ...
 }}}


 Here in this example django force us using
 `my_session._get_session_from_db().expire_date` instead
 `my_session.get_expiry_date()`, but one simple question: why we should do
 additional work when we determined to django 'we have specific db session
 to work on it' ?

 All i want say in one sentence: get_expiry_date() should return expire
 date of current session but when we have not eny session yet(like
 `SessionStore()`) its logical get_expiry_date() returns new created
 sessions expiration time.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.8938d1988539bbefa75d6a539a3d9983%40djangoproject.com.

Re: [Django] #33457: Expanding local vars in technical 500 causes horizontal scrolling

2022-01-21 Thread Django

#33457: Expanding local vars in technical 500 causes horizontal scrolling
-+-
 Reporter:  Keryn Knight |Owner:
 |  Hrushikesh Vaidya
 Type:  Bug  |   Status:  assigned
Component:  Error reporting  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  technical debug 500  | Triage Stage:
  UI |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Hrushikesh Vaidya):

 * owner:  (none) => Hrushikesh Vaidya
 * status:  new => assigned
 * has_patch:  0 => 1
 * ui_ux:  0 => 1


Comment:

 [https://github.com/django/django/pull/15348 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1af4c5783787cdda6717847b29ce84b5%40djangoproject.com.

Re: [Django] #33458: Messages framework incorrectly serializes/deserializes extra_tags when it's an empty string

2022-01-21 Thread Django

#33458: Messages framework incorrectly serializes/deserializes extra_tags when 
it's
an empty string
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 |  McCurrach
 Type:  Bug  |   Status:  assigned
Component:  contrib.messages |  Version:  4.0
 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 Tim McCurrach):

 * owner:  nobody => Tim McCurrach
 * status:  new => assigned
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.ef0343c1142f2e16e2b737295dcc0423%40djangoproject.com.

[Django] #33458: Messages framework incorrectly serializes/deserializes extra_tags when it's an empty string

2022-01-21 Thread Django

#33458: Messages framework incorrectly serializes/deserializes extra_tags when 
it's
an empty string
+
   Reporter:  Tim McCurrach |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.messages  |Version:  4.0
   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 |
+
 When a message is serialised and then deserialised with any of the built
 in storage backends, then `extra_tags==""` is converted to
 `extra_tags==None`. This is because `MessageEncoder` checks for the
 truthyness of `extra_tags` rather than checking it is not `None`.

 === To replicate this bug ===

 {{{
 >>> from django.conf import settings
 >>> settings.configure()  # Just to allow the following import
 >>> from django.contrib.messages.storage.base import Message
 >>> from django.contrib.messages.storage.cookie import MessageEncoder,
 MessageDecoder
 >>> original_message = Message(10, "Here is a message", extra_tags="")
 >>> encoded_message = MessageEncoder().encode(original_message)
 >>> decoded_message = MessageDecoder().decode(encoded_message)
 >>> original_message.extra_tags == ""
 True
 >>> decoded_message.extra_tags is None
 True
 }}}

 === Effect of the bug in application behaviour ===
 This error occurred in the wild with a template tag similar to the
 following:
 {{{
 {% if x not in message.extra_tags %}
 }}}
 When the message was displayed as part of a redirect, it had been
 serialised and deserialized which meant that extra_tags was `None` instead
 of the empty string. This caused an error.

 It's important to note that this bug affects all of the standard API
 (`messages.debug`, `messages.info` etc. all have a default value of
 `extra_tags` equal to `""`).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/056.df37a3df3639ff8e90e314ef0266585c%40djangoproject.com.

Re: [Django] #33457: Expanding local vars in technical 500 causes horizontal scrolling

2022-01-21 Thread Django

#33457: Expanding local vars in technical 500 causes horizontal scrolling
-+-
 Reporter:  Keryn Knight |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  technical debug 500  | Triage Stage:
  UI |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Keryn Knight):

 * Attachment "te500-scroll.gif" added.

 animated gif showing the table's end being off-screen, forcing an
 horizontal scrollbar to appear when Local vars are toggled

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c9f8556e3ddbc6daccbdc59c4beda70d%40djangoproject.com.

[Django] #33457: Expanding local vars in technical 500 causes horizontal scrolling

2022-01-21 Thread Django

#33457: Expanding local vars in technical 500 causes horizontal scrolling
-+-
   Reporter:  Keryn  |  Owner:  (none)
  Knight |
   Type:  Bug| Status:  new
  Component:  Error  |Version:  dev
  reporting  |   Keywords:  technical debug 500
   Severity:  Normal |  UI
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Whilst working on a little alpha project to [https://github.com/kezabelle
 /django-technicalerrors provide alternate error pages], and comparing
 output, I noticed that expanding the `Local vars` seems to ''always''
 cause a horizontal scrollbar, at least at 1425x in Chrome.

 As far as I can tell from checking out git tags, this seems to occur at
 least back to 2.2 ( that can't be right, but OK!), and before that I
 start getting issues with code which has moved that my project doesn't
 support, so ... it may go back further.

 A cursory play around with my devtools suggests that the following fixes
 it:
 {{{
 table.vars {
 margin: 5px 10px 2px 40px;
 width: auto;
 }
 }}}
 Specifically:
 - Restore the `width` to not be `100%` (which is currently applied to all
 `table`) and use `auto` or `inherit` or `initial` instead.
 - Add `10px` right margin so the table lines up vertically with it's
 related context lines.

 Attaching a gif which shows a slice of 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.f718422c8aa064bcaa839562db3dc4d5%40djangoproject.com.

Re: [Django] #28889: Use JavaScript to prevent double submission of admin forms

2022-01-21 Thread Django

#28889: Use JavaScript to prevent double submission of admin forms
-+-
 Reporter:  Manuel Saelices  |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  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
-+-

Comment (by Marcelo Galigniana):

 Is there anything I can do to move this forward?

 Should I create a conversation at the django-developers google group?

 IMO the 2nd approach: "Disable buttons while submitting" it's simpler and
 works well!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.bd6250963c212cdbd8ba4d78de9427b1%40djangoproject.com.

Re: [Django] #26760: Delete nonexistent migrations from django_migrations table

2022-01-21 Thread Django

#26760: Delete nonexistent migrations from django_migrations table
-+-
 Reporter:  Jarek Glowacki   |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  django_migrations| Triage Stage:  Ready for
  squash migrations  |  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:"2d8232fa716f5fe46eec9f35a0e90c2d0f126279" 2d8232fa]:
 {{{
 #!CommitTicketReference repository=""
 revision="2d8232fa716f5fe46eec9f35a0e90c2d0f126279"
 Fixed #26760 -- Added --prune option to migrate command.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.603ead56ea33f6196304e807c4304e8b%40djangoproject.com.

Re: [Django] #33378: ImproperlyConfigured error is raised when installing apps in subdirectory

2022-01-21 Thread Django

Comment (by Zack West):

Thanks and sorry for the duplicate post. It wasn't so much the requirement
of the full path I noted as much as it was Django *generating* a non-
fullpath when running the `python manage.py startapp` command or, more
particularly, if one is in a subdirectory (e.g. apps/) and runs the
command `django-admin startapp myapp` the `name` field in
`apps/myapp/apps.py` config class gets auto-populated with just `myapp`
rather than the required `apps.myapp` which will throw a
`django.core.exceptions.ImproperlyConfigured` exception unless a user
manually updates the `name` field.

I understand if that was passed over but I wanted to ensure I was drawing
attention to the proper aspect of the issue.

Replying to [comment:1 Mariusz Felisiak]:
> Thanks for the report, however it works exactly the same in Django 3.2,
3.1, etc. I don't see any change in this behavior. `AppConfig.name` must
be a full Python path to the application, as

[https://docs.djangoproject.com/en/4.0/ref/applications/#django.apps.AppConfig.name
documented], so in your case `Apps.bestapp` is required and expected. We
tried to improve generated `apps.py` files in #30618 but it was clunky.
>
> Duplicate of #30618.

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.44c3275b70a8efa3ce360a816e47404d%40djangoproject.com.

Re: [Django] #33456: Make underscore in hostname error more explicit

2022-01-21 Thread Django

#33456: Make underscore in hostname error more explicit
-+-
 Reporter:  kimsia   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 > I will try to rewrite in a way that respects the existing if/else
 statement and yes i also note the number of tickets talking about this
 issue. Personally i just wasted a few hrs of my time because i didn't read
 the RFC close enough.

 I'm not sure that fixing this won't add more complexity than it's worth,
 but we could evaluate a patch. Please take into account that code added in
 [https://github.com/django/django/pull/15343 PR] is unreachable.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.97839a951676059df05286ba23f72447%40djangoproject.com.

Re: [Django] #33454: Django4 does not pick up tests according to tags. (was: Django4 does not pick up tests according to market value)

2022-01-21 Thread Django

#33454: Django4 does not pick up tests according to tags.
---+--
Reporter: Thorben Luepkes|Owner: nobody
Type: Bug| Status: closed
Component: Testing framework | Version: 4.0
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 Mariusz Felisiak):

* cc: Chris Jerdonek (added)
* status: new => closed
* resolution: => invalid

Comment:

Thanks for the report. This behavior was changed intentionally in
038940cf5525c41464a1b9e9ba3801042320b0cc. Previously tests that failed to
load did not match tags. I was able to fix the attached project
(`django4-testrunner`) by:
- removing the

[https://github.com/Thorbenl/django4-testrunner/blob/main/django4_testrunner/__init__.py
__init__.py] file from `django4_testrunner`,
- changing imports from `django4_testrunner.default.market_settings` to
`default.market_settings`.

It looks like an issue in your code.

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.4bac65b1add3eae044a22058af5cfacf%40djangoproject.com.

Re: [Django] #33456: Make underscore in hostname error more explicit

2022-01-21 Thread Django

#33456: Make underscore in hostname error more explicit
-+-
 Reporter:  kimsia   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kimsia):

 Replying to [comment:4 Florian Apolloner]:
 > Given that we already have an if/else there and it seems to be a
 somewhat common issue that can also reduce the number of tickets created I
 am a slight +0 for accepting, but I do not feel strongly.

 I will try to rewrite in a way that respects the existing if/else
 statement and yes i also note the number of tickets talking about this
 issue. Personally i just wasted a few hrs of my time because i didn't read
 the RFC close enough.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.575a27c9620df61a112501ef231afdba%40djangoproject.com.

Re: [Django] #33456: Make underscore in hostname error more explicit

2022-01-21 Thread Django

#33456: Make underscore in hostname error more explicit
-+-
 Reporter:  kimsia   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 Given that we already have an if/else there and it seems to be a somewhat
 common issue that can also reduce the number of tickets created I am a
 slight +0 for accepting, but I do not feel strongly.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.413814b1dbc995c2cb9198a0701a8eec%40djangoproject.com.

Re: [Django] #33456: Make underscore in hostname error more explicit

2022-01-21 Thread Django

#33456: Make underscore in hostname error more explicit
-+-
 Reporter:  kimsia   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kimsia):

 > Is this really Django's choice? 樂 As far as I'm aware they are
 forbidden in RFC 1035 and we're not doing anything unusual here.

 I mean yes, it's Django's choice to follow RFC 1035 strictly. I have no
 issues with that.

 The more explicit message for underscore is to help silly people like me
 to realize the error faster.

 To address the issue of not treating underscore any more special, would
 you mind if I change the error message to highlight which character
 doesn't conform to the hostname regardless whether it's underscore or
 something else.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0d94b334f5e45f701d015b6ca1a40cfd%40djangoproject.com.

Re: [Django] #33456: Make underscore in hostname error more explicit

2022-01-21 Thread Django

#33456: Make underscore in hostname error more explicit
-+-
 Reporter:  kimsia   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 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 kimsia):

 * has_patch:  0 => 1


Old description:

> Currently, the error message is simply
>
> "The domain name provided is not valid according to RFC 1034/1035."
>
> Most tickets filed against this topic is about how underscores should be
> allowed. I agreed with Django's choice to invalidate underscores.
>
> https://github.com/django/django/pull/594 explains this clearly.
>
> However, the error message can be clearer.
>
> I recommend when underscore is detected, simply make it more explicit
>
> " %r contains _ and that is not valid according to RFC 1034/1035." %
> domain
>
> Otherwise, "The domain name provided is not valid according to RFC
> 1034/1035."

New description:

 Currently, the error message is simply

 "The domain name provided is not valid according to RFC 1034/1035."

 Most tickets filed against this topic is about how underscores should be
 allowed. I agreed with Django's choice to invalidate underscores.

 https://github.com/django/django/pull/594 explains this clearly.

 However, the error message can be clearer.

 I recommend when underscore is detected, simply make it more explicit

 " %r contains _ and that is not valid according to RFC 1034/1035." %
 domain

 Otherwise, "The domain name provided is not valid according to RFC
 1034/1035."

 Patch: https://github.com/django/django/pull/15343

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ecc95bf72df2a9974638e717eefda11d%40djangoproject.com.

Re: [Django] #33456: Make underscore in hostname error more explicit

2022-01-21 Thread Django

#33456: Make underscore in hostname error more explicit
-+-
 Reporter:  kimsia   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 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 Mariusz Felisiak):

 * cc: Florian Apolloner (added)
 * owner:  (none) => nobody
 * status:  new => closed
 * component:  Error reporting => HTTP handling
 * resolution:   => wontfix


Comment:

 Thanks for this ticket, however I see no reason to treat the underscore
 differently from the other forbidden chars.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e153c54e767f206cbc4362f1a0c35cd5%40djangoproject.com.

[Django] #33456: Make underscore in hostname error more explicit

2022-01-21 Thread Django

#33456: Make underscore in hostname error more explicit
+
   Reporter:  kimsia|  Owner:  (none)
   Type:  Cleanup/optimization  | Status:  new
  Component:  Error reporting   |Version:  3.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 |
+
 Currently, the error message is simply

 "The domain name provided is not valid according to RFC 1034/1035."

 Most tickets filed against this topic is about how underscores should be
 allowed. I agreed with Django's choice to invalidate underscores.

 https://github.com/django/django/pull/594 explains this clearly.

 However, the error message can be clearer.

 I recommend when underscore is detected, simply make it more explicit

 " %r contains _ and that is not valid according to RFC 1034/1035." %
 domain

 Otherwise, "The domain name provided is not valid according to RFC
 1034/1035."

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.3f87c2d06fe9c9b485dbd7b10c16fb0b%40djangoproject.com.

Re: [Django] #26760: Delete nonexistent migrations from django_migrations table

2022-01-21 Thread Django

#26760: Delete nonexistent migrations from django_migrations table
-+-
 Reporter:  Jarek Glowacki   |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  django_migrations| Triage Stage:  Ready for
  squash migrations  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.30df72b7edcb48f0561b24de427f41fb%40djangoproject.com.

Re: [Django] #32691: Performance regression in Exact lookup on BooleanField on MySQL.

2022-01-21 Thread Django

Comment (by Mariusz Felisiak):

Replying to [comment:18 Anže Pečar]:
> Any chance that we could cheery-pick the fix into Django 3.2? The issue
nearly caused a production outage for us when we upgraded to Django 3.2
and it would be great to make sure nobody else gets burned by this.

Unfortunately not, this is a regression in Django 3.1 that is no longer
supported. Per our backporting policy this means it doesn't qualify for a
backport to 3.2.x or 4.0.x anymore.
See [https://docs.djangoproject.com/en/stable/internals/release-process/
Django’s release process] for more details.

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/072.4e454ea0980d53be55aaf196173fbe41%40djangoproject.com.

Re: [Django] #32691: Performance regression in Exact lookup on BooleanField on MySQL.

2022-01-21 Thread Django

#32691: Performance regression in Exact lookup on BooleanField on MySQL.
-+-
 Reporter:  Todor Velichkov  |Owner:  Roman
 Type:   |  Miroshnychenko
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  bool, booleanfield,  | Triage Stage:  Ready for
  orm, sql, mysql|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anze3db):

 Any chance that we could cheery-pick the fix into Django 3.2? The issue
 nearly caused a production outage for us when we upgraded to Django 3.2
 and it would be great to make sure nobody else gets burned by this.

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

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

Re: [Django] #32088: Django Database Sessions - Can't Retrieve expire_date from request.session (SessionStore)

Re: [Django] #33457: Expanding local vars in technical 500 causes horizontal scrolling

Re: [Django] #33458: Messages framework incorrectly serializes/deserializes extra_tags when it's an empty string

[Django] #33458: Messages framework incorrectly serializes/deserializes extra_tags when it's an empty string

Re: [Django] #33457: Expanding local vars in technical 500 causes horizontal scrolling

[Django] #33457: Expanding local vars in technical 500 causes horizontal scrolling

Re: [Django] #28889: Use JavaScript to prevent double submission of admin forms

Re: [Django] #26760: Delete nonexistent migrations from django_migrations table

Re: [Django] #33378: ImproperlyConfigured error is raised when installing apps in subdirectory

Re: [Django] #33456: Make underscore in hostname error more explicit

Re: [Django] #33454: Django4 does not pick up tests according to tags. (was: Django4 does not pick up tests according to market value)

Re: [Django] #33456: Make underscore in hostname error more explicit

Re: [Django] #33456: Make underscore in hostname error more explicit

Re: [Django] #33456: Make underscore in hostname error more explicit

Re: [Django] #33456: Make underscore in hostname error more explicit

Re: [Django] #33456: Make underscore in hostname error more explicit

[Django] #33456: Make underscore in hostname error more explicit

Re: [Django] #26760: Delete nonexistent migrations from django_migrations table

Re: [Django] #32691: Performance regression in Exact lookup on BooleanField on MySQL.

Re: [Django] #32691: Performance regression in Exact lookup on BooleanField on MySQL.

20 matches

Site Navigation

Mail list logo

Footer information