Re: Update returning

Hi all I asked a question on the Django forums about whether it would be possible to use the RETURNING SQL clause when calling `save()` on a Django model instance. In that thread I got pointed here, whic

Re: Moving discussions to the forum

Thank you Karen! For anyone wanting even more context on this, here is the corresponding forum thread: Proposal: retiring django-users and django-developers mailing lists -- You receive

Re: Django 5.2 beta 1 released

Thank you Sarah! And thank you to everyone who’s been testing those pre-releases so far ⭐️ On Wednesday, 19 February 2025 at 11:02:46 UTC Sarah Boyce wrote: > Details are available on the Django project weblog: > https://www.djangoproject.com/weblog/2025/feb/19/django-52-beta-1-released/ > --

Re: Introduction & Contribution Interest – Django

Hello Ahmed The forum is way more active these days. It's worth repeating your introduction there, perhaps under membership: https://forum.djangoproject.com/c/internals/mentorship/10 . Balaji, you can also try asking there for support. Good luck all. On Fri, 14 Feb 2025, at 01:02, Thamarai Se

Re: Introduction & Contribution Interest – Django

Hi Balaji, If you add token validation globally like using session or jwt token authentication in middleware , generally all requests comes under the token validation in other words all endpoints are protected. But we will get token after login successfully. So here you have to make the login en

Re: Introduction & Contribution Interest – Django

Please share the specific piece of code where this token is being created. On Thu, Feb 13, 2025, 8:31 PM BALAJI V wrote: > Hi, I'm new to Django. When I try to generate a login token, I receive > these errors: > json > CopyEdit > {"detail": "Authentication credentials were not provided."} > {"er

Re: Hi everyone I am the beginner django back end developer.

Hi Balaji, Make sure you are correctly sending credentials (e.g., username and password) to the login endpoint. Typically, the request should be something like: curl -X POST "https://yourapi.com/api/login/"; \ -H "Content-Type: application/json" \ -d '{"username": "username", "password":

Re: Introduction & Contribution Interest – Django

Hi, I'm new to Django. When I try to generate a login token, I receive these errors: json CopyEdit {"detail": "Authentication credentials were not provided."} {"error_short": "Module is not Assigned", "status": "failed"} Any help resolving these issues would be appreciated. Thanks! On Saturda

Re: Use of TIME_INPUT_FORMATS in TimeField

hello I'm new to Django Developer anyone can share learning document? On Mon, Dec 9, 2024 at 5:03 PM Arthur Pemberton wrote: > Adam, > > Up until now, I've only been reading the test. Now that I actually tried > running the test, it does not get discovered by the testing system (without > modifi

Re: How to run the CustomTimeInputFormatsTests unit test?

I've submitted https://code.djangoproject.com/ticket/35986 If I'm missing something, please let me know. Arthur Pemberton On Monday, December 9, 2024 at 5:12:57 AM UTC-5 Bendegúz Csirmaz wrote: > Yes you're right, it's not executed for me either. > > On Monday, 9 December 2024 at 17:53:16 UTC+

Re: How to run the CustomTimeInputFormatsTests unit test?

Yes you're right, it's not executed for me either. On Monday, 9 December 2024 at 17:53:16 UTC+8 Arthur Pemberton wrote: > I've read through > https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/ > > and I'm still uncertain how to properly run it. > > As far as

Re: Use of TIME_INPUT_FORMATS in TimeField

Adam, Up until now, I've only been reading the test. Now that I actually tried running the test, it does not get discovered by the testing system (without modifications to test_input_formats.py) and when I do get the test to run, it fails. I used tag "5.1.4" to get the unit tests. Arthur On

Re: Use of TIME_INPUT_FORMATS in TimeField

As further follow up on this, as far as I can tell, the relevant unit test does not run, seemingly due to the use of `translation.override(None)` Removing, that, and running the test `./runtests.py forms_tests.tests.test_input_formats.CustomTimeInputFormatsTests.test_timeField` results in the

Re: Use of TIME_INPUT_FORMATS in TimeField

To simplify things further, within a view: TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M', '%I:%M %p'] and forms.TimeField.input_formats = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M'] On Sun, Dec 8, 2024 at 9:55 AM Arthur Pemberton wrote: > I finally got back to this. > > I have a failing m

