Re: [Django] #5069: newforms cannot initial SelectDateWidget 's value

[Django]

#5069: newforms cannot initial SelectDateWidget 's value
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  master
 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 Carlton Gibson):

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


Comment:

 Please see TicketClosingReasons/DontReopenTickets.

-- 
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.30aa13c7e73e2bc987149bb5752e6dcf%40djangoproject.com.

Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields. (was: Migration optimizer removes 1 RemoveField for FK when deleting 2 models)

[Django]

#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
--+
 Reporter:  Panagis Alisandratos  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  migration,optimizer   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by felixxm):

 * cc: Markus Holtermann, Andriy Sokolovskiy, Shai Berger (added)
 * version:  2.2 => master
 * stage:  Unreviewed => Accepted


Comment:

 IMO, `RemoveField` is redundant in this case (see #24061 with a related
 discussion).

-- 
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.3abd4a9e9105954d6357b49b327c211c%40djangoproject.com.

Re: [Django] #31256: Inline widget permision is now based on it's foregin key.

[Django]

#31256: Inline widget permision is now based on it's foregin key.
+--
 Reporter:  John Lyu|Owner:  nobody
 Type:  Uncategorized   |   Status:  closed
Component:  contrib.admin   |  Version:  2.1
 Severity:  Normal  |   Resolution:  wontfix
 Keywords:  Inlines, permision  | 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:   => wontfix
 * component:  Uncategorized => contrib.admin


Comment:

 I don't agree that this solution is rude. The rationale behind the
 Security Team decision is included in the release notes and there is not
 much to add.

-- 
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/069.684ab1f9c868d784d7b035f37e45e65f%40djangoproject.com.

Re: [Django] #31256: Inline widget permision is now based on it's foregin key.

[Django]

#31256: Inline widget permision is now based on it's foregin key.
+--
 Reporter:  PaleNeutron |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  2.1
 Severity:  Normal  |   Resolution:
 Keywords:  Inlines, permision  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by PaleNeutron):

 * version:  2.2 => 2.1


Old description:

> Use an old example:
>
> in models.py
> {{{
> class Ticket(models.Model):
> 
>
> class Action(models.Model):
>
> ticket = models.ForeignKey(Ticket)
> 
> }}}
>
> in admin.py:
> {{{
> class ActionInline(admin.TabularInline):
> model = Action
> extra=1
> max_num=3
>
> class TicketAdmin(admin.ModelAdmin):
>
> .
> inlines = [
> ActionInline,
> ]
> }}}
>
> In version  2.2.10 or 3.0.3:
> If I set current user's permisson `edit_Action` but no `edit Ticket`,
> I will not be able to edit actions inlines in "Change Ticket" page.
>
> I think that is different with at least version 2.1.7 and is confusing.

New description:

 Use an old example:

 in models.py
 {{{
 class Ticket(models.Model):
 

 class Action(models.Model):

 ticket = models.ForeignKey(Ticket)
 
 }}}

 in admin.py:
 {{{
 class ActionInline(admin.TabularInline):
 model = Action
 extra=1
 max_num=3

 class TicketAdmin(admin.ModelAdmin):

 .
 inlines = [
 ActionInline,
 ]
 }}}

 In version  2.1.15:
 If I set current user's permisson `edit_Action` but no `edit Ticket`,
 I will not be able to edit actions inlines in "Change Ticket" page.

 Based on https://docs.djangoproject.com/en/3.0/releases/2.1.15/,  that bug
 fix is rude and confusing.

 In fact, I can still change `Action` it self and  indirectly "change" the
 page of it's parent Ticket. We should stop trigger save method in this
 condition instead of disable the feature.

--

-- 
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/069.f1795c9b242c62c4c21d431ec57839e4%40djangoproject.com.

Re: [Django] #31256: Inline widget permision is now based on it's foregin key.

[Django]

#31256: Inline widget permision is now based on it's foregin key.
+--
 Reporter:  PaleNeutron |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  2.2
 Severity:  Normal  |   Resolution:
 Keywords:  Inlines, permision  | 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 PaleNeutron:

Old description:

