Increasing support for Microsoft SQL Server

[Warren Chu]

Hi All,

Microsoft has commissioned internal resources, of which I'm a member, to 
drive development and support of an open source Microsoft SQL Server 
backend solution for Django. This project would exist under the 
github.com/microsoft organization.

We recognize there is an existing and active project 
[https://github.com/ESSolutions/django-mssql-backend], and we'd like to 
solicit ideas and feedback from the Django community on the best way to 
proceed.

Some initial questions we have are:

1 - How can we best collaborate?
2 - What issues or challenges are most pressing to make MSSQL-Django work 
better for you?

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/25102379-5df3-4c55-a786-ac9acda20b13n%40googlegroups.com.

Re: Email console backend via docker logs not accessible

[Gil Obradors]

Sorry, my fault
The email is not sent if there isnt password set.

Working fine  with docker.



El dt., 3 de nov. 2020, 19:32, Gil Obradors  va
escriure:

>
> Hi,
> My name is Gil, new from here from Spain.
> A pleasure trying to contribute content to this wonderful project
>
> I'm dealiing with a project dockerized. I have seen when you have
> configured 'django.core.mail.backends.console.EmailBackend' as
> EMAIL_BACKEND the emails are written to stdout. In docker env this
> messages  are not seen.
>
> It's a better approuch to make a patch so that this email is sent by
> logging debug, instead of stdout ?
>
> If it's worth it, I'll try to write it down
>
> Thanks and see you soon!
>
>
> PD: tested in Django 3.1.3
>
>
>
> --
> 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/df58d993-8c11-4e4d-812e-dd3c808d73b0n%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/CAK-JoTTKr%2Bt0uFdOYKRi-g3wFNa91u-EXXiA3h%2BCHaMPX6wO3A%40mail.gmail.com.

Email console backend via docker logs not accessible

[Gil Obradors]

Hi,
My name is Gil, new from here from Spain.
A pleasure trying to contribute content to this wonderful project

I'm dealiing with a project dockerized. I have seen when you have 
configured 'django.core.mail.backends.console.EmailBackend' as 
EMAIL_BACKEND the emails are written to stdout. In docker env this 
messages  are not seen.

It's a better approuch to make a patch so that this email is sent by 
logging debug, instead of stdout ?

If it's worth it, I'll try to write it down

Thanks and see you soon!


PD: tested in Django 3.1.3



-- 
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/df58d993-8c11-4e4d-812e-dd3c808d73b0n%40googlegroups.com.

Re: Improved labels for M2M relations

[Julian Klotz]

Hey there, thanks! I agree, "Relation between  and " will work in all 
cases.

Here’s a draft implementation:
https://github.com/django/django/compare/master...julianklotz:feature_better_m2m_relation_labels

Here’s what needs to be improved:

   - `create_many_to_many_intermediary_model`: The method uses both model 
   classes and model class names; to access the verbose name, class names need 
   to be resolved to “real” classes first. Any hints how to do that? 
`resolve_relation` 
   doesn't to the job, because it returns both model names and classes, too.
   - Not sure how to implement tests for __str__ method without creating 
   migrations?

Let me know what you think about it.

Julian
Adam Johnson schrieb am Montag, 2. November 2020 um 10:21:06 UTC+1:

> I don't think we can use just "Relation to" because M2M relationships are 
> two-way by default. Whilst a ManyToManyField can be declared on one model, 
> it adds a reverse field on the other model. We'd have to show both sides of 
> the relation e.g. "Relation between  and ".
>
> On Tue, 27 Oct 2020 at 08:56, Julian Klotz  wrote:
>
>> … one last thought:
>>
>> The verbose name could be: “Media Item-Piece relation”
>> The string presentation could be: “Relation to > to-instance>”, e.g. “Relation to Piece xyz”
>>
>> Together: 
>> *Media Item-Piece relation: Relation to Piece xyz (ID: 11773)*
>>
>>
>> Julian Klotz schrieb am Dienstag, 27. Oktober 2020 um 09:30:59 UTC+1:
>>
>>> Hi Adam,
>>>
>>> thanks for picking this up so quickly.
>>> I considered setting custom “through” models to set verbose name and 
>>> __str__, but I currently can’t “afford” changing all m2m fields throught 
>>> the application.
>>>
>>> Here’s the feedback I got concerning the usability issues (e.g. for 
>>> MediaItem_pieces_relation object (11773))
>>>
>>>- Some people thought “11773” was the number of objects to be 
>>>deleted, even though the UI clearly states something else – it isn’t 
>>>obvious for some people that relations have their own IDs
>>>- People asked where they could change the (then-deleted) relation 
>>>to a different object
>>>
>>>
>>>
>>> *It can also help with debugging as the label appears in the default 
>>> str/repr.*
>>> Thanks for giving me that hint. It’s the __str__ method of models.Model. 
>>> Changing the default string presentation may be dangerous and also too 
>>> generic. It would make sense to define a custom to-string method in 
>>> `create_many_to_many_intermediary_model` (fields/related.py)*.*
>>> Instead of showing *MediaItem_pieces_relation object (11773),* 
>>> something like “Media Item-Piece relation, ID: 11773) would be good*; 
>>> *moreover, 
>>> it may be a good idea to show the “from” model’s edit link to point people 
>>> to the place where they can change this relation.
>>>
>>> *My main question is, does this not trigger migrations on user projects?*
>>> Good point. I just checked – interestingly, neither changing the verbose 
>>> name nor the __str__ method triggers new migrations 拾
>>>
>>>
>>>
>>> Best regards
>>> Julian
>>>
>>> Adam Johnson schrieb am Montag, 26. Oktober 2020 um 19:56:15 UTC+1:
>>>
 Hi Julian

 It should be noted that you can improve the display today by creating 
 explicit through models. However this is more longwinded.

 This change does look like a neat usability improvement to me. It can 
 also help with debugging as the label appears in the default str/repr. My 
 main question is, does this not trigger migrations on user projects?

 Thanks,

 Adam

 On Mon, 26 Oct 2020 at 16:28, Julian Klotz  
 wrote:

