date:20220512

Re: [Django] #33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement

2022-05-12 Thread Django

#33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement
---+--
Reporter: Maxim Danilov |Owner: nobody
Type: Uncategorized | Status: closed
Component: contrib.admin | Version: 4.0
Severity: Normal | Resolution: invalid
Keywords: admin, modeladmin | 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):

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

Comment:

Thanks for the report, however as far as I'm aware `get_fields()` works as
intended and

[https://docs.djangoproject.com/en/stable/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_fields
documented], it's a hook which allows specifying fields dynamically. It
returns `ModelAdmin.fields` or base fields and readonly-fields, if not
specified.

It shouldn't check fieldsets definition, but the other way around,
fieldsets should check specified fields. That's why you're getting an
infinite recursion. Moreover `fields=None` was added intentionally in
23e1b59cf2ad6a75637dd0273973e657e48e317e.

--
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/01070180bbe42b7a-b340f807-a960-4b0d-9246-ca08e3a91f35-00%40eu-central-1.amazonses.com.

Re: [Django] #33702: Make request available to custom 500 and 400 templates

2022-05-12 Thread Django

#33702: Make request available to custom 500 and 400 templates
---+--
Reporter: Andrew |Owner: Andrew
Type: New feature| Status: closed
Component: HTTP handling | Version: 4.0
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 |UI/UX: 0
---+--
Changes (by Mariusz Felisiak):

* status: assigned => closed
* has_patch: 1 => 0
* resolution: => wontfix

Comment:

Django deliberately doesn't pass a `request` objects when rendering 400
and 500 error pages. It's recommended to keep them as simple as possible
and don't e.g. interact with the database (see #22011) or do anything that
might cause further errors. You can always
[https://docs.djangoproject.com/en/stable/topics/http/views/#customizing-
error-views-1 customize error views] in your app and pass a `request`
objects to templates, but my advise is to avoid it.

You can also start a discussion on DevelopersMailingList if you don't
agree.

--
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/01070180bba990b6-5cbbec94-7d28-4ab9-8d7e-58665254d942-00%40eu-central-1.amazonses.com.

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

2022-05-12 Thread Django

#33700: APPEND_SLASH adds significant latency to all requests not ending in / 
(even
if successful)
-+-
 Reporter:  Anders Kaseorg   |Owner:  Anders
 Type:   |  Kaseorg
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anders Kaseorg):

 * owner:  nobody => Anders Kaseorg
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180ba6fc536-59b3a740-7dd0-4b8d-8b57-a904b0e8d209-00%40eu-central-1.amazonses.com.

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

2022-05-12 Thread Django

#33700: APPEND_SLASH adds significant latency to all requests not ending in / 
(even
if successful)
-+-
 Reporter:  Anders Kaseorg   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anders Kaseorg):

 * has_patch:  0 => 1


Comment:

 Submitted a patch at https://github.com/django/django/pull/15689.

-- 
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/01070180ba6bce5e-75e8752d-e67e-4480-a732-8acbdfbe59be-00%40eu-central-1.amazonses.com.

Re: [Django] #33689: Django theme color variables are inconsistently named and poorly documented

2022-05-12 Thread Django

#33689: Django theme color variables are inconsistently named and poorly 
documented
-+-
 Reporter:  Murray Chapman   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  theme dark mode  | Triage Stage:  Accepted
  color variables documentation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Murray Chapman):

 Replying to [comment:1 Carlton Gibson]:
 > (Out of interest, were you proposing to create the style guide? )

 This should probably be done by someone with a modicum of visual design
 talent, which I don't have , and familiarity with the Django admin's
 existing visual style which I don't see documented or described
 anywhere. There are probably people more passionate and experienced about
 this than me, so I'll defer to any of them.

 I can offer some guidance based on a long career building websites,
 though:

  Scope::
 (''Not suggesting that these need to be done as part of this ticket,
 but they should be kept in mind'')
* be mindful that visual theme overlaps with usability, accessibility,
 brand identity, and widget design
* there are things beyond color that should be made variables (e.g.
 margins; border width/radius)

  Consistency::
* variables should be consistently named, and refer to concepts rather
 than specific use cases or colors
* it should be easy to determine the target of a color: Text?
 Background? Border? Shadow?
* text/background color variables should always be paired (current
 implementation makes assumptions about text/background pairings that are
 difficult to deduce)

  Completeness::
