Re: [Django] #29981: "Please correct the error below." (with no errors displayed) when changing an inline that has a one-to-one relation to the parent that uses to_field

[Django]

#29981: "Please correct the error below." (with no errors displayed) when 
changing
an inline that has a one-to-one relation to the parent that uses to_field
---+-
 Reporter:  Bernie |Owner:  Patrik Sletmo
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by Bernie):

 Replying to [comment:3 Patrik Sletmo]:
 > I've managed to reproduce the issue and will start to look for a
 solution.

 Start looking at django.forms.models.BaseInlineFormSet.add_fields:

 {{{
 form.fields[name] = InlineForeignKeyField(self.instance, **kwargs)
 }}}

 When there is an existing inline-instance, InlineForeignKeyField needs to
 know about the to_field.

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

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

Re: [Django] #28296: Add support for aggregation through subqueries

[Django]

#28296: Add support for aggregation through subqueries
-+-
 Reporter:  László Károlyi   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Another API alternative could be allow queries to be passed directly to
 aggregation functions

 {{{#!python
 # Implicit Count(*)
 Performance.objects.annotate(
 reserved_seats=Count(SeatReservation.objects.filter(
 performance=OuterRef('pk'),
 status__in=TAKEN_TYPES,
 ))
 )

 # Explicit Count('pk')
 Performance.objects.annotate(
 reserved_seats=Count(SeatReservation.objects.filter(
 performance=OuterRef('pk'),
 status__in=TAKEN_TYPES,
 ).values('pk'))
 )

 # Sum('seat__amount')
 Performance.objects.annotate(
 reserved_seats_total_amount=Sum(SeatReservation.objects.filter(
 performance=OuterRef('pk'),
 status__in=TAKEN_TYPES,
 ).values('seat__amount')
 )
 }}}

 Or to allow passing a `subquery` kwarg to aggregation expressions. It can
 either be `True` or a query

 {{{#!python
 # subquery=True
 Performance.objects.annotate(
 reserved_seats=Count(
 'seat_reservations',
 filter=Q(status__in=TAKEN_TYPES),
 subquery=True,
 ),
 )

 # explicit subquery
 Performance.objects.annotate(
 reserved_seats=Count(
 'seat_reservations',
 subquery=SeatReservation.objects.filter(
 status__in=TAKEN_TYPES,
 ),
 ),
 )

 # Sum('seat_reservations__seat__amount')
 Performance.objects.annotate(
 reserved_seats_total_amount=Sum(
 'seat_reservations__seat__amount'',
 subquery=True,
 ),
 )
 }}}

 I think I like  the`subquery` kwarg alternative better. It blends
 naturally with the newly added `filter` kwarg and result in less verbose
 expressions as the `subquery` shouldn't have to be provided most of the
 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.59b24de8741c893d2a4146e4aebee6b9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29992: Error in admin checking list_display items

[Django]

#29992: Error in admin checking list_display items
---+
   Reporter:  gtoffoli |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  contrib.admin|Version:  2.1
   Severity:  Release blocker  |   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 porting my app from Django 1.8 and 2.0.6 to **Django 2.1.3**.
 In the last environment, ''runserver'' emits a lot of system check issues
 of type **admin.E108**
 They refer to fields from different modules and many different classes,
 but all of them are ''CharField'' or ''TextField''.

 I see that method **_check_list_display_item** of class
 ''ModelAdminChecks'' in module ''check'' of ''django.contrib.admin'' has
 changed significantly between releases 2.0.6 and 2.1.3; in the latter, has
 been removed the last branch (else) of the top-level if-elif-else
 structure, although it was explicitly stated, in a comment inside it, that
 the associated path was required.

 I'm not able to make a complete diagnosis, but it seems that testing

 {{{
 hasattr(model, item)
 }}}

 in general gives a different result than testing the existence of the same
 field with

 {{{
 model._meta.get_field(item)
 }}}

 In fact, using the ''manage.py shell'' command, I experimentally verified
 such difference on a subset of the fields presenting the above mentioned
 problem: the ''hasattr'' test yields sometimes True and sometimes False
 (don't know why), while the other way of testing the existence of the
 field always yields a True result.

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

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

Re: [Django] #29992: Error in admin checking list_display items

[Django]

#29992: Error in admin checking list_display items
-+--
 Reporter:  gtoffoli |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tim Graham):

 Please give a minimal sample project that reproduces the issue.

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

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

Re: [Django] #29992: Error in admin checking list_display items

[Django]

#29992: Error in admin checking list_display items
-+--
 Reporter:  gtoffoli |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tim Graham):

 Check if #29636 explains the cause.

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

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

