date:20240117

Re: [Django] #33497: Database persistent connections do not work with ASGI in 4.0

2024-01-17 Thread Django

#33497: Database persistent connections do not work with ASGI in 4.0
-+-
 Reporter:  Stenkar  |Owner:  Sarah
 |  Boyce
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ASGI, Database,  | Triage Stage:  Accepted
  async  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sarah Boyce):

 There is already a ticket (and now a PR) to support database connection
 pools in Oracle: #7732

-- 
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/0107018d1b10f2c0-72774037-f448-4716-ab6f-1d0da422245b-00%40eu-central-1.amazonses.com.

Re: [Django] #34036: Low text contrast over light blue backgrounds in admin light theme

2024-01-17 Thread Django

#34036: Low text contrast over light blue backgrounds in admin light theme
-+-
 Reporter:  Thibaud Colas|Owner:  Mariana
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  accessibility,   | Triage Stage:  Ready for
  color contrast, ux |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:16 Collin Anderson]:
 > Hi All, it seems to me that `a:link {color: var(--body-fg);}` is a
 Django 5.0 regression. Why did that get changed from `color: var(--link-
 fg);` ? This might get fixed in #34038 for future versions, but having
 links default to being the same color as body text seems to me to be a big
 accessibility regression in Django 5.0.

 Thanks for the report, I've created a separate ticket for this regression,
 #35121.

-- 
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/0107018d1ae8a6ac-e7c91a63-5ae9-419b-84ca-6866287919c6-00%40eu-central-1.amazonses.com.

[Django] #35121: Links in the admin should use the --link-fg color.

2024-01-17 Thread Django

#35121: Links in the admin should use the --link-fg color.
+
   Reporter:  Mariusz Felisiak  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.admin |Version:  5.0
   Severity:  Release blocker   |   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  1 |