Re: Use of TIME_INPUT_FORMATS in TimeField

I finally got back to this. I have a failing minimal project (not test) that demonstrates TIME_INPUT_FORMATS not being respected: https://github.com/pembo13/dateentry In the example, the form should be valid, if TIME_INPUT_FORMATS worked as documented. I _think_ there's something about how the u

Re: GSOC2025

Thankyou Sir On Sunday, November 3, 2024 at 2:23:31 PM UTC+5:30 Shai Berger wrote: > Hi pavanMudavath, > > You can join a Discord server at https://discord.gg/T8w8fjbh > but the canonical place for discussion these days is the forum > https://forum.djangoproject.com/ > you probably want to start a

Re: GSOC2025

Hi pavanMudavath, You can join a Discord server at https://discord.gg/T8w8fjbh but the canonical place for discussion these days is the forum https://forum.djangoproject.com/ you probably want to start at the "Mentorship" category https://forum.djangoproject.com/c/internals/mentorship/10 Hope thi

Re: Request to contribute in Django

Thanks a lot it helped me out a lot. I also wanted to ask that I am going through the code of whole project now a days. Should I spend time on that part. On Friday, September 20, 2024 at 8:41:20 PM UTC+5:30 Tim Graham wrote: > Hi Anant, > https://docs.djangoproject.com/en/dev/internals/contribu

Re: Request to contribute in Django

Hi Anant, https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/ is a good place to start. On Monday, September 16, 2024 at 1:03:21 PM UTC-4 Anant Chitranshi wrote: > Dear All, > I am Anant Chitranshi. I wish to contribute to django. Can you please help > me to start? >

Re: Django security releases issued: 5.1.1, 5.0.9, and 4.2.16

Hello Uri, This is expected, the release notes take some time to get built in the remote server that serves them. For security releases in particular, the CVE-fixing notes are pushed "fresh" at the time of the release, so they are not pre-built as with usual bug fixes. Natalia. On Tuesday, Sep

Re: Django security releases issued: 5.1.1, 5.0.9, and 4.2.16

Hi, I noticed that Django 4.2.16 release notes (and the other versions released today) are not updated: https://docs.djangoproject.com/en/5.1/releases/4.2.16/ This happens usually every time after a new release. Is it possible to fix it? Thanks, Uri Rodberg, Speedy Net. אורי u...@speedy.net On

Re: Escaping of JSON attributes and CVE-2024-42005

Hello Ole, this was discussed during the security enforcement patch design but wasn't part of the public announcement unfortunately. The solution is to alias a KT[0] expression and then filter against it. In you particular example that would be from django.db.models import KT SomeModel.objects

Re: Django Firebird driver update for Django 5.0

Hi Mariuz This mailing list isn't really a venue for announcing package updates. The forum is a lot more active these days, and the “Show & Tell” section is for announcing projects and updates: https://forum.djangoproject.com/c/projects/11 . Try it there! I also think you could improve the ann

Re: Celery Working Limitations Updates

Huey used to work in Windows just fine. On Thursday, August 22, 2024 at 5:13:49 PM UTC+3 Muhammad Shariq Shafiq wrote: > Hello Dear Django Team > > Last month, I tried to do some task of django which primarily based on > scheduling of accessibility with time and role based authnetications > >

Re: Celery Working Limitations Updates

Ok Ken thank you for clarifying I think that blog and research would be misleading. Sorry for saying all that. I love Django as it's my core tech stack Regards On Thu, Aug 22, 2024, 7:39 PM Cory Zue wrote: > I agree with Ken, that this a Celery issue, not a Django one. > > But while we're here

Re: Celery Working Limitations Updates

I agree with Ken, that this a Celery issue, not a Django one. But while we're here, as far as I know Celery still runs fine on windows. It is not officially supported, and the default pool no longer works, but if you run celery with --pool=solo (in development) or --pool=gevent (in production) it