[Django] #29993: Bug trying to add two fields with the same name in two models

[Django]

#29993: Bug trying to add two fields with the same name in two models
--+
   Reporter:  César García Tapia  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  2.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   |
--+
 We have two models in the same application:

 {{{
 class ModelA(models.Model):
 one_field = models.CharField(...)

 class ModelB(models.Model):
 another_field = models.CharField(...)
 }}}

 If we try to add a new field to both of them with the same name (doesn't
 have to be of the same type), makemigrations only detects one of them:

 {{{
 class ModelA(models.Model):
 one_field = models.CharField(...)
 repeated_field = models.CharField(...)

 class ModelB(models.Model):
 another_field = models.CharField(...)
 repeated_field = models.BooleanField()
 }}}

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

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

Re: [Django] #29993: Bug trying to add two fields with the same name in two models

[Django]

#29993: Bug trying to add two fields with the same name in two models
+--
 Reporter:  César García Tapia  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  2.0
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by César García Tapia):

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


Comment:

 I'm sorry, it was my fault, not django's. I had a @property in the model
 with the same name, and that's why it wasn't detected by makemigrations.

 Sorry for the noise. :-(

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

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

Re: [Django] #27813: BinaryField type inconsistent between sqlite3 (bytes) and postgresql (memoryview)

[Django]

#27813: BinaryField type inconsistent between sqlite3 (bytes) and postgresql
(memoryview)
-+-
 Reporter:  Antonio Terceiro |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Václav Řehák):

 The same applies to Oracle backend which also returns bytes. One of the
 reasons we use Django in current project is that we can run it on Oracle
 (as needed due to historical reasons) but hopefully convert it to
 PostgreSQL one day. Subtle differences like this make it more complicated.
 What is the reason to return different data type from PostgreSQL backend?

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

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

Re: [Django] #27813: BinaryField type inconsistent between sqlite3 (bytes) and postgresql (memoryview)

[Django]

#27813: BinaryField type inconsistent between sqlite3 (bytes) and postgresql
(memoryview)
-+-
 Reporter:  Antonio Terceiro |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 My guess is that's how the database or database driver (psycopg2) works.

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

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

Re: [Django] #29929: ModelAdmin.prepopulated_fields crashing admin when showing read-only view

[Django]

#29929: ModelAdmin.prepopulated_fields crashing admin when showing read-only 
view
-+-
 Reporter:  Sébastiaan Versteeg  |Owner:  Basil
 |  Dubyk
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   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 Tim Graham):

 * needs_better_patch:  0 => 1


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

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

[Django] #29994: Document performance issues in FileBasedCache

[Django]

#29994: Document performance issues in FileBasedCache
-+
   Reporter:  matkoniecz |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  2.1
   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  |
-+
 https://docs.djangoproject.com/en/2.1/topics/cache/#filesystem-caching is
 not mentioning any problems with FileBasedCache

 According to https://github.com/grantjenks/python-diskcache#diskcache-
 disk-backed-cache "Unfortunately the file-based cache in Django is
 essentially broken. The culling method is random and large caches
 repeatedly scan a cache directory which slows linearly with growth. Can
 you really allow it to take sixty milliseconds to store a key in a cache
 with a thousand items?"

 From my checking it seems to not be reported so far.

 According to https://github.com/grantjenks/python-
 diskcache/issues/93#issuecomment-442580191 "The deficiencies of
 FileBasedCache are too well known to require enumeration" but it would be
 nice to warn also developers unaware of this problems.

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

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

Re: [Django] #29994: Document performance issues in FileBasedCache

[Django]

#29994: Document performance issues in FileBasedCache
---+--
 Reporter:  matkoniecz |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by matkoniecz):

 * needs_docs:  0 => 1


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

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

[Django] #29995: Customize Technical Error Response Template

[Django]