>
> Hey there,
>
> here’s a little topic that impacts the usability of Django admin’s 
> delete views.
>
> When deleting an object using django admin, you get a nice summary of 
> all deleted objects.
> I really like the overview, but the labels used to describe m2m 
> relations that will be deleted aren't user-friendly at all:
>
> […]
>
>- MediaItem-subseries-relation: MediaItem_sub_series_relation 
>object (11482)
>- MediaItem-piece-relation: MediaItem_pieces_relation object 
>(11773)
>
> So I’d like to improve the labels a bit, using the from and to model’s 
> verbose names. This can be easily accomplished by changing 
> `create_many_to_many_intermediary_model` in fields/related.py.
>
> To be honest, I don’t know how to update the tests for something 
> rooted deeply in Django’s core.Is anyone who is more competent than me 
> interested in fixing this? It would greatly improve the “delete 
> confirmation“ views.
>
> Here’s what I’ve got so for; it only fixes the model’s verbose name, 
> not its string presentation.
>
> Best regards
> Julian
>
>
> […]
> to = make_model_tuple(to_model)[1]
> from_ = klass._meta.model_name
>
> if 

Re: Fellow Reports - October 2020

[Mariusz Felisiak]

Week ending November 1, 2020.

*Triaged: *
   https://code.djangoproject.com/ticket/32143 - Use EXISTS to exclude 
multi-valued relationships (accepted) 
   https://code.djangoproject.com/ticket/32141 - Translated content becomes 
ugly due to line-down on new admin side-bar (duplicate) 
   https://code.djangoproject.com/ticket/32138 - Header of calendar widget 
will be render "under" the map widget. (accepted) 
   https://code.djangoproject.com/ticket/32144 - makemessages leaves 
temporary files when locale directory doesn't exist. (accepted) 
   https://code.djangoproject.com/ticket/32146 - Make AutocompleteSelect 
and AutocompleteSelectMultiple easier to reuse (wontfix) 
   https://code.djangoproject.com/ticket/32137 - Change message describing 
the deletion of inline objects in admin has no id available. (needsinfo) 
   https://code.djangoproject.com/ticket/32147 - timezone error when 
casting a naive date in a Daylight Saving Time Change (invalid) 
   https://code.djangoproject.com/ticket/32149 - dateformat.y() doesn't 
support years < 1000. (accepted) 
   https://code.djangoproject.com/ticket/32148 - Exception reporter returns 
text/html response when X-Requested-With is set. (wontfix) 
   https://code.djangoproject.com/ticket/32151 - Invalid query SQL created 
when combining __in and F() in filter (duplicate) 
   https://code.djangoproject.com/ticket/32153 - Support for list arguments 
inside exclusive required groups (accepted) 
   https://code.djangoproject.com/ticket/32157 - Additional information to 
the "with" templatetag. (worksforme) 
   https://code.djangoproject.com/ticket/32158 - loaddata crashes on SQLite 
when table names are SQL keywords. (accepted) 

*Reviewed/committed: *
   https://github.com/django/django/pull/13595 - Fixed #32138 -- Prevented 
admin's map from covering other widgets. 
   https://github.com/django/django/pull/13598 - Refs #31670 -- Used 
allowlist_externals in tox.ini. 
   https://github.com/django/django/pull/13589 - Fixed #29497 -- Fixed loss 
of assigned parent when saving child with bulk_create() after parent. 
   https://github.com/django/django/pull/13396 - Removed @no_oracle 
decorator. 
   https://github.com/django/django/pull/13315 - Fixed #1891, Fixed #11707 
-- Prevented duplicates with limit_choices_to on multi-value relations. 
   https://github.com/django/django/pull/13606 - Fixed #32143 -- Used 
EXISTS to exclude multi-valued relationships. 
   https://github.com/django/django/pull/13600 - Fixed #32062 -- Added %b 
support to Date.strftime. 
   https://github.com/django/django/pull/13392 - Refs #25780 -- Removed 
redundant status code assertions from tests. 
   https://github.com/django/django/pull/13567 - Fixed #26962 -- Doc'd 
running migrations in transactions. 
   https://github.com/django/django/pull/13617 - Fixed #32152 -- Fixed 
grouping by subquery aliases. 
   https://github.com/django/django/pull/13622 - Refs #32061 -- Unified 
DatabaseClient.runshell() in db backends. 
   https://github.com/django/django/pull/13477 - Refs #32061 -- Prevented 
password leak on MySQL dbshell crash. 
   https://github.com/django/django/pull/13494 - Increased test coverage of 
django.utils.datastructures to 100%. 
   https://github.com/django/django/pull/13620 - Fixed #32153 -- Fixed 
management commands when using required list options.

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/e8c42f7c-1d7d-4300-b02e-f1dd637571cfn%40googlegroups.com.