* every color should be a variable (some are still hardcoded)
* every variable should be documented and an example given

  Accessibility::
* accessibility issues like visual impairment and color blindness
 should be considered (good work already done on improving visual contrast)
* usability best practices strongly discourage using color alone to
 communicate meaning or state (e.g. don't use a red background and assume
 people will know that means "error". Should be accompanied by verbiage or
 an icon)

  Maintainability::
 * very helpful for developers would be a visual "crib sheet" that
 shows all colors/widgets on a single web view. Ideally this would be part
 of `contrib.admin` (so developers can test theme changes) as well as in
 the online documentation
 * future commits to stylesheets should be policed for hardcoded
 colors, ideally via automation
 * technical designs should be mindful of ease of maintenance and
 future expansion (e.g. introduction of other CSS variables for things like
 border widths)

 Django has '''excellent''' documentation and a high-quality/consistent
 visual design; I'm hoping we can get this formally defined/declared
 somewhere so plugin/extension authors can build consistently on top of it.

-- 
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/01070180ba59b249-31a628de-d1d6-4e4c-80c3-70cf1712df72-00%40eu-central-1.amazonses.com.

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

2022-05-12 Thread Django

Comment (by Anders Kaseorg):

We have a mix of URLs with `/` (most user-facing HTML) and URLs without
`/` (REST API with compatibility considerations, access-controlled
uploaded files with given names, SAML `metadata.xml`, SCIM endpoints at
specified paths, static content in development). `RUNNING_INSIDE_TORNADO`
is not the right test; it was just an easy workaround for one part of the
problem. Of course we can fork `CommonMiddleware` in an arbitrary Zulip-
specific way, but we’d prefer to improve Django for everyone, and this
seems like a clear opportunity for that.

I don’t think it’s reasonable to assume that URLs without `/` are likely
incorrect. Many URLs are required to be without `/` for compatibility or
convention or other technical reasons. I’m typing this very comment at a
URL without `/`.

I’ve done some more investigation with the help of `git bisect`, and I
found that the logging problem #26293 that was targeted by
9390da7fb6e251eaa9a785692f987296cb14523f was subsequently addressed more
completely by 40b69607c751c4afa453edfd41d2ed155e58187e (#26504).
Therefore, we can simply revert 9390da7fb6e251eaa9a785692f987296cb14523f
to improve performance without regressing #26293. Everybody wins!

--
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/01070180b9f3bf5e-02f977d8-b908-4c72-89de-a93399e0b67d-00%40eu-central-1.amazonses.com.

Re: [Django] #33691: Deprecate CryptPasswordHasher.

2022-05-12 Thread Django

#33691: Deprecate CryptPasswordHasher.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  4.0
 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 Nick Pope):

 Replying to [comment:3 Mariusz Felisiak]:
 > Replying to [comment:2 Florian Apolloner]:
 > > ACK, while we are on it I wonder if we should deprecate the unsalted &
 sha/md5 hashers as well. It is time to face reality, if you haven't
 upgraded Django by now and are still on one of those old algorithms your
 installation is probably 10 years or older?
 >
 > `MD5PasswordHasher` is still a nice hook for faster testing :)

 Like Florian, I also think that now is the time to get rid of the
 following hashers:

 - `MD5PasswordHasher`
 - `SHA1PasswordHasher`
 - `UnsaltedMD5PasswordHasher`
 - `UnsaltedSHA1PasswordHasher`

 It is long past time that these were gone, and they were removed from the
 default `PASSWORD_HASHERS` setting in Django 1.10 along with
 `CryptPasswordHasher`. In addition, they will not be fully removed until
 December 2023, so that gives Django 4.1 and 4.2 to move of these, and 4.2,
 being an LTS, gives plenty of time beyond that.

 Yes, it'd be nice to keep something fast around for testing purposes and
 we've been recommending `MD5PasswordHasher` up to now, but I don't think
 that should prevent removal of the other three at the very least...

 However, I propose that we add an explicit new `TestPasswordHasher` that
 has something in place to scream about not using it outside of local
 development environments and continuous integration pipelines for the
 purpose of speeding up testing. Maybe this could be achieved with the
 check framework (disabled when using testing tools). Or disabled when
 Django is executed via normal ASGI/WSGI stuff as would be done in
 production, but not when running tests. Or that `TestPasswordHasher` will
 only work when it is the only hasher.

 Another question would be whether we make it still use MD5 as the
 algorithm, or whether, now that we're making it explicitly for testing, we
 make it even faster by making it totally insecure? (Although this would
 maybe be a step to far in case of people still ignoring all the
 warnings...)

 I started messing around very roughly with this idea on the following
 branch, but I don't really have all that much time to follow it up right
 now. It needs thought about how we'd flag up and/or block use of
 `TestPasswordHasher` in the wrong places.

 https://github.com/ngnpope/django/tree/test-password-hasher