#29995: Customize Technical Error Response Template
+
   Reporter:  Matthew Pava  |  Owner:  (none)
   Type:  Cleanup/optimization  | Status:  new
  Component:  Error reporting   |Version:  2.1
   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 really appreciate the error response, but I recently switched my display
 to high-contrast mode.  Unfortunately, the default color scheme for the
 response template is not legible in high contrast mode.  I envision two
 paths here:  Either allow full customization of the technical error
 response template or choose a color scheme that will work effectively in
 high-contrast mode and non-high-contrast mode.

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

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

Re: [Django] #29995: Customize Technical Error Response Template

[Django]

#29995: Customize Technical Error Response Template
-+-
 Reporter:  Matthew Pava |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Error reporting  |  Version:  2.1
 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 Matthew Pava):

 * Attachment "high-contrast-mode.png" added.

 Screenshot of high-contrast mode technical error page

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

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

Re: [Django] #29995: Customize Technical Error Response Template

[Django]

#29995: Customize Technical Error Response Template
-+-
 Reporter:  Matthew Pava |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Error reporting  |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Matthew Pava:

Old description:

> I really appreciate the error response, but I recently switched my
> display to high-contrast mode.  Unfortunately, the default color scheme
> for the response template is not legible in high contrast mode.  I
> envision two paths here:  Either allow full customization of the
> technical error response template or choose a color scheme that will work
> effectively in high-contrast mode and non-high-contrast mode.

New description:

 I really appreciate the error response, but I recently switched my display
 to high-contrast mode.  Unfortunately, the default color scheme for the
 response template is not legible in high contrast mode.  I envision two
 paths here:  Either allow full customization of the technical error
 response template or choose a color scheme that will work effectively in
 high-contrast mode and non-high-contrast mode.  I've added a screenshot so
 that you can see what I'm seeing.

--

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

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

Re: [Django] #28205: Document that ModelAdmin.prepopulated_fields only works on empty forms

[Django]

#28205: Document that ModelAdmin.prepopulated_fields only works on empty forms
-+-
 Reporter:  Ju   |Owner:  Botond
 Type:   |  Béres
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  prepopulated_fields  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"a9d9680ea344a243f6e3ed7d0ad8031172458b9a" a9d9680e]:
 {{{
 #!CommitTicketReference repository=""
 revision="a9d9680ea344a243f6e3ed7d0ad8031172458b9a"
 [2.1.x] Refs #28205 -- Corrected ModelAdmin.prepopulated_fields docs
 regarding when they're populated.

 Backport of 682cdf6cab8cb76ef1808df45631c39748052e13 from master.
 }}}

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

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

Re: [Django] #28205: Document that ModelAdmin.prepopulated_fields only works on empty forms

[Django]

#28205: Document that ModelAdmin.prepopulated_fields only works on empty forms
-+-
 Reporter:  Ju   |Owner:  Botond
 Type:   |  Béres
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  prepopulated_fields  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"682cdf6cab8cb76ef1808df45631c39748052e13" 682cdf6c]:
 {{{
 #!CommitTicketReference repository=""
 revision="682cdf6cab8cb76ef1808df45631c39748052e13"
 Refs #28205 -- Corrected ModelAdmin.prepopulated_fields docs regarding
 when they're populated.
 }}}

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

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

Re: [Django] #29995: Make the technical error response more legible when using high contrast mode (was: Customize Technical Error Response Template)

[Django]

#29995: Make the technical error response more legible when using high contrast
mode
--+
 Reporter:  Matthew Pava  |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Error reporting   |  Version:  2.1
 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 Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 I don't have knowledge about how high contrast mode works but I guess it
 should be possible for things to "just work".

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

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

Re: [Django] #29994: Document performance issues in FileBasedCache

[Django]

#29994: Document performance issues in FileBasedCache
---+--
 Reporter:  matkoniecz |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Grant Jenks):

 Related, and much older issue: https://code.djangoproject.com/ticket/11260

 I agree that the file-based caching docs could be improved to described
 the limitations. I would also welcome a link to the Disk Cache project
 (disclaimer: I'm the author.)

 For the Django developers, please don't think Disk Cache is a criticism of
 Django's file-based cache. I love Django! The Disk Cache project is
 thousands of lines of code with many non-Django users. I don't think the
 code nor design is appropriate for inclusion in Django.

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

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

Re: [Django] #29994: Document performance issues in FileBasedCache

[Django]

#29994: Document performance issues in FileBasedCache
--+
 Reporter:  matkoniecz|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 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 Tim Graham):

 * needs_docs:  1 => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 The Django documentation avoids endorsing third-party packages because of
 the burden of curation this would present. I think we would need a
 consensus on the DevelopersMailingList to do that.

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

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