Re: Celery Working Limitations Updates

I think you're misinterpreting what you're reading from your search results. This is a Celery issue, not a Django issue. Quoting from the Celery docs at https://docs.celeryq.dev/en/stable/faq.html#does-celery-support-windows - Does Celery supportWindows?

Re: Proposal to upgrade django.core.mail to Python's modern email API

PRs are now open: 1. Updated test cases (on existing legacy implementation): https://github.com/django/django/pull/18502 2. Change to modern email API: https://github.com/medmunds/django/pull/2 A few changes of note from the original plan, based on things discovered during implementati

Re: Cookies with Django

Thank you. אורי u...@speedy.net On Fri, Aug 9, 2024 at 9:08 AM Jacob Rief wrote: > Hi Uri, > we are running a large Django site in Austria. As cookies we use > session-ids, csrf-tokens and the preferred language. By our legal team, > they all are considered as strictly necessary and hence we

Re: Cookies with Django

Hi Uri, we are running a large Django site in Austria. As cookies we use session-ids, csrf-tokens and the preferred language. By our legal team, they all are considered as strictly necessary and hence we do not have to ask for consent from our users. This btw. only applies to assets served by o

Re: Cookies with Django

Thank you. אורי u...@speedy.net On Fri, Aug 9, 2024 at 5:40 AM Curtis Maloney wrote: > {I am not a lawyer. None of this is legal advice, of course.} > > Django itself does nothing to tell your users authentication uses cookies. > > If and how you choose to do that is up to you; also, there are

Re: Cookies with Django

{I am not a lawyer. None of this is legal advice, of course.} Django itself does nothing to tell your users authentication uses cookies. If and how you choose to do that is up to you; also, there are some 3rd party apps to try to make this easier. However, I find this paragraph from https://gdp

Re: Django 5.1 - LoginRequiredMiddleware

Hi, I read the updated Django 5.1 release notes and I think now it's more clear that LoginRequiredMiddleware is only enabled if we enable it, and is not enabled by default. Thanks, Uri. אורי u...@speedy.net On Wed, Aug 7, 2024 at 9:29 AM Adam Johnson wrote: > I’ve opened a PR for a small docs

Re: Django 5.1 - LoginRequiredMiddleware

Thank you. אורי u...@speedy.net On Wed, Aug 7, 2024 at 10:29 AM Adam Johnson wrote: > I’ve opened a PR for a small docs tweak that may help clarify the release > note: https://github.com/django/django/pull/18455 . > > On Wed, 7 Aug 2024, at 01:29, אורי wrote: > > > אורי > u...@speedy.net > > >

Re: Django 5.1 - LoginRequiredMiddleware

I’ve opened a PR for a small docs tweak that may help clarify the release note: https://github.com/django/django/pull/18455 . On Wed, 7 Aug 2024, at 01:29, אורי wrote: > > אורי > u...@speedy.net > > > On Wed, Aug 7, 2024 at 3:17 AM James Bennett wrote: >> On Tue, Aug 6, 2024 at 4:37 PM אורי

Re: Django 5.1 - LoginRequiredMiddleware

אורי u...@speedy.net On Wed, Aug 7, 2024 at 3:17 AM James Bennett wrote: > On Tue, Aug 6, 2024 at 4:37 PM אורי wrote: > >> No. I didn't see in the documentation of LoginRequiredMiddleware >> any MIDDLEWARE setting. >> >> >> https://docs.djangoproject.com/en/5.1/ref/middleware/#django.contrib.a

Re: Django 5.1 - LoginRequiredMiddleware

On Tue, Aug 6, 2024 at 4:37 PM אורי wrote: > No. I didn't see in the documentation of LoginRequiredMiddleware > any MIDDLEWARE setting. > > > https://docs.djangoproject.com/en/5.1/ref/middleware/#django.contrib.auth.middleware.LoginRequiredMiddleware > > > https://docs.djangoproject.com/en/5.1/re

