Internship espically for students feel free to apply on python resources

[yashwanth balanagu]

https://forms.gle/aHQ9jUbNtp2FsN597

-- 
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/98895731-747d-40b0-a8f5-fc3da8105d4an%40googlegroups.com.

Re: Accessibility standards & contribution guidelines for Django

[sapt...@gmail.com]

On Thursday, 17 June 2021 at 14:01:15 UTC+5:30 Thibaud Colas wrote:

> Thank you all for the feedback :) I have a feeling it might indeed be 
> easier for me to propose this for review in the form of a pull request to 
> the Django docs, as I have quite a clear idea of what I’d propose at a high 
> level.
>
> On testing tools, yes, both Pa11y and Lighthouse would be worth 
> considering. They both use Axe to do the actual checks, which means results 
> will be largely comparable between Lighthouse, Pa11y, and Accessibility 
> Insights. I’ve set up automated tests for the Django admin based on Pa11y + 
> Lighthouse, which you can see here: django_admin_tests 
> . My preference as 
> "the one tool" to recommend still is Accessibility Insights, as it contains 
> a good mixture of automated and semi-automated checks, as well as a very 
> thorough wizard to guide people through manual checks.
>
I love the Django admin accessibility tests and repo that you made. The 
demo report looks pretty decent to me! I think that would be super useful 
when issues are created and for fixing the issues. There's also this web 
app https://beinclusive.app/ which allows you to manage accessibility 
audits better which might be helpful in some form when we have a concrete 
accessibility audit.

Might I also add that once we have a decent accessibility improvement, we 
add something like accessLint  in the CI to assure 
that future PRs don't have any glaring accessibility issues?

>
> > I wanted to check the issue on password UX but maybe I can help on 
> others things related to this before. Tell me what do you think.
>
> There’s quite a lot of ground to cover, so any and all help is welcome :) 
> If you’re interested in UX work generally – once we start properly auditing 
> the Django admin, reporting issues will be straightforward enough, but 
> proposing solutions will be much harder. Anyone with a good mix of Django 
> and UX expertise will be in a great position to contribute. For example, 
> last week I audited django-postgres-metrics 
>  and found a few issues 
> relating to table sorting. Fixing those issues could be an opportunity to 
> generally improve the table sorting UX for all.
>
> > I am not completely sure about the definition of an "authoring tool",
> but it might make sense to consider django as a whole as such an
> authoring tool, not just the Django admin. ATAG A. (Make the authoring
> tool user interface accessible) would then only apply to Django admin,
> but ATAG B. (Support the production of accessible content) would apply
> to everything.
>
> Indeed! There are a few things that likely couldn’t apply (Guideline 
> B.3.2: Assist authors in repairing accessibility problems 
> ) 
> but they feel like they might be the exception rather than the rule. It’s 
> certainly a helpful lens to consider accessibility improvements through.
>
> Best regards,
>
> Thibaud
>
> On Tuesday, 15 June 2021 at 18:19:41 UTC+1 Tobias Bengfort wrote:
>
>> Hi Thibaud, 
>>
>> thanks for the follow up. +1 on basically everything you wrote! 
>>
>> On 15/06/2021 02.59, Thibaud Colas wrote: 
>> > This distinction between "sites built with Django" and the "Django 
>> > admin" highlights an important point, which is that for lots of sites 
>> > the Django admin would be what accessibility standards call an 
>> authoring 
>> > tool. There is a separate standard for authoring tools that builds upon 
>> > WCAG 2.1: ATAG 2.0. I think we should also explicitly aim for 
>> compliance 
>> > with ATAG 2.0 wherever possible, as it has a lot of useful guidelines 
>> we 
>> > could follow for the Django admin. For Django itself, there might be 
>> > very little to do to implement those guidelines, but for the wider 
>> > ecosystem of CMS-like features in Django it would make a clear 
>> > difference if Django was clearly defined as an authoring tool. WCAG 
>> > itself is a very thin baseline as standards go, so anything that goes 
>> > beyond it is well worth considering in my opinion. 
>>
>> I am not completely sure about the definition of an "authoring tool", 
>> but it might make sense to consider django as a whole as such an 
>> authoring tool, not just the Django admin. ATAG A. (Make the authoring 
>> tool user interface accessible) would then only apply to Django admin, 
>> but ATAG B. (Support the production of accessible content) would apply 
>> to everything. 
>>
>> > * *Which automated or semi-automated testing tools to use when testing 
>> > changes to Django*. My go-to is anything Axe 
>> > -based, as it’s ubiquitous, and has very 
>> > few false positives. In particular with the Accessibility Insights 
>> >  browser extension. 
>>
>> AFAIK the accessibility checker in chrome's lightho