> Use an old example:
>
> in models.py
> {{{
> class Ticket(models.Model):
> 
>
> class Action(models.Model):
>
> ticket = models.ForeignKey(Ticket)
> 
> }}}
>
> in admin.py:
> {{{
> class ActionInline(admin.TabularInline):
> model = Action
> extra=1
> max_num=3
>
> class TicketAdmin(admin.ModelAdmin):
>
> .
> inlines = [
> ActionInline,
> ]
> }}}
>
> In version 2.2.10:
> If I set current user's permisson `edit_Action` but no `edit Ticket`,
> I will not be able to edit actions inlines in "Change Ticket" page.
>
> I think that is different with at least version 2.1.7 and is confusing.

New description:

 Use an old example:

 in models.py
 {{{
 class Ticket(models.Model):
 

 class Action(models.Model):

 ticket = models.ForeignKey(Ticket)
 
 }}}

 in admin.py:
 {{{
 class ActionInline(admin.TabularInline):
 model = Action
 extra=1
 max_num=3

 class TicketAdmin(admin.ModelAdmin):

 .
 inlines = [
 ActionInline,
 ]
 }}}

 In version  2.2.10 or 3.0.3:
 If I set current user's permisson `edit_Action` but no `edit Ticket`,
 I will not be able to edit actions inlines in "Change Ticket" page.

 I think that is different with at least version 2.1.7 and is confusing.

--

-- 
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/069.734500714abf8de2d6f4318b999774ec%40djangoproject.com.

Re: [Django] #31256: Inline widget permision is now based on it's foregin key.

[Django]

#31256: Inline widget permision is now based on it's foregin key.
+--
 Reporter:  PaleNeutron |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  2.2
 Severity:  Normal  |   Resolution:
 Keywords:  Inlines, permision  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by PaleNeutron):

 * version:  3.0 => 2.2


Old description:

> Use an old example:
>
> in models.py
> {{{
> class Ticket(models.Model):
> 
>
> class Action(models.Model):
>
> ticket = models.ForeignKey(Ticket)
> 
> }}}
>
> in admin.py:
> {{{
> class ActionInline(admin.TabularInline):
> model = Action
> extra=1
> max_num=3
>
> class TicketAdmin(admin.ModelAdmin):
>
> .
> inlines = [
> ActionInline,
> ]
> }}}
>
> If I set current user's permisson `edit_Action` but no `edit Ticket`, I
> will not be able to edit actions inlines in "Change Ticket" page.
>
> I think that is different with at least version 2.1.7 and is confusing.

New description:

 Use an old example:

 in models.py
 {{{
 class Ticket(models.Model):
 

 class Action(models.Model):

 ticket = models.ForeignKey(Ticket)
 
 }}}

 in admin.py:
 {{{
 class ActionInline(admin.TabularInline):
 model = Action
 extra=1
 max_num=3

 class TicketAdmin(admin.ModelAdmin):

 .
 inlines = [
 ActionInline,
 ]
 }}}

 In version 2.2.10:
 If I set current user's permisson `edit_Action` but no `edit Ticket`,
 I will not be able to edit actions inlines in "Change Ticket" page.

 I think that is different with at least version 2.1.7 and is confusing.

--

-- 
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/069.e0287c75d40d8fe49c76a77eebbd1246%40djangoproject.com.

[Django] #31256: Inline widget permision is now based on it's foregin key.

[Django]

#31256: Inline widget permision is now based on it's foregin key.
-+-
   Reporter: |  Owner:  nobody
  PaleNeutron|
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  3.0
  Uncategorized  |
   Severity:  Normal |   Keywords:  Inlines, permision
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Use an old example:

 in models.py
 {{{
 class Ticket(models.Model):
 

 class Action(models.Model):

 ticket = models.ForeignKey(Ticket)
 
 }}}

 in admin.py:
 {{{
 class ActionInline(admin.TabularInline):
 model = Action
 extra=1
 max_num=3

 class TicketAdmin(admin.ModelAdmin):

 .
 inlines = [
 ActionInline,
 ]
 }}}

 If I set current user's permisson `edit_Action` but no `edit Ticket`, I
 will not be able to edit actions inlines in "Change Ticket" page.

 I think that is different with at least version 2.1.7 and is confusing.