-- 
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/01070180b9e052d5-cab9cd92-93b6-4dc9-9118-13a7a09ac01b-00%40eu-central-1.amazonses.com.

Re: [Django] #27064: Implement RenameIndex in a backwards compatible way

2022-05-12 Thread Django

#27064: Implement RenameIndex in a backwards compatible way
-+-
 Reporter:  Markus Holtermann|Owner:  David
 |  Wobrock
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 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 Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180b9c1ffe3-3d196b00-89ba-4a31-8e43-13e0b7a4372e-00%40eu-central-1.amazonses.com.

Re: [Django] #27064: Implement RenameIndex in a backwards compatible way

2022-05-12 Thread Django

#27064: Implement RenameIndex in a backwards compatible way
-+-
 Reporter:  Markus Holtermann|Owner:  David
 |  Wobrock
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 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 Mariusz Felisiak ):

 In [changeset:"eacd4977f6a4bb038e82796ba79a2f61bae330c6" eacd4977]:
 {{{
 #!CommitTicketReference repository=""
 revision="eacd4977f6a4bb038e82796ba79a2f61bae330c6"
 Refs #27064 -- Added RenameIndex migration operation.
 }}}

-- 
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/01070180b9c12822-c38bbd4e-8177-4e83-b715-478caec0314f-00%40eu-central-1.amazonses.com.

Re: [Django] #33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement

2022-05-12 Thread Django

#33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement
---+--
 Reporter:  Maxim Danilov  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords:  admin, modeladmin  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Maxim Danilov):

 * has_patch:  1 => 0
 * easy:  1 => 0


Old description:

> almost all my issue is "not fixed", but i try
>
> I found a bug: ModelAdmin.get_fields works wrong with fieldset statement.
>
> How to reproduce it:
>
> {{{
> from django.db import models
> from django.contrib.admin import ModelAdmin
>
> class MyModel(models.Model):
> title = models.CharField('Meta Title of object', max_length=80,
> blank=True)
> slug = models.CharField('Meta Slug of object', max_length=80,
> blank=True)
>
> class MyModelAdmin1(ModelAdmin):
>
> fields = ('title', )
>

> class MyModelAdmin2(ModelAdmin):
> fieldset = ('title', )
>

> print(MyModelAdmin1(MyModel, None).get_fields(None))
> print(MyModelAdmin2(MyModel, None).get_fields(None))
> }}}
> save as test.py, in new or old project.
> python manage.py test output:
>
> {{{
> ('title',)
> ['title', 'slug']
> Found xxx test(s).
> ...
> }}}
>
> Problem is nor directly in def get_fields.
> {{{
> def get_fields(self, request, obj=None):
> """
> Hook for specifying fields.
> """
> if self.fields:
> return self.fields
> # _get_form_for_get_fields() is implemented in subclasses.
> form = self._get_form_for_get_fields(request, obj)
> return [*form.base_fields, *self.get_readonly_fields(request,
> obj)]
> }}}
>
> But in call of self._get_form_for_get_fields
>
> {{{
> def _get_form_for_get_fields(self, request, obj):
> return self.get_form(request, obj, fields=None)
> }}}
>
> The author of _get_form_for_get_fields has forgotten how self.get_form
> handles "fields":
>
> {{{
> def get_form(self, request, obj=None, change=False, **kwargs):
> """
> Return a Form class for use in the admin add view. This is used
> by
> add_view and change_view.
> """
> if 'fields' in kwargs:
> fields = kwargs.pop('fields')
> else:
> fields = flatten_fieldsets(self.get_fieldsets(request, obj))
> ...
> }}}
>
> I see two possibility to fix it:
>
> or
> {{{
> def _get_form_for_get_fields(self, request, obj):
> return self.get_form(request, obj)
> }}}
>
> or
>
> {{{
> def get_form(self, request, obj=None, change=False, **kwargs):
> """
> Return a Form class for use in the admin add view. This is used
> by
> add_view and change_view.
> """
> fields = kwargs.pop('fields', None) or []
> if not fields:
> fields = flatten_fieldsets(self.get_fieldsets(request, obj))
> ...
> }}}
> p.s.
> this issue is easy to create, we already have 'contrib.admin' in
> "component select" in Issue-Creation-Form, unlike, for example,
> 'contrib.gis'.
> For 'contrib.gis' we suddenly use GIS in uppercase.