[bug?] Models on nested FilteredRelation are not joined

[Damiano Porta]

Hello,

i have just upgraded to Django 3.2 to use nested FilteredRelation, but i 
have noticed strange behaviors, this is the code:



/from django.db.models import FilteredRelation, Q//
//from django.db import models//
//
//
/

///class A(models.Model):/
///    foo = models.IntegerField()/
//
///class B(models.Model):/
///    value = models.IntegerField()/
//
///class C(models.Model):/
///    a = models.ForeignKey('A', on_delete=models.CASCADE)/
///    b = models.ForeignKey('B', on_delete=models.CASCADE)/

/
//>>> qs = A.objects.annotate(bla=FilteredRelation('c', 
condition=Q(c__b__value=1))).select_related('bla')//

//>>> str(qs.query)//
//'SELECT "base_a"."id", "base_a"."foo", bla."id", bla."a_id", 
bla."b_id" FROM "base_a" LEFT OUTER JOIN "base_c" bla ON ("base_a"."id" 
= bla."a_id" AND ("base_b"."value" = 1))'/



_*PROBLEM 1:*_

It is not joining the model B. As you can see on the query there is 
"base_b" without the join.



_*PROBLEM 2:*_

There is another strange behavior, if i "execute" the queryset i get this:

/>>> qs//
//Traceback (most recent call last)://
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/backends/utils.py", 
line 84, in _execute//

//    return self.cursor.execute(sql, params)//
//psycopg2.errors.UndefinedTable: ERRORE:  elemento FROM per la tabella 
"t4" mancante//
//LINE 1: ... "base_c" bla ON ("base_a"."id" = bla."a_id" AND 
(T4."value"...//

//^//
//
//The above exception was the direct cause of the following exception://
//
//Traceback (most recent call last)://
//  File "", line 1, in //
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/models/query.py", 
line 256, in __repr__//

//    data = list(self[:REPR_OUTPUT_SIZE + 1])//
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/models/query.py", 
line 262, in __len__//

//    self._fetch_all()//
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/models/query.py", 
line 1324, in _fetch_all//

//    self._result_cache = list(self._iterable_class(self))//
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/models/query.py", 
line 51, in __iter__//
//    results = compiler.execute_sql(chunked_fetch=self.chunked_fetch, 
chunk_size=self.chunk_size)//
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/models/sql/compiler.py", 
line 1169, in execute_sql//

//    cursor.execute(sql, params)//
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/backends/utils.py", 
line 98, in execute//

//    return super().execute(sql, params)//
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/backends/utils.py", 
line 66, in execute//
//    return self._execute_with_wrappers(sql, params, many=False, 
executor=self._execute)//
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/backends/utils.py", 
line 75, in _execute_with_wrappers//

//    return executor(sql, params, many, context)//
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/backends/utils.py", 
line 84, in _execute//

//    return self.cursor.execute(sql, params)//
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/utils.py", 
line 90, in __exit__//

//    raise dj_exc_value.with_traceback(traceback) from exc_value//
//  File 
"/home/damiano/.virtualenvs/myproj/lib/python3.8/site-packages/django/db/backends/utils.py", 
line 84, in _execute//