-- 
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/054.507a7364be49237be3dc802a1a26e83a%40djangoproject.com.

Re: [Django] #30509: Various FileResponse fixes and changes

[Django]

#30509: Various FileResponse fixes and changes
--+
 Reporter:  Piotr Kunicki |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  HTTP handling |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  FileResponse  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Piotr Kunicki):

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

Re: [Django] #31255: Migration optimizer removes 1 RemoveField for FK when deleting 2 models (was: Migration optimizer retains 1 RemoveField for FK when deleting 2 models)

[Django]

#31255: Migration optimizer removes 1 RemoveField for FK when deleting 2 models
-+-
 Reporter:  Palisand |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|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/066.79ad003bd159b3b22bda9ea859062774%40djangoproject.com.

Re: [Django] #31255: Migration optimizer retains 1 RemoveField for FK when deleting 2 models (was: Migration optimizer retains a 1 RemoveField for FK when deleting 2 models)

[Django]

#31255: Migration optimizer retains 1 RemoveField for FK when deleting 2 models
-+-
 Reporter:  Palisand |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|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/066.acd5ac3c3adee5386a546431b6230e54%40djangoproject.com.

[Django] #31255: Migration optimizer retains a 1 RemoveField for FK when deleting 2 models

[Django]

#31255: Migration optimizer retains a 1 RemoveField for FK when deleting 2 
models
-+-
   Reporter:  Palisand   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  2.2
  Migrations |
   Severity:  Normal |   Keywords:  migration,optimizer
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 {{{
 class ModelA(models.Model):
 field1 = models.BooleanField(default=False)

 class ModelB(models.Model):
 another_field1 = models.TextField(blank=True)
 field1 = models.BooleanField(default=False)
 related_field = models.ForeignKey(ModelA, on_delete=models.CASCADE)

 class ModelC(models.Model):
 another_field1 = models.TextField(blank=True)
 related_field = models.ForeignKey(ModelA, on_delete=models.CASCADE)
 }}}

 Removing {{{ModelB}}} and {{{ModelC}}} yields the following migration:
 {{{
 class Migration(migrations.Migration):

 dependencies = [
 ('analyzer', '0149_modela_modelb_modelc'),
 ]

 operations = [
 migrations.RemoveField(
 model_name='modelc',
 name='related_field',
 ),
 migrations.DeleteModel(
 name='ModelB',
 ),
 migrations.DeleteModel(
 name='ModelC',
 ),
 ]
 }}}

 It is unclear whether the {{{RemoveField}}} operation is redundant or if a
 {{{RemoveField}}} operation for {{{ModelB}}} is missing.

 I've confirmed that the {{{RemoveField}}} operation for {{{ModelB}}} is
 part of the unoptimized operations set.

-- 
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/051.056b2668d91940bf5553960363cdc739%40djangoproject.com.

Re: [Django] #31254: "populate() isn't reentrant" masks underlying error

[Django]

#31254: "populate() isn't reentrant" masks underlying error
--+--
 Reporter:  TK-23 |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  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
--+--
Changes (by TK-23):

 * type:  Uncategorized => Bug


-- 
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/063.8a63fb7056708536458156ac00fbb587%40djangoproject.com.

[Django] #31254: "populate() isn't reentrant" masks underlying error

[Django]

#31254: "populate() isn't reentrant" masks underlying error
-+
   Reporter:  TK-23  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Core (Other)   |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  |
-+
 I'm new to reporting bugs, but have struggled with this one enough that I
 thought I would formally document an issue we've seen.

 In django/django/apps/registry.py
 