New description:

 almost all my issue is "not fixed", but i try

 I found a bug: ModelAdmin.get_fields works wrong with fieldset statement.

 How to reproduce it:

 {{{
 from django.db import models
 from django.contrib.admin import ModelAdmin

 class MyModel(models.Model):
 title = models.CharField('Meta Title of object', max_length=80,
 blank=True)
 slug = models.CharField('Meta Slug of object', max_length=80,
 blank=True)

 class MyModelAdmin1(ModelAdmin):

 fields = ('title', )


 class MyModelAdmin2(ModelAdmin):
 fieldset = ('title', )


 print(MyModelAdmin1(MyModel, None).get_fields(None))
 print(MyModelAdmin2(MyModel, None).get_fields(None))
 }}}
 save as test.py, in new or old project.
 python manage.py test output:

 {{{
 ('title',)
 ['title', 'slug']
 Found xxx test(s).
 ...
 }}}

 Problem is nor directly in def get_fields.
 {{{
 def get_fields(self, request, obj=None):
 """
 Hook for specifying fields.
 """
 if self.fields:
 return self.fields
 # _get_form_for_get_fields() is implemented in subclasses.
 form = self._get_form_for_get_fields(request, obj)
 return [*form.base_fields, *self.get_readonly_fields(request,
 obj)]
 }}}

 But in call of self._get_form_for_get_fields

 {{{
 def _get_form_for_get_fields(self, request, obj):
 return self.get_form(request, obj, fields=None)
 }}}

Re: [Django] #33697: Cleanup duplication of HTTP header parsing in utils.http and multipart parser.

2022-05-12 Thread Django

#33697: Cleanup duplication of HTTP header parsing in utils.http and multipart
parser.
--+
 Reporter:  Carlton Gibson|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Kapil Bansal):

 Hi,
 I want to give this issue a try. Although I am not sure how to run and
 check what these functions are doing?
 Would it be like creating a new django project and tests from where this
 function is called? 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/01070180b98735e5-b56749ec-919f-4c69-88bd-3f97eedc300d-00%40eu-central-1.amazonses.com.

Re: [Django] #33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement

2022-05-12 Thread Django

#33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement
---+--
 Reporter:  Maxim Danilov  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords:  admin, modeladmin  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Maxim Danilov):

 * Attachment "test.py" added.

 example which works for me on django 4.01

-- 
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/01070180b981a29b-943a6756-aa70-494d-b071-2b77a2b81acc-00%40eu-central-1.amazonses.com.

[Django] #33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement

2022-05-12 Thread Django

#33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement
-+-
   Reporter:  Maxim  |  Owner:  nobody
  Danilov|
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  4.0
  contrib.admin  |
   Severity:  Normal |   Keywords:  admin, modeladmin
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 almost all my issue is "not fixed", but i try

 I found a bug: ModelAdmin.get_fields works wrong with fieldset statement.

 How to reproduce it:

 {{{
 from django.db import models
 from django.contrib.admin import ModelAdmin

 class MyModel(models.Model):
 title = models.CharField('Meta Title of object', max_length=80,
 blank=True)
 slug = models.CharField('Meta Slug of object', max_length=80,
 blank=True)

 class MyModelAdmin1(ModelAdmin):

 fields = ('title', )


 class MyModelAdmin2(ModelAdmin):
 fieldset = ('title', )


 print(MyModelAdmin1(MyModel, None).get_fields(None))
 print(MyModelAdmin2(MyModel, None).get_fields(None))
 }}}
 save as test.py, in new or old project.
 python manage.py test output:

 {{{
 ('title',)
 ['title', 'slug']
 Found xxx test(s).
 ...
 }}}

 Problem is nor directly in def get_fields.
 {{{
 def get_fields(self, request, obj=None):
 """
 Hook for specifying fields.
 """
 if self.fields:
 return self.fields
 # _get_form_for_get_fields() is implemented in subclasses.
 form = self._get_form_for_get_fields(request, obj)
 return [*form.base_fields, *self.get_readonly_fields(request,
 obj)]
 }}}

 But in call of self._get_form_for_get_fields

 {{{
 def _get_form_for_get_fields(self, request, obj):
 return self.get_form(request, obj, fields=None)
 }}}

 The author of _get_form_for_get_fields has forgotten how self.get_form
 handles "fields":

 {{{
 def get_form(self, request, obj=None, change=False, **kwargs):
 """
 Return a Form class for use in the admin add view. This is used by
 add_view and change_view.
 """
 if 'fields' in kwargs:
 fields = kwargs.pop('fields')
 else:
 fields = flatten_fieldsets(self.get_fieldsets(request, obj))
 ...
 }}}

 I see two possibility to fix it:

 or
 {{{
 def _get_form_for_get_fields(self, request, obj):
 return self.get_form(request, obj)
 }}}

 or

 {{{
 def get_form(self, request, obj=None, change=False, **kwargs):
 """
 Return a Form class for use in the admin add view. This is used by
 add_view and change_view.
 """
 fields = kwargs.pop('fields', None) or []
 if not fields:
 fields = flatten_fieldsets(self.get_fieldsets(request, obj))
 ...
 }}}
 p.s.
 this issue is easy to create, we already have 'contrib.admin' in
 "component select" in Issue-Creation-Form, unlike, for example,
 'contrib.gis'.
 For 'contrib.gis' we suddenly use GIS in uppercase.