Re: Django 5.1 - LoginRequiredMiddleware

אורי u...@speedy.net On Tue, Aug 6, 2024 at 8:37 PM 'Adam Johnson' via Django developers (Contributions to Django itself) wrote: > Did you add the middleware to the MIDDLEWARE setting? > No. I didn't see in the documentation of LoginRequiredMiddleware any MIDDLEWARE setting. https://docs.djan

Re: Django 5.1 - LoginRequiredMiddleware

Did you add the middleware to the MIDDLEWARE setting? On Tue, 6 Aug 2024, at 17:19, אורי wrote: > Hi, > > I read about LoginRequiredMiddleware in Django 5.1 release notes, where it's > written "The new LoginRequiredMiddleware redirects all unauthenticated > requests to a login page." > > I wan

Re: Proposal to upgrade django.core.mail to Python's modern email API

> I wish this discussion was on the forum so I could mark Pankaj’s response as spam 😅 And here I was thinking it was another +1 (that also gently poked fun at my own overly-verbose tendencies). Speaking of the forum, I've taken the "combine EmailMessage and EmailMultiAlternatives" idea that w

Re: Proposal to upgrade django.core.mail to Python's modern email API

I wish this discussion was on the forum so I could mark Pankaj’s response as spam 😅 On Sun, 21 Jul 2024, at 08:26, Othniel Davidson wrote: > Thank you for the update > > On Sat, Jul 20, 2024 at 15:26 Pankaj Kumar wrote: >> Hi Sir, >>I hope this message finds you well. >> I am writing t

Re: Proposal to upgrade django.core.mail to Python's modern email API

Thank you for the update On Sat, Jul 20, 2024 at 15:26 Pankaj Kumar wrote: > Hi Sir, >I hope this message finds you well. > > I am writing to inform you that we have reviewed and decided to accept the > proposal to upgrade django.core.mail to Python's modern email API. We > believe that

Re: Proposal to upgrade django.core.mail to Python's modern email API

Hi Sir, I hope this message finds you well. I am writing to inform you that we have reviewed and decided to accept the proposal to upgrade django.core.mail to Python's modern email API. We believe that this upgrade will bring significant improvements to our system's performance and maintain

Re: Proposal to upgrade django.core.mail to Python's modern email API

On Saturday, July 6, 2024 at 11:17:35 AM UTC-7 Florian Apolloner wrote: On Saturday, July 6, 2024 at 12:30:32 AM UTC+2 Mike Edmunds wrote: Incidentally, I thought there was (used to be?) a policy that internal undocumented APIs were fair game for use by third-party libraries, subclassing, etc

Re: Proposal to upgrade django.core.mail to Python's modern email API

Ticket created: https://code.djangoproject.com/ticket/35581 On Friday, July 5, 2024 at 5:27:28 PM UTC-7 Mike Edmunds wrote: > Thanks to everyone for the feedback so far. > > It looks like all the responses to date are generally positive, and I > haven't seen any objections, so I'm going to open

Re: Proposal to upgrade django.core.mail to Python's modern email API

On Saturday, July 6, 2024 at 12:30:32 AM UTC+2 Mike Edmunds wrote: Incidentally, I thought there was (used to be?) a policy that internal undocumented APIs were fair game for use by third-party libraries, subclassing, etc., so long as they didn't start with an underscore. (But "private" undersc

Re: Proposal to upgrade django.core.mail to Python's modern email API

We recently had quite a struggle with programming a newsletter extension for django-cms, mainly around the html-mails with CID embedded images. I am not deep into the details, still want to express my support for the idea to reshape the email abstraction in django, thus +1. Cheers, Jörg -- Y

Re: Proposal to upgrade django.core.mail to Python's modern email API

Thanks to everyone for the feedback so far. It looks like all the responses to date are generally positive, and I haven't seen any objections, so I'm going to open a ticket. (Of course, additional feedback—positive or negative—and advice is very much appreciated.) Cheers, Mike -- You receive

Re: Proposal to upgrade django.core.mail to Python's modern email API