(https://github.com/django/django/blob/20ba3ce4ac8e8438070568ffba76f7d8d4986a53/django/apps/registry.py#L83)
 there is a line of code that can raise an error when running simple
 commands like {{{python manage.py runserver}}}:

 {{{
 if self.loading:
 # Prevent reentrant calls to avoid running
 AppConfig.ready()
 # methods twice.
 raise RuntimeError("populate() isn't reentrant")
 }}}

 The problem is that this generic error can mask the true reason why django
 will not start up (I've seen the true reason be something like a problem
 with a version of a Python package needing to be updated, or an import of
 a module that does not exist elsewhere in the code). Based on a
 stackoverflow response (https://stackoverflow.com/questions/27093746
 /django-stops-working-with-runtimeerror-populate-isnt-reentrant) I've
 learned to comment out {{{raise RuntimeError("populate() isn't
 reentrant")}}} and replace it with {{{self.app_configs={} }}}

 This way the true error will be exposed when starting up django. I do not
 know the best way to handle this but before I found this stackoverflow
 post, we lost a lot of time trying to debug issues. Even knowing this
 workaround it is a hassle to adjust the django code to see the true error.

 I can provide a link to our opensource project with a branch set up to
 replicate the error if that is helpful.

-- 
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/048.1c30b1cb53e3e95400a3baee9a5714d4%40djangoproject.com.

Re: [Django] #31253: Possible data loss when using caching from async code.

[Django]

#31253: Possible data loss when using caching from async code.
-+-
 Reporter:  felixxm  |Owner:  Jon
 |  Dufresne
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  3.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  asgi async   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 [https://github.com/django/django/pull/12430 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/065.e46e8cbfc033f0207c1b2f42fa8755f0%40djangoproject.com.

[Django] #31253: Possible data loss when using caching from async code.

[Django]

#31253: Possible data loss when using caching from async code.
-+-
   Reporter:  felixxm|  Owner:  Jon Dufresne
   Type:  Bug| Status:  assigned
  Component:  Core   |Version:  3.0
  (Cache system) |
   Severity:  Release|   Keywords:  asgi async
  blocker|
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `CacheHandler` use `threading.local` instead of `asgiref.local.Local`,
 hence it's a chance of data corruption if someone tries to use caching
 from async code. There is a potential race condition if two coroutines
 touch the same cache object at exactly the same 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/050.d3994c3184c4d52a8dd1be5b040544fc%40djangoproject.com.

Re: [Django] #5069: newforms cannot initial SelectDateWidget 's value

[Django]

#5069: newforms cannot initial SelectDateWidget 's value
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  master
 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
---+--
Changes (by kqhwejhgqwhje):

 * status:  closed => new
 * severity:   => Normal
 * resolution:  wontfix =>
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => Uncategorized


Comment:

 {{{Person(request.POST)}}} isn't the same as
 {{{Person(initial=request.POST)}}}

 If our model has two field
 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
 class Person(newforms.form):
 birthday = forms.DateField( widget=utils.widgets.SelectDateWidget())
 name = models.CharField(max_length=80)
   }}}
 }}}

 and we have only {{{birthday}}} as initial data and we want to let user
 fill {{{name}}} we will get {{{required field}}} error with
 {{{Person(request.POST)}}}

-- 
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.da5cb4cce8e401733d6fce514bbe974f%40djangoproject.com.

Re: [Django] #30846: postgis backend doesn't respect custom index names.

[Django]

#30846: postgis backend doesn't respect custom index names.
-+-
 Reporter:  Thomas Steen |Owner:  Pratik
  Rasmussen  |  Kumar
 Type:  Bug  |   Status:  closed
Component:  GIS  |  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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"20ba3ce4ac8e8438070568ffba76f7d8d4986a53" 20ba3ce4]:
 {{{
 #!CommitTicketReference repository=""
 revision="20ba3ce4ac8e8438070568ffba76f7d8d4986a53"
 Fixed #30846 -- Made PostGIS backend respect Index's name argument.
 }}}

-- 
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.2a1d6559191c3d7cbcf5c93c31938f51%40djangoproject.com.

Re: [Django] #31251: QuerySet.annotate() crashes when grouping by OuterRef().

[Django]

#31251: QuerySet.annotate() crashes when grouping by OuterRef().
-+-
 Reporter:  Oliver Ford  |Owner:  Yuri
 Type:   |  Savin
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db,outerref,group| Triage Stage:  Accepted
  by,subquery,annotate   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by felixxm):

 Oliver, `OuterRef()` is a field from the outer query, so it will be the
 same for all rows in a subquery. Is there any value in adding it to a
 `GROUP BY` clause? e.g.
 {{{
 (SELECT MIN("price") from "subquery_table" GROUP BY "outer_table"."type")
 }}}
 is equivalent to
 {{{
 (SELECT MIN("price") from "subquery_table")
 }}}