-- 
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/01070180b9807893-ed13ab56-c146-498b-babe-7637c735f523-00%40eu-central-1.amazonses.com.

Re: [Django] #33682: Clarify using distinct() with related fields that have Meta.ordering defined.

2022-05-12 Thread Django

#33682: Clarify using distinct() with related fields that have Meta.ordering
defined.
--+
Reporter: Robert Leach |Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 3.2
Severity: Normal| Resolution:
Keywords: sql, distinct | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 |UI/UX: 0
--+

Comment (by Robert Leach):

OK, I just learned that you **cannot** add something like `blog__name` to
Entry's `Meta.ordering`. Still learning... So...

> If all you want is to make a set of query results distinct without
changing the ordering, note you must explicitly "re-"add the otherwise
over-ridden fields defined in Meta.ordering. But be careful, if you simply
add those fields, you can run afoul of the matching fields requirement
between order_by and distinct. The field(s) defined in Meta.ordering can
include a foreign key (via `ForeignKey`, `ManyToManyField`,
`OneToManyField`, etc. fields), which will resolve differently in order_by
(to the related model's Meta.ordering field(s)) and distinct (the _id) and
the fields will no longer match between the 2 expressions.
>
> Fields of related models cannot be added to a Model's `Meta.ordering`
(e.g. you cannot add `blog__name` to `Entry.Meta.ordering`), so to avoid
the order_by versus distinct matching field gotcha **and** retain the
default ordering in this instance, there are no shortcuts to only apply
distinct to an existing query without explicitly re-applying the default
ordering and resolving related model objects to database fields.

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/01070180b94c2f6b-33ef910a-def4-40f6-993d-5957f50bd839-00%40eu-central-1.amazonses.com.

Re: [Django] #16149: Allow disabling choices in a

2022-05-12 Thread Django

#16149: Allow disabling choices in a 
---+
 Reporter:  Jody McIntyre  |Owner:  (none)
 Type:  New feature|   Status:  new
Component:  Forms  |  Version:  1.3
 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 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180b92ab89f-f3a427fb-20ad-4596-ab96-8a92e1f74c49-00%40eu-central-1.amazonses.com.

Re: [Django] #33702: Make request available to custom 500 and 400 templates (was: Make request available to custom 500 and 404 templates)

2022-05-12 Thread Django

#33702: Make request available to custom 500 and 400 templates
---+--
 Reporter:  Andrew |Owner:  Andrew
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  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:  1  |UI/UX:  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180b8efe6f4-07c2a805-0fa3-472a-acc3-381da3c9d64a-00%40eu-central-1.amazonses.com.

Re: [Django] #33682: Clarify using distinct() with related fields that have Meta.ordering defined.

2022-05-12 Thread Django

Comment (by Robert Leach):

That's definitely better, as it directly references Meta.ordering, which
is a great clue to what the implications are. What do you think about
**adding** something like:

> If all you want is to make a set of query results distinct without
changing the ordering, note you must explicitly "re-"add the otherwise
over-ridden fields defined in Meta.ordering. But be careful, if you
simply add those fields, you can run afoul of the matching fields
requirement between order_by and distinct. The field(s) defined in
Meta.ordering can include a foreign key, which will resolve differently in
order_by (to the related model's Meta.ordering field(s)) and distinct (the
`_id`) and the fields will no longer match between the 2 expressions.
>
> But this gotcha can be entirely avoided by only ever using real database
fields in every `Meta.ordering`, `order_by`, and `distinct` list instead
of adding Django's related model objects (e.g. `ForeignKey`,
`ManyToManyField`, `OneToManyField`, etc.) so as not to rely on Django's
differing related-model-object to database-field resolving mechanisms
(e.g. instead of adding `blog` to `Entry.Meta.ordering`, add
`blog__name`).