Re: [Django] #11260: File based cache not very efficient with large amounts of cached files

[Django]

#11260: File based cache not very efficient with large amounts of cached files
-+-
 Reporter:  anteater_sa  |Owner:  josh
 Type:  Uncategorized|   Status:  closed
Component:  Core (Cache system)  |  Version:  1.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  filebased file   | Triage Stage:  Design
  cache  |  decision needed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by matkoniecz):

 https://code.djangoproject.com/ticket/29994#ticket is related issue that
 proposed explicitly documenting this performance issues

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

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

Re: [Django] #29994: Document performance issues in FileBasedCache

[Django]

#29994: Document performance issues in FileBasedCache
--+
 Reporter:  matkoniecz|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by matkoniecz):

 From #11260 - ""I'm going to wontfix, on the grounds that the filesystem
 cache is intended as an easy way to test caching, not as a serious caching
 strategy. The default cache size and the cull strategy implemented by the
 file cache should make that obvious.""

 Would it be OK to submit patch that for start will add something like
 "Note that this caching strategy is useful only for development and should
 not be used in production" ?

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

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

Re: [Django] #29995: Make the technical error response more legible when using high contrast mode

[Django]

#29995: Make the technical error response more legible when using high contrast
mode
-+-
 Reporter:  Matthew Pava |Owner:  Zach
 Type:   |  Garwood
  Cleanup/optimization   |   Status:  assigned
Component:  Error reporting  |  Version:  2.1
 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 Zach Garwood):

 * status:  new => assigned
 * owner:  (none) => Zach Garwood


Comment:

 I'm currently learning more about accessibility best practices and would
 love to tackle this issue.

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

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

Re: [Django] #29929: ModelAdmin.prepopulated_fields crashing admin when showing read-only view

[Django]

#29929: ModelAdmin.prepopulated_fields crashing admin when showing read-only 
view
-+-
 Reporter:  Sébastiaan Versteeg  |Owner:  Basil
 |  Dubyk
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   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 Tim Graham ):

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


Comment:

 In [changeset:"7d1123e5ada60963ba3c708a8932e57342278706" 7d1123e5]:
 {{{
 #!CommitTicketReference repository=""
 revision="7d1123e5ada60963ba3c708a8932e57342278706"
 Fixed #29929 -- Fixed admin view-only change form crash when using
 ModelAdmin.prepopulated_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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.38069e811b65adeb2a01eafb76d97b03%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29929: ModelAdmin.prepopulated_fields crashing admin when showing read-only view

[Django]

#29929: ModelAdmin.prepopulated_fields crashing admin when showing read-only 
view
-+-
 Reporter:  Sébastiaan Versteeg  |Owner:  Basil
 |  Dubyk
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   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 Tim Graham ):

 In [changeset:"381bdd4898bffbe1cbd3020826e6bf4c7cc63254" 381bdd48]:
 {{{
 #!CommitTicketReference repository=""
 revision="381bdd4898bffbe1cbd3020826e6bf4c7cc63254"
 [2.1.x] Fixed #29929 -- Fixed admin view-only change form crash when using
 ModelAdmin.prepopulated_fields.

 Backport of 7d1123e5ada60963ba3c708a8932e57342278706 from master.
 }}}

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

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

Re: [Django] #29992: Error in admin checking list_display items

[Django]

#29992: Error in admin checking list_display items
-+--
 Reporter:  gtoffoli |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by gtoffoli):

 In my view #29636 correctly identifies the commit at the origin of the
 problem, but doesn't explain the cause.
 My case is very similar but it involves only ''CharField'' and
 ''TextField'', not a field class I defined, nor, for example,
 ''IntegerField''.
 And, as far as I can understand, these field classes haven't the
 ''__get__'' method at all.

 An excerpt of my code follows


 {{{
 @python_2_unicode_compatible
 class Repo(models.Model):
 name = models.CharField(max_length=255, db_index=True,
 verbose_name=_('name'))
 description = models.TextField(blank=True, null=True,
 verbose_name=_('short description'))
 state = models.IntegerField(choices=PUBLICATION_STATE_CHOICES,
 default=DRAFT, null=True, verbose_name='publication state')
 ...
 }}}



 {{{
 class RepoAdmin(admin.ModelAdmin):
 list_display = ('id', 'name', 'slug', 'description', 'repo_type',
 'state', 'user_fullname', 'created', 'modified',)
 ...

 }}}

 and this is an excerpt of the error log:


 {{{
 : (admin.E108) The value of
 'list_display[1]' refers to 'name', which is not a callable, an attribute
 of 'RepoAdmin', or an attribute or method on 'commons.Repo'.
 : (admin.E108) The value of
 'list_display[3]' refers to 'description', which is not a callable, an
 attribute of 'RepoAdmin', or an attribute or method on 'commons.Repo'.

 }}}

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

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

[Django] #29996: QuerySet.extra using contains, startswith on integerfield

[Django]

#29996: QuerySet.extra using contains, startswith on integerfield
-+
   Reporter:  openafox   |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Uncategorized  |Version:  2.1
   Severity:  Normal |   Keywords:  QuerySet.extra
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Reporting my use as requested in docs
 https://docs.djangoproject.com/en/2.1/ref/models/querysets/#extra

 Maybe I'm doing something strange?
 Ex.
 qs = qs.extra(where=["foreignkey_id LIKE %s + '%%'"], params=[param])

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

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

Re: [Django] #29992: Error in admin checking list_display items

[Django]

#29992: Error in admin checking list_display items
-+--
 Reporter:  gtoffoli |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tim Graham):

 I don't get a check error with the excerpt you provided. Please provide a
 minimal project that demonstrates the issue.

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

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