-- 
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/064.bad7c11592913b5e6c33f3efcd7bfe89%40djangoproject.com.

Re: [Django] #31251: QuerySet.annotate() crashes when grouping by OuterRef().

[Django]

#31251: QuerySet.annotate() crashes when grouping by OuterRef().
-+-
 Reporter:  Oliver Ford  |Owner:  Yuri
 Type:   |  Savin
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db,outerref,group| Triage Stage:  Accepted
  by,subquery,annotate   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Oliver Ford):

 Why not the column that `OuterRef` is referencing? That was my intended
 behaviour, though I eventually realised I was overcomplicating it and just
 needed to group on the column directly, not an outer ref, and filter on
 the outer ref.

-- 
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/064.ea00889d681afc650d4dcf004eb62ef9%40djangoproject.com.

Re: [Django] #31250: assertXMLEqual() crashes on processing instructions.

[Django]

#31250: assertXMLEqual() crashes on processing instructions.
---+--
 Reporter:  Matt Fisher|Owner:  Yuri Savin
 Type:  Bug|   Status:  assigned
Component:  Testing framework  |  Version:  master
 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
---+--
Changes (by Yuri Savin):

 * owner:  nobody => Yuri Savin
 * 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/068.aa2318322ab92ebf5dc9c1260ef7c1f2%40djangoproject.com.

Re: [Django] #31251: QuerySet.annotate() crashes when grouping by OuterRef().

[Django]

#31251: QuerySet.annotate() crashes when grouping by OuterRef().
-+-
 Reporter:  Oliver Ford  |Owner:  Yuri
 Type:   |  Savin
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db,outerref,group| Triage Stage:  Accepted
  by,subquery,annotate   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Yuri Savin):

 * owner:  nobody => Yuri Savin
 * 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/064.fd4754b52b58d7842e860799eb17bf5e%40djangoproject.com.

Re: [Django] #31251: QuerySet.annotate() crashes when grouping by OuterRef(). (was: Unable to annotate a query that has an OuterRef already)

[Django]

#31251: QuerySet.annotate() crashes when grouping by OuterRef().
-+-
 Reporter:  Oliver Ford  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db,outerref,group| Triage Stage:  Accepted
  by,subquery,annotate   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * type:  Bug => Cleanup/optimization
 * version:  3.0 => master
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Grouping by `OuterRef()` doesn't have much value, it's like using a
 constant value, so IMO we can easily fix this with:
 {{{
 diff --git a/django/db/models/expressions.py
 b/django/db/models/expressions.py
 index 2e831b21ac..a165923784 100644
 --- a/django/db/models/expressions.py
 +++ b/django/db/models/expressions.py
 @@ -562,6 +562,9 @@ class ResolvedOuterRef(F):
  def relabeled_clone(self, relabels):
  return self

 +def get_group_by_cols(self, alias=None):
 +return []
 +

  class OuterRef(F):
  def resolve_expression(self, *args, **kwargs):
 }}}

-- 
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/064.68c63fdcd9873490c8fc4377a03933c6%40djangoproject.com.

Re: [Django] #31250: assertXMLEqual() crashes on processing instructions. (was: assertXMLEqual fails on processing instructions)

[Django]

#31250: assertXMLEqual() crashes on processing instructions.
---+
 Reporter:  Matt Fisher|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 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
---+
Changes (by felixxm):

 * version:  3.0 => master
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #30846: postgis backend doesn't respect custom index names.

[Django]

#30846: postgis backend doesn't respect custom index names.
-+-
 Reporter:  Thomas Steen |Owner:  Pratik
  Rasmussen  |  Kumar
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  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:  1|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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c3c0a34afc70042c35e27e0357e57531%40djangoproject.com.

Re: [Django] #31251: Unable to annotate a query that has an OuterRef already

[Django]