...but like I said, all the info is there to either put it together and
anticipate it (albeit requiring a fairly deep understanding and more
experience to achieve those insights), or to interpret the exception. I
just feel like piecing together this (what I would consider common) use-
case, may make it clearer to those who are endeavoring into their first
big Django project and applying complex understandings of and experiences
with other programming languages.

Whatever edit gets included, I would like to say that I very much
appreciate your attention to this topic.

--
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/01070180b8e49e3b-33580446-18f5-4a87-8680-cf6eb6733b0a-00%40eu-central-1.amazonses.com.

Re: [Django] #33702: Make request available to custom 500 and 404 templates (was: Custom 500 page is broken)

2022-05-12 Thread Django

#33702: Make request available to custom 500 and 404 templates
---+--
 Reporter:  Andrew |Owner:  Andrew
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  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:  1  |UI/UX:  0
---+--
Changes (by Tim Graham):

 * type:  Uncategorized => New feature
 * component:  Generic views => HTTP handling


-- 
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/01070180b8e2ae04-bfbeaa5f-d467-4c11-be79-94e00fbb9ab8-00%40eu-central-1.amazonses.com.

Re: [Django] #33702: Custom 500 page is broken

2022-05-12 Thread Django

#33702: Custom 500 page is broken
---+--
 Reporter:  Andrew |Owner:  Andrew
 Type:  Uncategorized  |   Status:  assigned
Component:  Generic views  |  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:  1  |UI/UX:  0
---+--
Changes (by Andrew):

 * 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/01070180b8c56cbe-6b594b5b-7d1b-4212-89a6-105dca319efd-00%40eu-central-1.amazonses.com.

Re: [Django] #33702: Custom 500 page is broken

2022-05-12 Thread Django

#33702: Custom 500 page is broken
---+--
 Reporter:  Andrew |Owner:  Andrew
 Type:  Uncategorized  |   Status:  assigned
Component:  Generic views  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Andrew):

 * owner:  nobody => Andrew
 * status:  new => assigned
 * easy:  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/01070180b8719c6b-f7006e24-b3ff-49aa-b1bd-bfa00337b9ae-00%40eu-central-1.amazonses.com.

[Django] #33702: Custom 500 page is broken

2022-05-12 Thread Django

#33702: Custom 500 page is broken
-+
   Reporter:  Andrew |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Generic views  |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  |
-+
 The problem occurs when rendering `views.defaults.server_error` with
 template, which is using some `request` - based markup. The `request`
 variable in template is just empty

-- 
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/01070180b87145b0-33556912-7837-4979-87f9-00a6907f58f1-00%40eu-central-1.amazonses.com.

Re: [Django] #32559: Add attribute 'step' to FloatField.

2022-05-12 Thread Django

#32559: Add attribute 'step' to FloatField.
-+-
 Reporter:  Jacob Rief   |Owner:  Jacob
 |  Rief
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  FloatField,  | Triage Stage:  Ready for
  NumberInput, step  |  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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"3a82b5f655446f0ca89e3b6a92b100aa458f348f" 3a82b5f6]:
 {{{
 #!CommitTicketReference repository=""
 revision="3a82b5f655446f0ca89e3b6a92b100aa458f348f"
 Fixed #32559 -- Added 'step_size’ to numeric form fields.

 Co-authored-by: Jacob Rief 
 }}}

-- 
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/01070180b834148f-0ed700ed-b2c7-4bc7-a324-ea2b817c820e-00%40eu-central-1.amazonses.com.

Re: [Django] #33701: Highlight error location in the technical 500 debug page on Python 3.11+. (was: Python 3.11 error location traceback highlighting)