Re: [Django] #29996: QuerySet.extra using contains, startswith on integerfield

[Django]

#29996: QuerySet.extra using contains, startswith on integerfield
-+-
 Reporter:  openafox |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid
 * component:  Uncategorized => Database layer (models, ORM)


Old description:

> Reporting my use as requested in docs
> https://docs.djangoproject.com/en/2.1/ref/models/querysets/#extra
>
> Maybe I'm doing something strange?
> Ex.
> qs = qs.extra(where=["foreignkey_id LIKE %s + '%%'"], params=[param])

New description:

 Reporting my use as requested in docs
 https://docs.djangoproject.com/en/2.1/ref/models/querysets/#extra

 Maybe I'm doing something strange?
 Ex.
 `qs = qs.extra(where=["foreignkey_id LIKE %s + '%%'"], params=[param])`

--

Comment:

 You can use a
 [https://docs.djangoproject.com/en/stable/ref/models/expressions/ query
 expression] for that. See TicketClosingReasons/UseSupportChannels to get
 help if the documentation isn't enough.

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

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

Re: [Django] #29969: Admin inline with view permission is shown when save_as validation fails

[Django]

#29969: Admin inline with view permission is shown when save_as validation fails
+
 Reporter:  Matija Kolarić  |Owner:  (none)
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  2.1
 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 Tim Graham):

 * severity:  Release blocker => Normal


Comment:

 Yea, the fix seems complicated enough that we might not consider this a
 release blocker. If someone provides a patch while 2.1 is still in bug fix
 mode, we could consider it. `ModelAdmin._changeform_view()` could  copy
 `object_id` to another variable before it's set to `None` on the line you
 mentioned. Then the inline relations need to be copied to the new object
 somehow. Maybe ` ModelAdmin._create_formsets()` could do it if `obj` is
 the original object and then the new object is swapped out for 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.c9fa491c2affad0e4349baf46728c855%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29994: Document performance issues in FileBasedCache

[Django]

#29994: Document performance issues in FileBasedCache
--+
 Reporter:  matkoniecz|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham):

 I'm not sure. I think ticket:11260#comment:9 is interesting: "I have
 Django sites of tens of thousands of pages running for over 2 years using
 the above patches, so your statements about filesystem caching not a
 serious strategy are irrelevant." The patch for #11260 is very simple and
 seems worth considering if it makes file-based caching usable in
 production. Do you have an opinion on that, Grant?

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

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