Fellow Reports -- March 2021

Hi all. Calendar Week 9 -- ending 07 March. Triaged: https://code.djangoproject.com/ticket/32504 -- Update admin's jQuery to 3.6.X. (Accepted) https://code.djangoproject.com/ticket/32412 -- User.has_perm should forward **kwargs to allow more flexibility in authentication backends (wontfix)

Django 3.2rc1: models.W042 is raised on inherited manually specified primary key.

This issue was raised in alpha1, but I still had the issue in beta1 and now also in rc1. As a result, I have to manually edit the migrations files and remove lines that alter fields to become BigField(). Has this really been fixed? Am I missing something obvious? Caram -- You received this

Re: Django 3.2rc1: models.W042 is raised on inherited manually specified primary key.

Hi, It would be helpful to link to the ticket and/or explain the issue in more detail. On Thursday, March 25, 2021 at 9:28:09 AM UTC-4 Caram wrote: > > This issue was raised in alpha1, but I still had the issue in beta1 and > now also in rc1. > > As a result, I have to manually edit the migrati

Addressing django and graphql ecosystem

Hello everyone, hope you are all doing well! Despite there being a few tools to integrate GraphQL with Django, the community stance towards their union is "it could be much better". This is expected, since though these tools exist, they are not made with the best developer experience in mind. T

Re: Django 3.2rc1: models.W042 is raised on inherited manually specified primary key.

Sorry, I meant to do that. Here's the link to the ticket: https://code.djangoproject.com/ticket/32367 I get an output similar to that of the ticket when I run `./manage makemigrations`: HINT: Configure the DEFAULT_AUTO_FIELD setting or the AppConfig.default_auto_field attribute to p

Re: Django 3.2rc1: models.W042 is raised on inherited manually specified primary key.

Caram, I don't see any issue here. As far as I'm aware you're using the auto-created primary key. If you want to get rid of warnings and avoid unwanted migrations in the future, set DEFAULT_AUTO_FIELD to AutoF

Re: Rethink (?) how we handle security headers.

I just came across this thread after seeing a related PR. Rather than a "get_security_header()" function, couldn't Django make the setting an object that is accessed by the user like a dict, but internally (underneath the hood) it tries from a user-defined dict and then falls back to a value in