Re: Fellow Reports -- July 2020

[Carlton Gibson]

Hi all. 


Calendar Week 31 -- ending 02 August.


Triaged:

https://code.djangoproject.com/ticket/31840 -- Adding Support for 
Cross-Origin Opener Policy (Accepted)
https://code.djangoproject.com/ticket/31827 -- Add test runner option to 
show N slowest tests (Accepted)
https://code.djangoproject.com/ticket/31835 -- JSONField's __contains 
lookup doesn't work in nested values on Oracle. (Accepted)



Reviewed:

https://github.com/django/django/pull/13262 -- Fixed #31842 -- Added 
DEFAULT_HASHING_ALGORITHM setting.
https://code.djangoproject.com/ticket/31842 -- django.core.signing.dumps() 
and loads() not backwards compatible
https://github.com/django/django/pull/13261 -- Refs #27996 -- Fixed 
postgres_tests crash if not running with PostgreSQL.
https://github.com/django/django/pull/13173 -- Fixed #25513 -- Extracted 
admin pagination to EllipsisPaginator.
https://github.com/django/django/pull/12387 -- Fixed #31216 -- Added 
support for colorama terminal colors on Windows.
https://github.com/django/django/pull/13247 -- Fixed #29336 -- Doc'd 
circular template inheritance
https://github.com/django/django/pull/13254 -- Corrected function signature 
in admin docs.
https://github.com/django/django/pull/13220 -- Fixed #28507 -- Made 
ValidationError.__eq__() ignore messages and params ordering.
https://github.com/django/django/pull/11937 -- Fixed #27395 -- Updated 
sitemap to generate 'alternates'
https://github.com/django/django/pull/13240 -- Fixed #29324 -- Validate 
SECRET_KEY lazily (on access).
https://github.com/django/django/pull/13239 -- Don't run 
`add_script_prefix` on every access to static/media urls in settings.
https://github.com/django/django/pull/13250 -- Fixed #31836 -- Dropped 
support for JSONField __contains and __contained_by lookup on SQLite.
https://github.com/django/django/pull/13248 -- Fixed #31835 -- Dropped 
support for JSONField __contains lookup on Oracle.
https://github.com/django/django/pull/13224 -- Fixed #31811 -- Add optional 
timing outputs to the test runner



Authored:

https://github.com/django/djangoproject.com/pull/1011 -- Added banner for 
2020 survey.



Kind Regards,

Carlton

-- 
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 from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4c328591-5410-4fa7-9181-2c4c464901beo%40googlegroups.com.

#31617 new New feature Improve overall admin accessibility.

[Abishek Rajagopal]

Hello Team,

   I'm ready to work on this issue. Im a Full Stack dev by 
profession. I need to know what are necessary thing that i need to change 
and how do get the original code of that page. 

-- 
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 from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c05163c4-6f43-4abc-ae98-8a6fd457382fo%40googlegroups.com.

Re: I need a mentor on django

[SUNIL PATEL]

Hi
how are you doing at django.
sunil patel

On Wed, Jun 10, 2020 at 9:27 PM Onayemi Hakeem 
wrote:

> I need a mentor who can guide me on my Django programming skill to develop
> my dream app
>
> --
> 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 from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8b4b8a83-aee6-4c84-acf5-3f0cdf3c03d2o%40googlegroups.com
> .
>

-- 
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 from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADarRE46vWdCiAfMUhXNHNXctTiDgsPNAMhGBeZZ1a0vzZu9yA%40mail.gmail.com.

Set up autolinks on Django's GitHub repositories

[laym...@gmail.com]

Hi folks,

I came across this feature on GitHub today:
https://docs.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources

In short, it adds autolinks to external resources (e.g. our issue tracker) 
by referencing them using a prefix in GitHub comments or commits. So, 
instead of using Markdown to manually link to a ticket, we can just use the 
prefix followed by the ticket number, e.g. *TR-123* and GitHub will 
automatically convert it to a link.

Currently, we use the # character as a convention to refer to the tickets. 
However, this conflicts with the use of # on GitHub which automatically 
links to PRs (and issues if enabled). As a result, commits that refer to a 
ticket whose number is also a valid PR number, incorrectly link to the PR. 
Here's an example: 
https://github.com/django/django/commit/5d4b9c1cab03f0d057f0c7751862df0302c65cf9

