Fellow Reports -- May 2020

[Carlton Gibson]

Hi all.


Calendar Week 19 -- ending 10 May.


Triaged:

https://code.djangoproject.com/ticket/31547 -- A bug in Django3.0.6 about 
the function of "include" (invalid)
https://code.djangoproject.com/ticket/31540 -- i18n URLs are not matched 
against the fallback language. (Accepted)
https://code.djangoproject.com/ticket/31536 -- Disabled clearable file 
field widget is not disabling the checkbox (Accepted)



Reviewed:

https://github.com/django/django/pull/12870 -- Enabled GitHub security 
policy.
https://github.com/django/django/pull/12835 -- Completed test coverage for 
ExclusionConstraint.
https://github.com/django/django/pull/12863 -- Added release notes URL to 
packaging metadata.
https://github.com/django/django/pull/12861 -- Fixed #31495 - Corrected 
note about admin i18n in tutorial.
https://github.com/django/django/pull/12159 -- Fixed #31034 -- Added a 
navigation sidebar to the admin
https://github.com/django/django/pull/12836 -- Updated admin's Select2 
to 4.0.13.
https://github.com/django/django/pull/12758 -- Fixed #31485 -- Updated 
admin's jQuery to 3.5.1.
https://code.djangoproject.com/ticket/31538 -- models.E015 is raised when 
ordering uses lookups that are not transforms.



Authored:

https://github.com/django/django/pull/12860 -- Fixed #31515 -- Made 
ASGIHandler dispatch lifecycle signals with thread sensitive.





Calendar Week 20 -- ending 17 May.


Triaged:

https://code.djangoproject.com/ticket/32588 -- Unclear behaviour for 
ModelForms (invalid)
https://code.djangoproject.com/ticket/31582 -- Django template backend 
allocates model cache even iterator() is used (Accepted)
https://code.djangoproject.com/ticket/27686 -- calls to 
request.user.is_authenticated returns vary by cookie header for all users 
(invalid)
https://code.djangoproject.com/ticket/31584 -- Queryset crashes when 
grouping by Exists() on Oracle. (Accepted)
https://code.djangoproject.com/ticket/31570 -- Translations of one language 
in different territories can override each other. (Accepted)
https://code.djangoproject.com/ticket/31577 -- The explanation ended in the 
middle. (Accepted)
https://code.djangoproject.com/ticket/31576 -- Navigation sidebar hides 
some elements on small windows. (Accepted)
https://code.djangoproject.com/ticket/31546 -- Replace 
Command.requires_system_checks = True by something like 
Command.required_system_checks = '__all__' (Accepted)
https://code.djangoproject.com/ticket/31553 -- Incorrect query for inline 
admin when the parent is a proxy model (needsinfo)
https://code.djangoproject.com/ticket/31575 -- Document admin's 
requirement on django.template.context_processors.request context 
processor. (Accepted)



Reviewed:

https://github.com/django/django/pull/12845 -- Removed unnecessary admin 
CSS.
https://github.com/django/django/pull/12821 -- Fixed #31524 -- Removed 
minified static assets from the admin.
https://github.com/django/django/pull/12819 -- Added Selenium test coverage 
for actions.js.
https://code.djangoproject.com/ticket/31584 -- Queryset crashes when 
grouping by Exists() on Oracle.
https://github.com/django/django/pull/12882 -- Fixed #9107 -- Allowed URL 
parameters to set values of fields in admin inlines.
https://github.com/django/django/pull/12876 -- Completed lorem tag test 
coverage.
https://github.com/django/django/pull/995 -- Updated docs-related model 
fixtures for 3.0 release.
https://github.com/django/django/pull/12907 -- Fixed #31576 -- Fixed 
selenium tests with headless mode.
https://code.djangoproject.com/ticket/31358 -- Increase default password 
salt size in BasePasswordHasher.
https://github.com/django/django/pull/12906 -- Fixed #31575, Refs #31034 -- 
Documented admin requires django.template.context_processors.request.
https://github.com/django/django/pull/12904 -- Add JSONField.from_db_value 
method only if necessary.
https://github.com/django/django/pull/12854 -- Bootstrapped Django 3.2.
https://code.djangoproject.com/ticket/31570 -- Translations of one language 
in different territories can override each other
https://github.com/django/django/pull/12899 -- Final changes before 
branching stable/3.1.x.
https://github.com/django/django/pull/12159 -- Fixed #31034 -- Added a 
navigation sidebar to the admin