About MIMEBase attachments: I propose we continue supporting them in Django, without deprecation, for now. We can investigate adding support for the equivalent in Python's modern email API later, as a separate proposal. More details… On Wednesday, June 26, 2024 at 6:28:06 PM UTC-7 I wrote: > Tr

Re: Proposal to upgrade django.core.mail to Python's modern email API

On Friday, June 28, 2024 at 1:07:35 PM UTC-7 Florian Apolloner wrote: > Are all of those documented? If not we can simply remove them (especially if the deprecation implementation turns out to be a PITA). It sort of depends on the definition of "documented." I've dug into real-world usage; resul

Re: Proposal to upgrade django.core.mail to Python's modern email API

Adding my support for the suggested approach. Start small and central and step-by-step. 👍 > (I'm going to add a link in django-anymail's "you probably don't need proprietary ESP templates " docs.) Thanks! Much appreciated! And thx on your

Re: Proposal to upgrade django.core.mail to Python's modern email API

Hi Mike, overall the plan sounds good. I especially like the approach to "fix" the tests first. This can happen in an extra merge request and reviewed independently so we can be sure that we are still testing what we want to test before moving to the tricky parts. On Thursday, June 27, 2024 at

Re: Proposal to upgrade django.core.mail to Python's modern email API

t;- >> >>*BadAddressHeader:* is a ValueError subclass raised only by >>forbid_multi_line_headers()—which would be deprecated. (The modern email >>API raises a ValueError for CR/NL in headers.) >> >>Do we want to issue a deprecation w

Re: Proposal to upgrade django.core.mail to Python's modern email API

;>*BadAddressHeader:* is a ValueError subclass raised only by >>forbid_multi_line_headers()—which would be deprecated. (The modern email >>API raises a ValueError for CR/NL in headers.) >> >>Do we want to issue a deprecation warning for this? The warning

Re: Proposal to upgrade django.core.mail to Python's modern email API

to just write BadAddressHeader = ValueError in >the deprecated code. (forbid_multi_line_headers() will warn about >deprecation when it's called.) > >Same question about all the deprecated constants (like >RFC5322_EMAIL_LINE_LENGTH_LIMIT). >- > >*sanitize_address():*

Re: Proposal to upgrade django.core.mail to Python's modern email API

in Django: - forbid_multi_line_headers() (which would be deprecated) - Django's *SMTP EmailBackend* to process the "envelope" from and recipient addresses (which may not be the same as the *From*, *To*, etc. message headers—e.g., bcc is only in envelope recipients

Re: Proposal to upgrade django.core.mail to Python's modern email API

> After my comment in the steering council vote and in-person conversation with Jake, I believe the SMTP backend will not be implemented for DEP 14 Then I can improve my earlier response: I *am confident* this proposal will have *no impact* on background workers. :-) - Mike On Tuesday, June 25

Re: Proposal to upgrade django.core.mail to Python's modern email API