As you can see, the commit message links to PR#12990 which actually isn't 
relevant. This also generates noise in the PR 
itself: https://github.com/django/django/pull/12990. I think that can be 
misleading to new contributors.

By using the autolinks, we can properly link the reference to the tickets. 
Sadly, we can't replace GitHub's # autolinks. So, we need to create a new 
prefix. This has some downsides, though:

   - It breaks the current convention of using # to refer to tickets.
   - The prefix must only contain letters, numbers, or -:/#
   - The prefix is 3 characters minimum, so this means commit messages will 
   be at least 2 characters longer than with the current convention.
   
However, considering the benefits:

   - No more incorrect links to irrelevant PRs.
   - No more noise in PRs from irrelevant commits.
   - Clickable ticket numbers in commits that take you to the tickets.
   - Quick linking to tickets in GitHub comments (no need to use Markdown).
   - Less confusion to new contributors.

I think it's worth it.

What do y'all think? If we're to agree upon this, I guess we need to come 
up with the prefix. I don't have any preference; as long as it makes sense, 
I'm in.

Oh, and one more thing: maybe we can also set up a prefix for PRs to easily 
differentiate between the two from now on. Here are some proposals:

   - *TR-1234* for TRac tickets, and *PR-5678* for PRs.
   - *TR#1234* for TRac tickets, and *PR#5678* for PRs.

And maybe we can set up another for DEPs, but that may not be necessary...

Regards,
Sage

-- 
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 from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e070dd97-0d22-4566-a605-867141f7e0aan%40googlegroups.com.

Re: Status of 3.1 release blockers.

[Mariusz Felisiak]

It seems that adding DEFAULT_HASHING_ALGORITHM setting is an acceptable 
solution, we have one remaining question: Do we keep the setting around?

   1. we can treat DEFAULT_HASHING_ALGORITHM as a transitional setting, 
   limit its values to `sha1` and `sha256`, and deprecate it immediately. 
   Florian said: *"From a security perspective I wonder if we should limit 
   this that the existing sha1 and the new sha256 algos. We really don't ever 
   want anyone to put md5 there and it is really just a transitional 
   setting.", "...setting this to sha256, running with it and then changing it 
   to sha512 will be a hard cut. There will be no migration path like there 
   would be for sha1. Imo that limits the usefulness of such a setting for 
   long term usage and makes it questionable if we want to support such 
   usage."*
   2. we can treat DEFAULT_HASHING_ALGORITHM as a new feature and allows 
   any secure hash algorithm supported by hashlib. Simon said: *"**It does 
   add one more setting but it feels like having this configurable project 
   wide will be a plus as it will allow the ecosystem to rely on it and 
   hopefully make audit of large Django application a bit easier when having 
   specific hashing requirements.".*

Personally I think we should choose the first option because it's safer. 

*We're delaying the 3.1 release until tomorrow.*

Best,
Mariusz

-- 
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 from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/023a0518-a58c-48c6-8b36-9d5fb7a7c108n%40googlegroups.com.

Re: Username Validators 27807

[Shekhar Gyanwali]

I have submitted a PR with what I had before the discussion. Will work on
it based on feedback.

Please see PR here. 

On Thu, Jul 30, 2020 at 11:35 PM Shekhar Gyanwali <
saykharng.gyanw...@gmail.com> wrote:

> Hi Everyone!
>
> I am currently working on my first Django ticket 27807
> , which is to allow users to
> customize username validation. My experience with Django and development is
> very limited (junior developer level). I need some guidance on this.
>
> I am taking similar approach as password validation
> 
>  (Thanks
> to Jacob ) . In the current solution, I am following Django core validators
> pattern which is to have __call__ method for validator. However, I have
> noticed that password validator needs to have it's own validate method.
>
> Is it best to implement username validators similar to password validators
> for the consistency and better user experience?
>
> What is the best approach here and what are the benefits of the best
> approach?
>
> Your feedback is much appreciated.
>
> Cheers
> Shekhar
>
> --
> 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 from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6102cf17-b9be-4987-863f-1939feed93f8o%40googlegroups.com
> 
> .
>

-- 
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 from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHAmSnptjSUERW5F%2BNEwZSxV_GTrLrJ02Qn%3DsXCRL1eY9c_vFg%40mail.gmail.com.