Calendar Week 21 -- ending 24 May.


Triaged:

https://code.djangoproject.com/ticket/31582 -- Django template engine 
render pre-fetches data even when iterator() is used (wontifx)
https://code.djangoproject.com/ticket/31596 -- ForeignKey.validate() should 
validate using the base manager. (Accepted)
https://code.djangoproject.com/ticket/31591 -- Spanning relationship 
backwards when related_name is used. (Accepted)
https://code.djangoproject.com/ticket/31604 -- Should 
SafeExceptionReporterFilter cleanse setting keys whose name matches 
"URL" in part, too? (wontfix)



Reviewed:

https://github.com/django/django/pull/12949 -- Doc'd release step for 
new classifiers on PyPI.
https://github.com/django/django/pull/12947 -- Fixed #31608 -- D

Re: GSoD - Google Season of Docs

[Carlton Gibson]

Hi Aksh. 

Thanks for your interest. It'll be good to hear your ideas. 

There's some discussion over on the forum. 
https://forum.djangoproject.com/c/internals/mentorship/10

Then the other thing worth checking out is the Season of Docs Technical 
Writers Guide: 
https://developers.google.com/season-of-docs/docs/tech-writer-guide

Kind Regards,

Carlton



On Tuesday, 19 May 2020 03:38:10 UTC+2, Aksh Gupta wrote:
>
> Hi,
>
> I'd love to improve the 'Contributing Guide' as a part of GSoD this year. 
> I have gone through the Guide myself to start contributing to the project, 
> and I agree that it is indeed overwhelming to follow.
>
> Getting new contributors is a crucial part of any big project. I would 
> love to give my best to make it a better read and easier to follow for 
> potential future contributors (including me).
>
> Looking forward to a wonderful interaction with the community!
>
> Kind Regards,
>
> Aksh
>

-- 
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/c2a0d468-c18b-433e-8c5d-82d874f6682a%40googlegroups.com.

Custom collation support

[Tom Carrick]

I think it would be useful to be able to create collations and use them
with model fields. The motivation here is mostly that citext is somewhat
discouraged  in favour of
creating a collation. I'm not sure how this would work on other
databases,or what the API would look like. I didn't see a ticket for it or
another discussion, but maybe there is one.

Perhaps a Collation class would make sense, and it could be added to a
Field with a new parameter. I'm not sure how easy it would be to only
create a collation once, so perhaps it would need a CreateCollation
migration as well, but I know very little about the internals of migrations.

Cheers,
Tom

-- 
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/CAHoz%3DMYpkS5-rPAUQ3sVg-Yahb%3D6B%2BT4ndP5PGOJrBE3iEgzPQ%40mail.gmail.com.

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

[Scott Cranfill]

The PR was merged! Thanks everyone for your input and assistance.