2022-05-12 Thread Django

#33701: Highlight error location in the technical 500 debug page on Python 
3.11+.
-+-
 Reporter:  Adam Johnson |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Someday/Maybe


Comment:

 Thanks for the ticket. Let's wait for the final release first.

-- 
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/01070180b7f720e9-cfc083cc-9c81-45ec-9a49-6e7365fe2d1d-00%40eu-central-1.amazonses.com.

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

2022-05-12 Thread Django

#33700: APPEND_SLASH adds significant latency to all requests not ending in / 
(even
if successful)
-+-
 Reporter:  Anders Kaseorg   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by JK Laiho):

 * cc: JK Laiho (removed)


-- 
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/01070180b7bb9f16-1b2d8053-ea7f-4841-b8dd-c6b264320585-00%40eu-central-1.amazonses.com.

[Django] #33701: Python 3.11 error location traceback highlighting

2022-05-12 Thread Django

#33701: Python 3.11 error location traceback highlighting
---+
   Reporter:  Adam Johnson |  Owner:  (none)
   Type:  New feature  | Status:  new
  Component:  Error reporting  |Version:  dev
   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|
---+
 Python 3.11 adds "where in the line" highlighting to tracebacks:

 {{{
 $ python3.11 t.py
 Traceback (most recent call last):
   File "/.../example.py", line 5, in 
 formula(1, 0)
 ^
   File "/.../example.py", line 2, in formula
 return a / b + b / a
~~^~~
 ZeroDivisionError: division by zero
 }}}

 Release note: https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-
 error-locations-in-tracebacks

 It would be good if we could use this on Django's error pages as well.

 The new code column information API may be required:
 https://docs.python.org/3.11/whatsnew/3.11.html#column-information-for-
 code-objects . Note it can be disabled.

-- 
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/01070180b7ba6d43-6c562191-5284-4a02-a037-e16c4ca3e20e-00%40eu-central-1.amazonses.com.

Re: [Django] #33681: Cache OPTIONS are not passed to the Redis client.

2022-05-12 Thread Django

#33681: Cache OPTIONS are not passed to the Redis client.
-+-
 Reporter:  Ben Picolo   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  4.0
 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 Mariusz Felisiak):

 * owner:  nobody => Mariusz Felisiak
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180b7b8941f-d75d4d42-7790-4c9b-a1b9-ea45a3a0e5a0-00%40eu-central-1.amazonses.com.

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

2022-05-12 Thread Django

#33700: APPEND_SLASH adds significant latency to all requests not ending in / 
(even
if successful)
-+-
 Reporter:  Anders Kaseorg   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 The Zulip middleware there...


 {{{
 def should_redirect_with_slash(self, request: HttpRequest) -> bool:
  if settings.RUNNING_INSIDE_TORNADO:
  return False
 return super().should_redirect_with_slash(request)
 }}}


 ... 樂

 Looks like that would be simpler just doing `APPEND_SLASH =
 RUNNING_INSIDE_TORNADO` in the settings file, since
 `should_redirect_with_slash()` would always immediately return `False` in
 that case.

 > ... extra urlconf lookup for every request not ending with /, whether or
 not it succeeds as written.

 If you're not normalising URLs, I wonder if you don't `APPEND_SLASH =
 False` anyway?

 > ...performance impact was not considered...

 The assumption is that URLs without `/` are likely incorrect, so
 ''succeeding as written'' should be rare, i.e. not performance sensitive.

 I'm inclined to say `wontfix` — you're welcome to disable APPEND_SLASH, or
 implement a response only version of the middleware — or `needsinfo` at
 least pending a suggested patch (that doesn't break anything).

-- 
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/01070180b7af4809-2b1069cf-ef23-415a-9908-ea365f678d8d-00%40eu-central-1.amazonses.com.

Re: [Django] #33543: Depracate passing False to OrderBy's nulls_first and nulls_last.

2022-05-12 Thread Django

#33543: Depracate passing False to OrderBy's nulls_first and nulls_last.
-+-
 Reporter:  Gordon Wrigley   |Owner:
 Type:   |  AllenJonathan
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"68da6b389c403cb91650754be0e2287696807333" 68da6b3]:
 {{{
 #!CommitTicketReference repository=""
 revision="68da6b389c403cb91650754be0e2287696807333"
 Fixed #33543 -- Deprecated passing nulls_first/nulls_last=False to OrderBy
 and Expression.asc()/desc().

 Thanks Allen Jonathan David for the initial patch.
 }}}