//    return self.cursor.execute(sql, params)//
//django.db.utils.ProgrammingError: ERRORE:  elemento FROM per la 
tabella "t4" mancante//
//LINE 1: ... "base_c" bla ON ("base_a"."id" = bla."a_id" AND 
(T4."value".../

 ^

there is no T4 on the previous qs.query, but i try again and the sql 
output is magically *_changed_*. (why?)


/>>> str(qs.query)//
//'SELECT "base_a"."id", "base_a"."foo", bla."id", bla."a_id", 
bla."b_id" FROM "base_a" LEFT OUTER JOIN "base_c" bla ON ("base_a"."id" 
= bla."a_id" AND (T4."value" = 1))'/



_*NOTE:*_

I also tested the code changing:

//.annotate(bla=FilteredRelation('c', condition=Q(c__b__value=1)))/
/

//with

/.annotate(bla=FilteredRelation('c__b', condition=Q(c__b__value=1)))/

In this case it works but it adds the B fields on the SELECT... i do not 
need them i just need to add that model on the condition without having 
its fields, _I just need fields of A and fields of __/C/_/

/

are they bugs?

D.

--
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/2b0eae17-aedd-c39e-f882-73535b0

Re: Update - MSSQL support for Django

[Warren Chu]

Hi All, 

We've released version 1.0rc1 of the Microsoft SQL Server 3rd Party Backend 
for Django, with support for Django 3.2 and JSONField.

We've re-added optional regex support so that the regex DLL file is 
included in the pypi package as opposed to the source code. This follows 
our organizational security best practices.

We've also cleared up the licensing issue and reverted to the prior BSD-3 
license.

We expect to release GA version 1.0 end of this month - where we'll prepare 
blog post content in advance and engage the community.

If you have any questions, feel free to post here in the Django Developer 
forum, or via Github issues at: https://github.com/microsoft/mssql-django

Thanks,
Warren

On Friday, 26 March 2021 at 07:39:20 UTC-7 f.apo...@gmail.com wrote:

> Maybe wait with featuring till the licensing issues are cleared up. 
> https://github.com/microsoft/mssql-django/issues/15 does not leave a good 
> impression on a first glance.
>
> On Friday, March 26, 2021 at 1:48:50 PM UTC+1 wi...@wsvincent.com wrote:
>
>> Yes, what Adam said! We'll certainly feature the project next week in 
>> Django News and would happily also include a blog post etc on the project :)
>>
>> On Friday, March 26, 2021 at 7:56:11 AM UTC-4 Adam Johnson wrote:
>>
>>> Great work Warren and co! I see you already have a number of stars on 
>>> GitHub.
>>>
>>> A promotional blog post could help get the word out as well. If you do 
>>> write one, submit your blog's Django-specific feed to "Community blog 
>>> posts" on https://www.djangoproject.com/community/ and it will get 
>>> picked up by many readers. You can also send it to Jeff Triplett and Will 
>>> Vincent who run Django News ( https://django-news.com/ ).
>>>
>>> On Fri, 19 Mar 2021 at 23:56, Warren Chu  wrote:
>>>
 Hi All, 

 We've released the preview version 1.0b1 of the Microsoft SQL Server 
 3rd Party Backend for Django. This version supports Django 2.2, 3.0 and 
 3.1.

 What's coming up next between now and GA release? We are re-adding 
 optional regex support, so that the regex DLL file is downloadable from a 
 trusted Microsoft downloads page. This file can then be installed in SQL 
 Server via our project script. This follows our organizational security 
 best practices.

 If you have any questions, feel free to post here in the Django 
 Developer forum, or via Github issues at: 
 https://github.com/microsoft/mssql-django

 Thanks,
 Warren

 -- 
 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-develop...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/93188f91-c638-4e4d-89ee-e4b63585ab38n%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/7aa5dd92-47b7-43fb-98b5-0c33447156f7n%40googlegroups.com.

#16406 - Allow separate access to matches from urlpatterns and extra_context args

[Alexandre Prieto Pantoja]

Hello everyone!

I’am new to Django and I would like to contribute.

I followed the documentation and I picked up an assigned ticket (# 16406 3 
)

Now I’am trying to solve it but I am stuck. The ticket is rather old and I 
don’t really understand what is the problem I have to tackle.

I posted a message to explain what I’ve done until now in the ticket 
description.

If anyone could give me a direction to follow It would be a great help.

Thanks

-- 
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/26c86d66-84f3-4c40-9b3e-bb21471ffeban%40googlegroups.com.