+
 Links in the admin should use the `--link-fg` color. There is #34038 to
 improve links in the admin, however, this is a separate regression that
 should be fixed and backported to Django 5.0:

 {{{#!diff
 diff --git a/django/contrib/admin/static/admin/css/base.css
 b/django/contrib/admin/static/admin/css/base.css
 index aaa9c3441a..daf4699cac 100644
 --- a/django/contrib/admin/static/admin/css/base.css
 +++ b/django/contrib/admin/static/admin/css/base.css
 @@ -102,7 +102,7 @@ body {
  /* LINKS */

  a:link, a:visited {
 -color: var(--body-fg);
 +color: var(--link-fg);
  text-decoration: none;
  transition: color 0.15s, background 0.15s;
  }

 }}}

 Reported by [https://code.djangoproject.com/ticket/34036#comment:16
 Collin].

 Regression in 6ad2738a8f32b94cbae742f212080fadf2dee421.

-- 
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/0107018d1ae7c67d-0e566ff3-a68b-4c83-91c5-552737acb3fa-00%40eu-central-1.amazonses.com.

Re: [Django] #32340: Usability issues with Django form fields expecting specific patterns

2024-01-17 Thread Django

Comment (by Thibaud Colas):

See PR [Accessibility guidelines for all contributors #17338
https://github.com/django/django/pull/17338] for the next step on adding
accessibility docs in Django. After this, I believe [Add guidelines for
accessibility in documentation #17340
https://github.com/django/django/pull/17340] will be a good step in adding
accessibility considerations in documentation.

After _that_, I think we’ll be in an excellent place for someone to pick
up this ticket and write the right docs. We don’t necessarily need all of
this to be merged though if someone wants to already take a look. A good
first step would be to identify where in Django’s documentation we could
document what’s discussed in this ticket.

--
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/0107018d18f9f682-9575ce8f-48f9-4f71-9c6e-1f319e7f8a5f-00%40eu-central-1.amazonses.com.

Re: [Django] #34976: startproject and startapp should provide feedback

2024-01-17 Thread Django

#34976: startproject and startapp should provide feedback
-+-
 Reporter:  Thibaud Colas|Owner:  Salvo
 Type:   |  Polizzi
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  tutorial, command,   | Triage Stage:  Accepted
  startproject, startapp |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Thibaud Colas):

 New PR: [https://github.com/django/django/pull/17722 Refs #34976 --
 Provide feedback when startapp and startproject are called #17722] by
 @salvo-polizzi

-- 
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/0107018d18f44c40-d037be88-b78e-4544-8466-1ccad662dc87-00%40eu-central-1.amazonses.com.

Re: [Django] #31700: Highlight destructive operations in makemigrations output

2024-01-17 Thread Django

#31700: Highlight destructive operations in makemigrations output
-+-
 Reporter:  Tom Forbes   |Owner:  Amir Karimi
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"27a3eee72170f1eb994a213db985f42c6cf5f994" 27a3eee7]:
 {{{
 #!CommitTicketReference repository=""
 revision="27a3eee72170f1eb994a213db985f42c6cf5f994"
 Fixed #31700 -- Made makemigrations command display meaningful symbols for
 each 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/0107018d18f1ab93-e2dfb216-b2d9-4c64-b6a3-f54c9daf2b1a-00%40eu-central-1.amazonses.com.

Re: [Django] #34038: Low text contrast and no visual cues for links within body text in admin UI

2024-01-17 Thread Django

Comment (by Natalia Bidart):

Pasting
[https://github.com/django/django/pull/17419#pullrequestreview-1820021243
the latest comment from the linked PR] to re-puporse this ticket for
providing admin link underlines:

{{{
We had a good chat about this at our latest @django/accessibility meeting.
We agreed that for now, we should just fix the colours and not add the
underline.
We should still do the underline part, but as a new ticket, because:
* The changes can easily be done separately.
* Because of the difficulty in deciding what should and shouldn't be
underlined, it's better to get the less contentious change out 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/0107018d184226a4-d840022f-0d54-4f48-abea-f8a457026ea3-00%40eu-central-1.amazonses.com.

Re: [Django] #34036: Low text contrast over light blue backgrounds in admin light theme

2024-01-17 Thread Django

#34036: Low text contrast over light blue backgrounds in admin light theme
-+-
 Reporter:  Thibaud Colas|Owner:  Mariana
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  accessibility,   | Triage Stage:  Ready for
  color contrast, ux |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Natalia Bidart):

 Replying to [comment:17 Tom Carrick]:
 > Colin, I agree that's a regression. On the PR you mention I've suggested
 only changing the colours so we can merge that faster. It should probably
 also be a release blocker.

 I'll comment about this in the linked ticket #34038 but I did not want to
 leave this unanswered. In general I would advice on commenting on
 active/open tickets instead of closed tickets, referencing the closed
 tickets as necessary. Thank you!

-- 
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/0107018d18129969-374ef619-dfb4-4f4f-b591-547056dc2be0-00%40eu-central-1.amazonses.com.

Re: [Django] #35118: Mention test-suggestions when specific email-backend is used

2024-01-17 Thread Django

Comment (by jecarr):

Replying to [comment:6 Natalia Bidart]:

Thanks Natalia, I understand this better.

> The thing is that, IMHO, when multiple email backends gets implemented,
the `connection` param will likely be deprecated in favor of an email
backend name, similar to how the database `using` parameter works. So,
considering both this goal and the fact that passing custom email
connection is not the common case, I really don't think is worth investing
time and resources into automagically mocking custom email connections.

I understand the resolution, I'll rewrite my code to avoid using the
connection parameter anyway.

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018d17e61513-e95c7dfd-5078-49f6-a0dd-f36a921070bc-00%40eu-central-1.amazonses.com.

Re: [Django] #35118: Mention test-suggestions when specific email-backend is used

2024-01-17 Thread Django

#35118: Mention test-suggestions when specific email-backend is used
-+-
 Reporter:  jecarr   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Mail)  |  Version:  5.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

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


Comment:

 Replying to [comment:5 jecarr]:
 > I believed I was following the docs anyway: I didn't change the
 `EMAIL_BACKEND` setting in my project. I just used an
 [https://docs.djangoproject.com/en/5.0/topics/email/#smtp-backend SMTP
 EmailBackend] instance as my `connection` parameter when creating an
 `EmailMessage` or to call `connection.send_messages()`.

 The usual pattern and recommended approach to change the email backend is
 to change the `EMAIL_BACKEND` setting. In fact, the docs you linked say:

 ''The SMTP backend is the default configuration inherited by Django. If
 you want to specify it explicitly, put the following in your settings:
 `EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"`''

 > This then mirrors Baptiste Mispelon's code example on how my test cases
 sent actual emails:

 I do understand your use case now, thank you and thanks Baptiste for the
 clarification. Still, building a backend instance and passing it
 explicitly to `send_email`, while supported, is not the common case.
 Passing a `connection` is usually done when a different/specific backend
 is needed for a specific email message. And to be clear, I'm not saying
 that your code is incorrect, I'm saying that the usual way of using the
 `SMTP` backend (or any other backend across a project) is to override the
 setting, for which the Django ` setup_test_environment` has support.

 > > We may consider adding a note in the docs, but the clarification
 should be quite explicit about *when* a backend override is needed in
 tests, since the proposed PR could be read as that the tests always need
 an override (when, in practice, they almost never need one).
 >
 > I thought I was explicit about when the override is needed? My PR begins
 with "If your application defines a different email backend to be used
 [other than locmem]".

 Is not explicit in that the most common approach associated with "your
 application defines a different email backend" is to override the
 `EMAIL_BACKEND` setting. If we were to add a clarification to the docs
 (I'm not convinced yet), it should clearly state that the test override is
 needed only in those less common cases where a connection is passed
 explicitly in the code.

 Something along the lines:

 {{{
 .. admonition:: Testing email sending with custom connections

If your email sending code explicitly passes a `connection` object,
 ensure
that tests appropriately handle the connection to prevent the actual
 sending
of emails during test runs. In such cases, consider using mocking
 techniques
to simulate the behavior of the connection without triggering actual
 email
delivery.
 }}}

 > edit - I see what you mean, I meant if a connection parameter is used as
 opposed to if a different email backend is used.

 Yes, exactly!

 > Replying to [comment:1 Baptiste Mispelon]:
 > > I think we should try to find a systematic solution to the problem but
 if that's too hard we should at least document quite loudly that one must
 pay attention when using a custom `connection`.
 >
 > I therefore think this point still stands rather than this being about
 multiple email backends (do point out if I'm misunderstanding how that
 links!).

 The thing is that, IMHO, when multiple email backends gets implemented,
 the `connection` param will likely be deprecated in favor of an email
 backend name, similar to how the database `using` parameter works. So,
 considering both this goal and the fact that passing custom email
 connection is not the common case, I really don't think is worth investing
 time and resources into automagically mocking custom email connections.

-- 
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

Re: [Django] #31700: Highlight destructive operations in makemigrations output

2024-01-17 Thread Django

#31700: Highlight destructive operations in makemigrations output
-+-
 Reporter:  Tom Forbes   |Owner:  Amir Karimi
 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/0107018d177b4b2c-fc06a13f-3fe7-466b-95ab-26c12a3b2c88-00%40eu-central-1.amazonses.com.

Re: [Django] #5865: cycle template tag should accept a single argument

2024-01-17 Thread Django

#5865: cycle template tag should accept a single argument
-+-
 Reporter:  Gary Wilson  |Owner:  Alexander
 |  Lazarević
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Alexander Lazarević):

 After the discussion in https://forum.djangoproject.com/t/cycle-template-
 tag-should-accept-a-single-argument/27010/3 I'm withdrawing the PR.

 My implementation would have introduced an ambiguity that would have had
 it made it harder for users to use the `cycle` tag.

 In the discussion @carlton mentioned that it could be worth "... to
 investigate [is] whether we could add * and ** list and dictionary
 expansion to the DTL. cycle could benefit from list expansion.".

 So I'm trying to come up with something in that direction instead.

-- 
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/0107018d17441f68-c9369ff0-abff-4f0f-9366-344052834df0-00%40eu-central-1.amazonses.com.

Re: [Django] #34060: Creating CheckConstraint on JSONField with __exact lookup on key transforms crashes on Oracle.

2024-01-17 Thread Django

#34060: Creating CheckConstraint on JSONField with __exact lookup on key 
transforms
crashes on Oracle.
-+-
 Reporter:  Mariusz Felisiak |Owner:  raydeal
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by raydeal):

 This error is because JSON is stored in NCLOB database type but according
 to Oracle documentation:
   Oracle Database does not support constraints on columns or attributes
 whose type is a LOB, with the following exception: NOT NULL constraints
 are supported for a LOB column or attribute.

 The exact check should be implemented differently to work with JSON in
 LOB. I am working on 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/0107018d173ddf9a-32497ffb-9f48-4af0-bf02-161e7b3d3419-00%40eu-central-1.amazonses.com.

Re: [Django] #35118: Mention test-suggestions when specific email-backend is used

2024-01-17 Thread Django

#35118: Mention test-suggestions when specific email-backend is used
-+-
 Reporter:  jecarr   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Mail)  |  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jecarr):

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


Comment:

 Replying to [comment:4 Natalia Bidart]:

 Thanks for the discussion on this.

 > If a custom but single backend is needed across the project, the
 recommendation would be to define the custom backend class and point the
 `EMAIL_BACKEND` setting to it (as per
 [https://docs.djangoproject.com/en/5.0/topics/email/#defining-a-custom-
 email-backend these docs]). In this case, the previously linked
 `setup_test_environment` would do the right thing by overriding the
 `EMAIL_BACKEND` setting to be `locmem`.

 I believed I was following the docs anyway: I didn't change the
 `EMAIL_BACKEND` setting in my project. I just used an
 [https://docs.djangoproject.com/en/5.0/topics/email/#smtp-backend SMTP
 EmailBackend] instance as my `connection` parameter when creating an
 `EmailMessage` or to call `connection.send_messages()`.

 This then mirrors Baptiste Mispelon's code example on how my test cases
 sent actual emails:


 {{{
 from django.core import mail
 from django.core.mail.backends.smtp import EmailBackend
 from django.test import SimpleTestCase

 def send_message():
 mail.send_mail(
 "Subject here",
 "Here is the message.",
 "f...@example.com",
 ["t...@example.com"],
 fail_silently=False,
 connection=EmailBackend()  # comment out to pass test
 )


 class ReproductionTestCase(SimpleTestCase):
 def test_custom_backend_bypass_locmem(self):
 send_message()
 self.assertEqual(len(mail.outbox), 1)
 }}}

 > We may consider adding a note in the docs, but the clarification should
 be quite explicit about *when* a backend override is needed in tests,
 since the proposed PR could be read as that the tests always need an
 override (when, in practice, they almost never need one).

 I thought I was explicit about when the override is needed? My PR begins
 with "If your application defines a different email backend to be used
 [other than locmem]". This was applicable to my scenario above because I
 was defining an SMTP backend. I did link
 [https://github.com/django/django/pull/17741 the PR] when I opened my
 ticket but it seems to be unlinked at time of writing.

 Replying to [comment:1 Baptiste Mispelon]:
 > I think we should try to find a systematic solution to the problem but
 if that's too hard we should at least document quite loudly that one must
 pay attention when using a custom `connection`.

 I therefore think this point still stands rather than this being about
 multiple email backends (do point out if I'm misunderstanding how that
 links!).

-- 
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/0107018d16f9945e-7cb47087-70ee-4522-9c7b-9042ed9e7713-00%40eu-central-1.amazonses.com.

Re: [Django] #35115: Empty footer element in main section of admin layout

2024-01-17 Thread Django

#35115: Empty footer element in main section of admin layout
-+-
 Reporter:  Marijke Luttekes |Owner:  Marijke
 Type:   |  Luttekes
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  HTML | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Marijke Luttekes):

 Thank you, I will pick it up!

-- 
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/0107018d16b7b06c-535b288e-629b-48a1-aac4-089884fd6dae-00%40eu-central-1.amazonses.com.

Re: [Django] #33497: Database persistent connections do not work with ASGI in 4.0

Re: [Django] #34036: Low text contrast over light blue backgrounds in admin light theme

[Django] #35121: Links in the admin should use the --link-fg color.

Re: [Django] #32340: Usability issues with Django form fields expecting specific patterns

Re: [Django] #34976: startproject and startapp should provide feedback

Re: [Django] #31700: Highlight destructive operations in makemigrations output

Re: [Django] #34038: Low text contrast and no visual cues for links within body text in admin UI

Re: [Django] #34036: Low text contrast over light blue backgrounds in admin light theme

Re: [Django] #35118: Mention test-suggestions when specific email-backend is used

Re: [Django] #35118: Mention test-suggestions when specific email-backend is used

Re: [Django] #31700: Highlight destructive operations in makemigrations output

Re: [Django] #5865: cycle template tag should accept a single argument

Re: [Django] #34060: Creating CheckConstraint on JSONField with __exact lookup on key transforms crashes on Oracle.

Re: [Django] #35118: Mention test-suggestions when specific email-backend is used

Re: [Django] #35115: Empty footer element in main section of admin layout

15 matches

Site Navigation

Mail list logo

Footer information