quot; (you're not wrong!), there are convenience APIs that simplify constructing and sending it. Some come with Django: send_mail(), send_mass_mail(), mail_admins(). Some come from third party libraries: django-pony-express, django-templated-mail, etc. *Many* get built (and repea

Re: Proposal to upgrade django.core.mail to Python's modern email API

The idea is to create emails like you create views. All important stuff is encapsulated but you can overwrite everything you need. There are a bunch of examples in the docs. Apart from not having to deal with low-level email API stuff (which is a pain IMHO), it provides lots of neat improvement

Re: Proposal to upgrade django.core.mail to Python's modern email API

After my comment in the steering council vote and in-person conversation with Jake, I believe the SMTP backend will not be implemented for DEP 14 : https://forum.djangoproject.com/t/steering-council-vote-on-background-tasks-dep-14/31131/20 On Tue, 25 Jun 2024, at 10:27, Arthur Pemberton wrote: >

Re: Proposal to upgrade django.core.mail to Python's modern email API

> The background workers proposal will implement a new background SMTP EmailBackend (in django.core.mail.backends). I had missed that fact. Thanks for the explanation. I for one think that this is a good proposal -- this would modern transactional email sending. - Arthur On Mon, Jun 24, 2024

Re: Proposal to upgrade django.core.mail to Python's modern email API

> Would this be designed to be compatible with "Proposal 14: Background Workers"? I wouldn't expect this to impact background workers one way or the other. The same goes for the async email proposal(s) floating around. Virtually all of this work would occur in django.core.mail.message, where P

Re: Proposal to upgrade django.core.mail to Python's modern email API

Would this be designed to be compatible with "Proposal 14: Background Workers"? On Sun, Jun 23, 2024 at 10:46 PM Mike Edmunds wrote: > I want to propose updating django.core.mail to replace use of Python's > legacy email.message.Message (and other legacy email APIs) with > email.message.EmailM

Re: Proposal to upgrade django.core.mail to Python's modern email API

+1, I like to help in this On Mon, 24 Jun 2024, 05:46 Mike Edmunds, wrote: > I want to propose updating django.core.mail to replace use of Python's > legacy email.message.Message (and other legacy email APIs) with > email.message.EmailMessage (and other modern APIs). > > If there's interest, I c

Re: Proposal on how add configuration options to Email Backends

There is a ticket for this feature request now: https://code.djangoproject.com/ticket/35514#ticket -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails fr

Re: Django 5.1 alpha 1 released

Thank you On Wed, May 22, 2024, 10:26 PM Natalia Bidart wrote: > Details are available on the Django project weblog: > > > https://www.djangoproject.com/weblog/2024/may/22/django-51-alpha-1-released/ > > -- > You received this message because you are subscribed to the Google Groups > "Django dev

Re: Use of TIME_INPUT_FORMATS in TimeField

Thank you 🙏🏿 On Sun, May 19, 2024, 1:44 AM Arthur Pemberton wrote: > I haven't yet checked the tests thoroughly enough to determine why things > didn't work for me in practice. I do know they didn't work. And I do see > that the tests pass. But I suspect that the tests may not be fully > mimicki

Re: Use of TIME_INPUT_FORMATS in TimeField

I haven't yet checked the tests thoroughly enough to determine why things didn't work for me in practice. I do know they didn't work. And I do see that the tests pass. But I suspect that the tests may not be fully mimicking the read-world use case in this scenario. I'll return here once I have som

Re: Ticket #34646 Ordering a Django admin column based on multiple model fields

ril 26, 2024 at 7:10:36 PM UTC+2 Mubarak Alrashidi wrote: Could you re-consider it please? it is really important, and we need it. I have started another project where I need to create a computed column (used_invitations / max_invitations) Best regards On Friday, June 23, 2023 at 10:39:51 AM UTC

Re: Ticket #34646 Ordering a Django admin column based on multiple model fields

Could you re-consider it please? it is really important, and we need it. I have started another project where I need to create a computed column (used_invitations / max_invitations) Best regards On Friday, June 23, 2023 at 10:39:51 AM UTC+3 Mubarak Alrashidi wrote: > I really hope

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

Hi! I would be happy to make a contribution if a decision can be reached. I'm in favor of making the Group model swappable with the AUTH_GROUP_MODEL setting, similar to the User model. The ticket was marked as Someday/Maybe, I'm not sure why. The customization of the Group model is necessary in

Re: Should Django use Ada?

Thanks for the replies everybody. A few thoughts >From Adrián: > You should probably be addressing urllib devs with this inquiry (e.g. such vuln is then probably in many other web frameworks) I did that in 2021 when I found the issue with newlines in URLs. Python devs had the resources to

Re: Should Django use Ada?

I agree with Jörg. We need evidence of problems before we decide to act, and that those problems aren’t being addressed in Python. Forcing a new dependency on all users is not something we’d do lightly. On the contradictory standards, see the cURL maintainer’s post: https://daniel.haxx.se/blog/

Re: Should Django use Ada?

You should probably be addressing urllib devs with this inquiry (e.g. such vuln is then probably in many other web frameworks). Anyhow, just out of curiosity, wouldn't it be possible to use functools.partial function to replace urllib.parse.urlparse with ada-python in settings.py? Or make some kind

Re: Should Django use Ada?

You write: "It could still be a vulnerability ... / It could fail to parse ... / could decide it's invalid - This is all pretty bad..." I agree - this indeed would be really bad, if it can be used in malicious ways. But note that the fact that django or an upstream lib decided to slightly de

Re: Should Django use Ada?

I always wonder why people feel the need to belittle others' work with statements like " But Python, being maintained mostly by volunteers, did the minimum needed work to fix the vulnerability without really fixing the urlparse library properly." But then add something about their time being too va

Re: Fellow Reports - March 2024

March 25-26 *Triaged:* https://code.djangoproject.com/ticket/35330 - The update of related objects fails in the admin when the related model is camel case. (accepted) https://code.djangoproject.com/ticket/35331 - Adding a new related entry using the "+" sign from M2M field doesn't update

Re: Intermittent IntegrityError on Model Save with auto_now and auto_now_add Fields

Looks like this issue isn't affecting lots of folks, since nobody is piping up, so I'll just add that if anybody arrives here in the future, we'll be tracking this in a public issue here: https://github.com/freelawproject/courtlistener/issues/3359 My theory is it has something to do with race

Re: Fellow Reports - March 2024

Week ending March 24 *Triaged:* https://code.djangoproject.com/ticket/35312 - FileNotFoundError escapes from run_formatters() (invalid) https://code.djangoproject.com/ticket/34059 - Validation of check constraints on JSONField key transforms with None produces invalid SQL on PostgreSQL.

Re: Fellow Reports - March 2024

Week ending March 17 *Triaged:* https://code.djangoproject.com/ticket/35287 - manage createsuperuser too restrictive (duplicate) https://code.djangoproject.com/ticket/35291 - Whitenoise Not Working when DEBUG = FALSE - Django - Hosting Static Files (duplicate) https://code.djangoproj

RE: Intermittent IntegrityError on Model Save with auto_now and auto_now_add Fields

Hi Bill, We ended up using a package called Django-audit-log: https://pypi.org/project/django-audit-log/. It’s outdated now, but we used the source code for their CreatingUserField, LastUserField, CreationDateTimeField, and ModificationDateTimeField. More modern packages may have enhanced featur

Re: Use of TIME_INPUT_FORMATS in TimeField

USE_I18N does not disable localization, but internationalization. USE_L10N was the setting to enable/disable localization, but it was deprecated in Django 4.0: https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was removed completely in Django 5.0, in this commit: https://git

Re: Use of TIME_INPUT_FORMATS in TimeField

Thanks, I'll look into that. But does that mean that settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic flows that lead to it being used. On Tue, Mar 5, 2024 at 3:00 AM David Sanders wrote: > Define TIME_INPUT_FORMATS in your local formats.py setup as per: > https://docs.dj

Re: Use of TIME_INPUT_FORMATS in TimeField

Define TIME_INPUT_FORMATS in your local formats.py setup as per: https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton wrote: > The documentation ( > https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefie

Re: Fellow Reports - February 2024

Week ending March 3 *Triaged:* https://code.djangoproject.com/ticket/35245 - Django freezes on DRF's APIView. (invalid) https://code.djangoproject.com/ticket/35253 - Pagination for StackedInline and TabularInline (duplicate) https://code.djangoproject.com/ticket/35251 - dumpdata refa

Re: Fellow Reports - February 2024

Week ending February 25 *Triaged:* https://code.djangoproject.com/ticket/35232 - Cache Options.verbose_name_raw (accepted) https://code.djangoproject.com/ticket/35234 - ExclusionConstraint.expressions should be checked for foreign relationship references (accepted) https://code.djan

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

I've found the reason why I've been thinking this wrong way. `getattr(self.get_queryset(), name)` is getting a bound method from Manager.get_queryset() which is a QuerySet class instance, while method is getting function from _queryset_class. The difference is one of them is bound method, whil

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

Thanks for your answer. I will continue to investigate based on your suggestions and if I find the answer I will respond again. 在2024年2月28日星期三 UTC+8 10:13:09 写道： > Hi Ryoma, a good way to investigate this would be to make the change and > see if anything breaks. > > If I understand correctly,

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

Hi Ryoma, a good way to investigate this would be to make the change and see if anything breaks. If I understand correctly, your suggest is: -return getattr(self.get_queryset(), name)(*args, **kwargs) +return method(*args, **kwargs) In that case, running the tes

Re: Deprecate CICharField, CIEmailField, CITextField

True, not the end of the world. Just ... another dependency. The NPM world has traumatized me. Many thanks for creating that. If there's nothing that can be done, it's time to move on. But worth asking. (Interestingly, even with the deprecation, historical migration fields still need to be su

Re: Deprecate CICharField, CIEmailField, CITextField

I just say it: The decision certainly had good intentions, but maybe wasn't fully informed. It happens. But since we don't really have a processed to revert a deprecation, I would recommend using the django-citext package. It's a drop-in replacement with the same license as Django and a corporate

Re: Deprecate CICharField, CIEmailField, CITextField

Coming in again now that I've looked at upgrading. @Adam: your post was useful. But can you actually say you prefer the new approach? But I'm going to be honest, this is a lot of hoops and gotchas. What did we actually gain by deprecating this? I'm seeing maybe 15-20 lines of code that will be

Re: Fellow Reports - February 2024

Week ending February 18 *Triaged:* https://code.djangoproject.com/ticket/35181 - behaviour of makemessage dont follow documentation (needsinfo) https://code.djangoproject.com/ticket/35185 - Daphne: websocket works locally with ws protocol, but it connects and quickly disconnects in prod

Re: Proposal for SyncChatRoom Integration in Django

That sounds great, I will keep you updated for any technologies to use or have you have any technical issues also keep me updated On Sun, Feb 18, 2024, 03:08 David Ansa wrote: > Hi Fawemimo Owolabi, > > Thank you for your support and feedback! I appreciate your suggestion to > use SyncChatRoom a

Re: Proposal for SyncChatRoom Integration in Django

Hi Fawemimo Owolabi, Thank you for your support and feedback! I appreciate your suggestion to use SyncChatRoom as a third-party package, and I'm considering extending it to integrate with Django REST Framework as well. I'll keep the community updated on the progress, and feel free to share any

Re: New feature request - Run only a random subset of tests.

agreed about this is a unittest/pytest specific focus, not django. This is pretty straightforward to do with pytest, can have a custom flag and then randomize the test collection. With unittest, not sure. On Monday, February 12, 2024 at 11:36:57 AM UTC-5 Jörg Breitbart wrote: > I also think th

Re: Proposal for SyncChatRoom Integration in Django

I really support these motions, it really sound great but it will be best to used as a third-party package, also for drf as well On Tuesday, February 13, 2024 at 11:21:02 PM UTC+1 Adam Johnson wrote: > Hi David > > SyncChatRoom sounds more like something that Django would help users > build, ra

Re: Proposal for SyncChatRoom Integration in Django

Hi David SyncChatRoom sounds more like something that Django would help users build, rather than include in the framework. If it’s somewhat reusable between projects, it would be best be published as a third-party package. Thanks, Adam On Tue, Feb 13, 2024, at 8:57 PM, David Ansa wrote: > Hi

Re: Testing Unmanaged Models - Using the SchemaEditor to create db tables

Hi Adam, Thanks for your response! I understand your point about unmanaged models being a niche use case of Django. I've decided to proceed with creating a package and see how it goes. The new enterContext() and other methods in unittest seem interesting. I'll definitely be using them more fro

Re: New feature request - Run only a random subset of tests.

I also think that your requirements are too specific to be added to django. You are prolly better suited by creating your own test picking abstraction for this, e.g. by writing custom test suite aggregates or using unittest.TestLoader.discover and going into tests of interest by your own logic

  1   2   3   4   5   6   7   8   9   10   >