#31251: Unable to annotate a query that has an OuterRef already
-+-
 Reporter:  OJFord   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db,outerref,group| Triage Stage:
  by,subquery,annotate   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by OJFord):

 Perhaps I was doing something silly in the first place; I've resolved my
 issue by changing the subquery to first annotate (group by) all the
 `type`s, whatever they are, not `OuterRef`, and then only after the `Min`
 annotation `filter`ing on the `OuterRef("type")` matching the grouped by
 type.

 I'll leave this open for now though in case it's desired to improve the
 error message in this case, or perhaps there's a more sensibly-intentioned
 query that does produce the same error.

-- 
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/064.4297a207bf2e79656adacc1b8f6ca836%40djangoproject.com.

[Django] #31252: Oracle GIS doesn't support spatial indexes in Meta.indexes.

[Django]

#31252: Oracle GIS doesn't support spatial indexes in Meta.indexes.
+
   Reporter:  felixxm   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  GIS   |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Oracle GIS doesn't support spatial indexes in `Meta.indexes`, it raises an
 error:
 {{{
 django.db.utils.DatabaseError: ORA-02327: cannot create index on
 expression with datatype ADT
 }}}
 because `INDEXTYPE IS MDSYS.SPATIAL_INDEX` is missing in generated SQL.

-- 
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/050.4a851b7075d54fab2ae6e8c180ff8bae%40djangoproject.com.

[Django] #31251: Unable to annotate a query that has an OuterRef already

[Django]

#31251: Unable to annotate a query that has an OuterRef already
-+-
   Reporter:  OJFord |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  layer (models, ORM)|   Keywords:  db,outerref,group
   Severity:  Normal |  by,subquery,annotate
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm trying to construct a query like:
 {{{
 cheapest_query = models.Subquery(qs.annotate(
 groupbytype=models.OuterRef("type"),
 ).values("groupbytype")).annotate(
 cheapest=models.Min("price"),
 ).values("cheapest"))

 qs = qs.annotate(premium_over_cheapest=models.F("price") - cheapest_query)
 }}}

 However this fails in the second `annotate` (`cheapest=`) since
 `ResolvedOuterRef` does not descend from `BaseExpression`; so it has no
 `get_group_by_cols` method:
 {{{
File "/usr/local/lib/python3.8/site-
 packages/django/db/models/query.py", line 1078, in annotate
  clone.query.set_group_by()
   File "/usr/local/lib/python3.8/site-
 packages/django/db/models/sql/query.py", line 1938, in set_group_by
  inspect.getcallargs(annotation.get_group_by_cols, alias=alias)
  AttributeError: 'ResolvedOuterRef' object has no attribute
 'get_group_by_cols'
 }}}

 https://github.com/django/django/blob/master/django/db/models/expressions.py

-- 
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/049.179c80fb413bc6473cc4e5e065a854c0%40djangoproject.com.

Re: [Django] #31248: Missing whitespace in SQL generated for PostGIS indexed with USING.

[Django]

#31248: Missing whitespace in SQL generated for PostGIS indexed with USING.
-+-
 Reporter:  Hannes Ljungberg |Owner:  Hannes
 Type:   |  Ljungberg
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  Version:  master
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"adcf1a73084d005a04ce6ebce9a5cecd42fed812" adcf1a73]:
 {{{
 #!CommitTicketReference repository=""
 revision="adcf1a73084d005a04ce6ebce9a5cecd42fed812"
 Fixed #31248 -- Added missing space before USING SQL on PostGIS.
 }}}

-- 
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.6c28a19fc0c43830440377506dcfa8a2%40djangoproject.com.

Re: [Django] #31003: Suggesting: Documentation update for bulk_create method

[Django]

#31003: Suggesting: Documentation update for bulk_create method
-+-
 Reporter:  Peter Vlasveld   |Owner:  Adam
 Type:   |  (Chainz) Johnson
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  bulk_create, | Triage Stage:  Accepted
  database, query,   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"382af9b14113aaa8821da404933c12053bb394fd" 382af9b1]:
 {{{
 #!CommitTicketReference repository=""
 revision="382af9b14113aaa8821da404933c12053bb394fd"
 Fixed #31003 -- Doc'd and tested return value of QuerySet.bulk_create().
 }}}

-- 
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.f9ddbec9403c3b68c1bc41acf07a217f%40djangoproject.com.