On Wednesday, May 20, 2020 at 12:51:56 PM UTC-4, Scott Cranfill wrote:
>
> Thanks for the additional feedback, folks!
>
> We have opened a fresh PR, rebased on the latest master and referencing 
> #11157, at https://github.com/django/django/pull/12945
>
> Best,
> Scott
>
>
> On Saturday, May 16, 2020 at 5:25:29 AM UTC-4, Adam Johnson wrote:
>>
>> There's a bit more support now, and there have been no opinions against 
>> it.
>>
>> Because of this I've reopened the older closed ticket #11157: 
>> https://code.djangoproject.com/ticket/11157 . Andy/Scott, I hope you can 
>> retarget your PR as per my comment there. Thanks!
>>
>> Admin users still get a preview of the slug and can edit it if needed.
>>>
>>
>> Agree, no need for deprecation warnings. This behaviour is in front of 
>> users with an easy override.
>>
>> ‪On Sat, 16 May 2020 at 03:04, ‫אורי‬‎  wrote:‬
>>
>>> I very much prefer a slug "to-be-or-not-to-be-that-is-the-question" 
>>> than "be-or-not-be-question" (which doesn't make sense).
>>> אורי
>>> u...@speedy.net
>>>
>>>
>>> On Wed, Apr 8, 2020 at 11:35 PM Andy Chosak  wrote:
>>>
 Automatic slug generation in ModelAdmin via prepopulated_fields 
 
  
 uses a urlify.js 
 
  
 file which, among other behaviors, removes certain stop words 
 
  
 from the slug. For example, a string like "To be or not to be, that is the 
 question" will generate a slug "be-or-not-be-question", not 
 "to-be-or-not-to-be-that-is-the-question" as one might expect. I’d like to 
 solicit feedback on the idea of removing this logic so that slugs can 
 contain these words.

 For reference, the current list is: a, an, as, at, before, but, by, 
 for, from, is, in, into, like, of, off, on, onto, per, since, than, the, 
 this, that, to, up, via, with.

 Django ticket #30538  
 mentions this behavior as part of a more general comparison between 
 urlify.js and Python slugify 
 .
  
 It was closed as wontfix due to reasons of backwards compatibility. Per 
 the triaging 
 guidelines 
 ,
  
 I’m making this post to solicit feedback on the more specific question of 
 addressing stopword removal in the JS code only -- not to try to address 
 any other differences in behavior between these two methods. There’s been 
 quite a bit of discussion on generating slugs for non-English languages 
 (for example #2282 ), and 
 this post is not intended to reopen that discussion.

 The current list of stopwords being removed seems to have been the same 
 since 
 at least 2005 
 
  
 (the earliest code I can find including this logic). Some of these words 
 feel a little unexpected, for example “before” and “since”. After 15 years 
 it seems reasonable to revisit the list and consider whether it still 
 makes 
 sense.

 Was removal of these words introduced for SEO reasons? If so, is this 
 still a recommended default behavior? In 2020, search engines like Google 
 seem smart enough to interpret them properly. Here's 
  an arbitrary page that 
 discusses this and includes a much longer list of what might be considered 
 stopwords. As another datapoint, the popular WordPress Yoast SEO plugin 
 used to remove stopwords, but stopped doing so 
  a few years back.

 Potentially outdated SEO concerns aside, does this behavior still align 
 well with the needs and desires of Django users? Is this something this 
 community would be open to revisiting? Thanks for your consideration.

 (One minor point on language support: allowing these words would help 
 to resolve at least some of the unequal treatment given to English over 
 other languages, for example #12905 
 . See also wagtail#4899 
 , from which much of 
 this post has been copied, for an example of how this logic impacts a 
 Django-based CMS.)

to send data from our site to various sites

[Shubham Bindal]

in this suppose we upload picture in our site its gets uploaded to other 
site like facebook t all accounts whose credentials we have saved i our site
 

-- 
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/d5d15c40-24eb-45e9-a385-8d86d5a27fd5%40googlegroups.com.

Re: to send data from our site to various sites

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Wed, 27 May 2020 at 11:37, Shubham Bindal  wrote:

> in this suppose we upload picture in our site its gets uploaded to other
> site like facebook t all accounts whose credentials we have saved i our site
>
>
> --
> 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/d5d15c40-24eb-45e9-a385-8d86d5a27fd5%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM3QddFsHudcYp9uKqB2NopYBg-OmnihM%3D-D0bKd7xaL-g%40mail.gmail.com.