-- 
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/01070180b79b0418-9eacc2f3-b53d-41ba-9376-9000ed40b239-00%40eu-central-1.amazonses.com.

Re: [Django] #27064: Implement RenameIndex in a backwards compatible way

2022-05-12 Thread Django

#27064: Implement RenameIndex in a backwards compatible way
-+-
 Reporter:  Markus Holtermann|Owner:  David
 |  Wobrock
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 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 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/01070180b77c5451-89c85fd6-3050-4b07-a239-07569672e30f-00%40eu-central-1.amazonses.com.

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

2022-05-12 Thread Django

#33700: APPEND_SLASH adds significant latency to all requests not ending in / 
(even
if successful)
-+-
 Reporter:  Anders Kaseorg   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Keryn Knight):

 * cc: Keryn Knight (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180b76b0bce-0ce08af6-ccd0-4730-9c0d-a1179f004829-00%40eu-central-1.amazonses.com.

Re: [Django] #32559: Add attribute 'step' to FloatField.

2022-05-12 Thread Django

#32559: Add attribute 'step' to FloatField.
-+-
 Reporter:  Jacob Rief   |Owner:  Jacob
 |  Rief
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  FloatField,  | Triage Stage:  Ready for
  NumberInput, step  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  1 => 0
 * 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/01070180b7512a73-91c21f74-2efc-477a-9278-2fb65f2388fa-00%40eu-central-1.amazonses.com.

Re: [Django] #29538: Query Expression in ordering of a related object fails

2022-05-12 Thread Django

#29538: Query Expression in ordering of a related object fails
-+-
 Reporter:  wilhelmhb|Owner:  Eduardo
 |  Rivas
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  ordering, query  | Triage Stage:  Ready for
  expression, related object |  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:"2798c937deb6625a4e6a36e70d4d60ce5faac954" 2798c937]:
 {{{
 #!CommitTicketReference repository=""
 revision="2798c937deb6625a4e6a36e70d4d60ce5faac954"
 Fixed #29538 -- Fixed crash of ordering by related fields when
 Meta.ordering contains expressions.

 Thanks Simon Charette for the review.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180b708f95d-80fe1187-9a82-4ef5-921f-ce86cf925454-00%40eu-central-1.amazonses.com.

Re: [Django] #33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement

Re: [Django] #33702: Make request available to custom 500 and 400 templates

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

Re: [Django] #33689: Django theme color variables are inconsistently named and poorly documented

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

Re: [Django] #33691: Deprecate CryptPasswordHasher.

Re: [Django] #27064: Implement RenameIndex in a backwards compatible way

Re: [Django] #27064: Implement RenameIndex in a backwards compatible way

Re: [Django] #33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement

Re: [Django] #33697: Cleanup duplication of HTTP header parsing in utils.http and multipart parser.

Re: [Django] #33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement

[Django] #33703: ModelAdmin.get_fields wrong work with ModelAdmin.fieldsets statement

Re: [Django] #33682: Clarify using distinct() with related fields that have Meta.ordering defined.

Re: [Django] #16149: Allow disabling choices in a

Re: [Django] #33702: Make request available to custom 500 and 400 templates (was: Make request available to custom 500 and 404 templates)

Re: [Django] #33682: Clarify using distinct() with related fields that have Meta.ordering defined.

Re: [Django] #33702: Make request available to custom 500 and 404 templates (was: Custom 500 page is broken)

Re: [Django] #33702: Custom 500 page is broken

Re: [Django] #33702: Custom 500 page is broken

[Django] #33702: Custom 500 page is broken

Re: [Django] #32559: Add attribute 'step' to FloatField.

Re: [Django] #33701: Highlight error location in the technical 500 debug page on Python 3.11+. (was: Python 3.11 error location traceback highlighting)

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

[Django] #33701: Python 3.11 error location traceback highlighting

Re: [Django] #33681: Cache OPTIONS are not passed to the Redis client.

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

Re: [Django] #33543: Depracate passing False to OrderBy's nulls_first and nulls_last.

Re: [Django] #27064: Implement RenameIndex in a backwards compatible way

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

Re: [Django] #32559: Add attribute 'step' to FloatField.

Re: [Django] #29538: Query Expression in ordering of a related object fails

32 matches

Site Navigation

Mail list logo

Footer information