Re: Validation of m2m

[Bernd Wechner]

That would be my guess too. So if it went into the Django core at all, it 
would need to be documented as a Postgresql only thing I guess (if the 
guess proves right). This might also then figure in the recommendation on 
databases. Postgresql is already recommended as the production database by 
Django doc somewhere, it's only reason I opted for it when I started this 
project, on that recommendation. And if, among its benefits is that you 
validate ToMany relationships in the ORM, that would be a feather in its 
cap. Was certainly a pleaasant and surprising discovery that I could get 
away with this in a transaction. 

On Friday, 22 February 2019 14:55:24 UTC+11, Chris Foresman wrote:
>
> My guess is this does not work on MySQL or SQLite, since as far as I can 
> tell it’s the only DB that will return IDs when bulk inserting. I’d think 
> you’d have to have some other code path to handle those DB backends. 

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bcaa4ee4-1649-42fc-82b6-6cffd25bee93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Validation of m2m

[Chris Foresman]

My guess is this does not work on MySQL or SQLite, since as far as I can tell 
it’s the only DB that will return IDs when bulk inserting. I’d think you’d have 
to have some other code path to handle those DB backends. 

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5896cf09-193a-4e3b-b315-d0963816099a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Validation of m2m

[Bernd Wechner]

That's an idea I like. Though it affects OneToMany relations too  (no idea 
why this is so often presented as an m2m issue, when it's literally a 2m 
issue. So I'd prefer the attribute to be something like 
validate_tomany_relations or validate_2m perhaps. The focus on m2m is 
misleading. 

Either way yes, the attribute could default to False in the core CreateView 
and UpdateView conserving existing behaviour and be set to True in derived 
views to win a callback to Model.clean_rleations() (or a method with some 
other name, the name is up for discussion). Could even be that clean() 
accepts an optional arg like relationships_available or 2nd_pass or 
whatever ... and we can code clean() in our Models to have two paths, one 
on the first pass for the model fields (which can force a bail before we 
bother to start a transaction that needs rolling back) and a second pass 
after the forms and formsets are saved inside a transaction and all the 
relationships are visible.

Of course I'm still not sure if this works on MySQL or Lightdb? MY empircal 
testing is entirely on Postgresql for now.

But yes I agree it's more flexible as it can be set for individual model 
views or not as desired rather than for the whole app! Thumbs up really for 
that.

On Friday, 22 February 2019 09:10:05 UTC+11, Ian Foote wrote:
>
> I don't think a new setting is the way to go. I'd prefer to add an 
> attribute (validate_m2m = False?) to the CreateView and UpdateView classes 
> that allows a developer to opt-in to the new behaviour when they need it. 
> This is more flexible and still maintains backwards compatibility.
>
> Regards,
> Ian
>
> On Thu, 21 Feb 2019 at 11:03, Bernd Wechner  > wrote:
>
>> Most once sided discussion I've seen on a developers group in a while 
>> ;-), but I'll go so far as to suggest an API for the Django Core on this 
>> one. I mean I have a way to advance myself now, but methinks this need is 
>> so common that perhaps it's best sitting in the Django Core, albeit with a 
>> setting as it demands an atomic transaction for create and update views. 
>> Now this rests on a few premises, namely:
>>
>>
>>1. That there is nothing overly broken with my suggestion that I am 
>>not seeing as yet (I am the noob after all, and while pretty Python and 
>>Django savvy, not diving into the core code very often at all, as little 
>> as 
>>I've needed to, the very benefit of a cool framewor, keeping us isolated 
>>from the dirty details ;-).
>>2. That the observations I tabled are valid across all three database 
>>backends that Django supports. if it's only  1 (Postgres) or 2 then it 
>>shoudl definitely stay an enable-able option and not a default behaviour.
>>
>> A suggested API is as follows:
>>
>>
>>1. Implement a  setting to enable this new behaviour. Looking over 
>>exiting settings they can get quite long in name (like  
>>DATA_UPLOAD_MAX_NUMBER_FIELDS for example) and so perhaps a name like: 
>>RELATIONSHIP_VALIDATORS. I take inspiration from this setting:
>>
>>AUTH_PASSWORD_VALIDATORS¶ 
>>
>> 
>>  
>>
>>Default: [] (Empty list)
>>
>>The list of validators that are used to check the strength of user’s 
>>passwords. See Password validation 
>>
>> 
>>  
>>for more details. By default, no validation is performed and all 
>> passwords 
>>are accepted.
>>
>>And propose:
>>
>>TOMANY_RELATIONSHIP_VALIDATORS¶ 
>>
>> 
>>  
>>
>>Default: False
>>
>>A boolean that specifies whether to use atomic transactions on in 
>>CreateView and UpdateView POST requests in order to support relationship 
>>(OneToMany and ManyToMany) validation in the Model itself. If true, 
>>Model.clean() is called as usual, then inside an atomic transaction all 
>>submitted forms and formsets are saved and Model.clean_relations() is 
>>called. It is important to note that when Model.clean() is saved ToMany 
>>relationship (creation or changes) are not visible to Model.clean() but 
>> are 
>>visible in Model.clean_relations() where they can be validated.
>>
>>2. 
>>
>>Implement the code in CreateView.post(...) and UpdateView.post(...) 
>>that does this, that is a little savvier than my example in previous 
>> mail, 
>>but if form.is_valid() pass opens a transaction, saves the form and then 
>>for each other form or formset in the POSTed data (not sure off hand how 
>> to 
>>find those, more learning for me), check each with their .is_valid() and 
>> if 
>>passing save it, then call Model.clean_relations() (for each model 
>> involved 
>>(associated with any of the submitted forms or formsets). Of course has 
>> to 
>>work 

Re: Validation of m2m

[Ian Foote]

I don't think a new setting is the way to go. I'd prefer to add an
attribute (validate_m2m = False?) to the CreateView and UpdateView classes
that allows a developer to opt-in to the new behaviour when they need it.
This is more flexible and still maintains backwards compatibility.

Regards,
Ian

On Thu, 21 Feb 2019 at 11:03, Bernd Wechner  wrote:

> Most once sided discussion I've seen on a developers group in a while ;-),
> but I'll go so far as to suggest an API for the Django Core on this one. I
> mean I have a way to advance myself now, but methinks this need is so
> common that perhaps it's best sitting in the Django Core, albeit with a
> setting as it demands an atomic transaction for create and update views.
> Now this rests on a few premises, namely:
>
>
>1. That there is nothing overly broken with my suggestion that I am
>not seeing as yet (I am the noob after all, and while pretty Python and
>Django savvy, not diving into the core code very often at all, as little as
>I've needed to, the very benefit of a cool framewor, keeping us isolated
>from the dirty details ;-).
>2. That the observations I tabled are valid across all three database
>backends that Django supports. if it's only  1 (Postgres) or 2 then it
>shoudl definitely stay an enable-able option and not a default behaviour.
>
> A suggested API is as follows:
>
>
>1. Implement a  setting to enable this new behaviour. Looking over
>exiting settings they can get quite long in name (like
>DATA_UPLOAD_MAX_NUMBER_FIELDS for example) and so perhaps a name like:
>RELATIONSHIP_VALIDATORS. I take inspiration from this setting:
>
>AUTH_PASSWORD_VALIDATORS¶
>
> 
>
>Default: [] (Empty list)
>
>The list of validators that are used to check the strength of user’s
>passwords. See Password validation
>
> 
>for more details. By default, no validation is performed and all passwords
>are accepted.
>
>And propose:
>
>TOMANY_RELATIONSHIP_VALIDATORS¶
>
> 
>
>Default: False
>
>A boolean that specifies whether to use atomic transactions on in
>CreateView and UpdateView POST requests in order to support relationship
>(OneToMany and ManyToMany) validation in the Model itself. If true,
>Model.clean() is called as usual, then inside an atomic transaction all
>submitted forms and formsets are saved and Model.clean_relations() is
>called. It is important to note that when Model.clean() is saved ToMany
>relationship (creation or changes) are not visible to Model.clean() but are
>visible in Model.clean_relations() where they can be validated.
>
>2.
>
>Implement the code in CreateView.post(...) and UpdateView.post(...)
>that does this, that is a little savvier than my example in previous mail,
>but if form.is_valid() pass opens a transaction, saves the form and then
>for each other form or formset in the POSTed data (not sure off hand how to
>find those, more learning for me), check each with their .is_valid() and if
>passing save it, then call Model.clean_relations() (for each model involved
>(associated with any of the submitted forms or formsets). Of course has to
>work if the model fails to implement clean_relations(), either by checking
>it's there first of defining a default implementation which pay just pass.
>
>3.
>
>If Model.clean_relations() fails (throws an exception), roll back, if
>not commit.
>
> It's a rough outline that I think can work. And if it's good (which I
> await feedback on from the silent developer community) then there may even
> be a case for defaulting this setting to True, on new projects anyhow as it
> may be sensible to default to False on any existing site (not introduce a
> new transaction layer without warning on existing projects that upgrade
> Django - where there may well be a transaction system in place already).
>
> I mean if it's a good plan, and it actually gets some feedback to that
> efffect or that help it evolve into a good plan, thus far this looks
> eminently like something I could implement and submit as a PR (Pull
> Request), but I'm just as likely to code mine up and run as I am way way
> busy on other stuff ;-).
>
> Regards,
>
> Bernd.
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> 

Re: Django 2.2 and the watchman reloader

[Claude Paroz]

Le jeudi 21 février 2019 21:43:43 UTC+1, Tom Forbes a écrit :
>
> Hey Claude,
> Thanks for your feedback on the feature, I fully agree with you. I think 
> we should remove that warning message about the missing package. I will 
> make a PR to do that.
>

I'm not completely sure it's a good idea to entirely remove the message. 
Maybe just telling the used reloader would be fine.
 

> Regarding creating another reloader: it should not be that difficult to do 
> at all since we have all the other pieces in place. In theory it's just 
> implementing a class with single generator method.
>
> If people agree I would like to use the 'watchdog' package for this rather 
> than the pyinotify library as it would be quicker to implement, a lot nicer 
> to work with and is easier to test.
>

++1, watchdog is better maintained, looks like pyinotify is dead. Tell me 
if you need help, even if you seems a lot more knowledgeable than me on the 
subject.
 
Thanks.

Claude


> On Thu, 21 Feb 2019, 19:56 Claude Paroz, > 
> wrote:
>
>> Le jeudi 21 février 2019 19:48:31 UTC+1, Dan Davis a écrit :
>>>
>>> Claude,
>>>
>>> I've tested a Django based application on 2.2b1 without watchman on 
>>> Windows, it does tell you about watchman, but it doesn't fail to run.  
>>> Apparently, it falls back to the old way of reloading.   Is this not the 
>>> behavior on Debian/Ubuntu? 
>>>
>>
>> Yes it is. I would say this is still a slight regression in two ways:
>>
>> - no messages told you the reload method was not optimal before. So now 
>> people will try to "fix" their system, more than before.
>> - for Debian-based systems, you could improve the reloading performance 
>> by installing system or pip packages in 30 seconds. Now you have to spend 
>> 30 minutes to search how watchman can be installed and to compile the 
>> package (+ you have to care yourself for any security issue).
>>
>> Claude
>>
>> -- 
>> 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 post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/b059553a-e25e-4d90-beed-bf7e0f797305%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6de70f64-9bbb-4017-bd10-c85e94ae08d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.2 and the watchman reloader

[Tom Forbes]

Hey Claude,
Thanks for your feedback on the feature, I fully agree with you. I think we
should remove that warning message about the missing package. I will make a
PR to do that.

Regarding creating another reloader: it should not be that difficult to do
at all since we have all the other pieces in place. In theory it's just
implementing a class with single generator method.

If people agree I would like to use the 'watchdog' package for this rather
than the pyinotify library as it would be quicker to implement, a lot nicer
to work with and is easier to test.

On Thu, 21 Feb 2019, 19:56 Claude Paroz,  wrote:

> Le jeudi 21 février 2019 19:48:31 UTC+1, Dan Davis a écrit :
>>
>> Claude,
>>
>> I've tested a Django based application on 2.2b1 without watchman on
>> Windows, it does tell you about watchman, but it doesn't fail to run.
>> Apparently, it falls back to the old way of reloading.   Is this not the
>> behavior on Debian/Ubuntu?
>>
>
> Yes it is. I would say this is still a slight regression in two ways:
>
> - no messages told you the reload method was not optimal before. So now
> people will try to "fix" their system, more than before.
> - for Debian-based systems, you could improve the reloading performance by
> installing system or pip packages in 30 seconds. Now you have to spend 30
> minutes to search how watchman can be installed and to compile the package
> (+ you have to care yourself for any security issue).
>
> Claude
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b059553a-e25e-4d90-beed-bf7e0f797305%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFNZOJMK_MCbKByWkVKC7QY8_As30%2BnKA4rR1c9UNqWLhUX60g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.2 and the watchman reloader

[Claude Paroz]

I have a POC patch here: https://github.com/django/django/pull/11014

Claude

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0e5965c9-0e1c-42ed-8d58-55a71ff6e91c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.2 and the watchman reloader

[Claude Paroz]

Le jeudi 21 février 2019 19:48:31 UTC+1, Dan Davis a écrit :
>
> Claude,
>
> I've tested a Django based application on 2.2b1 without watchman on 
> Windows, it does tell you about watchman, but it doesn't fail to run.  
> Apparently, it falls back to the old way of reloading.   Is this not the 
> behavior on Debian/Ubuntu? 
>

Yes it is. I would say this is still a slight regression in two ways:

- no messages told you the reload method was not optimal before. So now 
people will try to "fix" their system, more than before.
- for Debian-based systems, you could improve the reloading performance by 
installing system or pip packages in 30 seconds. Now you have to spend 30 
minutes to search how watchman can be installed and to compile the package 
(+ you have to care yourself for any security issue).

Claude

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b059553a-e25e-4d90-beed-bf7e0f797305%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.2 and the watchman reloader

[Dan Davis]

Claude,

I've tested a Django based application on 2.2b1 without watchman on
Windows, it does tell you about watchman, but it doesn't fail to run.
Apparently, it falls back to the old way of reloading.   Is this not the
behavior on Debian/Ubuntu?

On Thu, Feb 21, 2019 at 12:28 PM Claude Paroz  wrote:

> Hi,
>
> The new watchman-based autoreloader in Django 2.2 is a nice improvement.
> However, the main issue in my opinion is that there are no Debian/Ubuntu
> official packaging of watchman to my knowledge.
> I've been able to compile it without difficulty, but I'm especially
> concerned about newcomers and non-experienced programmers which will be
> faced to a startup warning message and a rather heavy system load when they
> start developing with Django. Telling them they have to compile from
> sources to get rid of that is not very friendly at least.
>
> Tom (Forbes), as the author of this refactoring, could you tell us if it
> would be much work to create a pyinotify reloader to fallback when watchman
> is not installed?
>
> Claude
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/23ecaa54-a148-4439-a16b-16937da9e934%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFzonYbE4fSy7wsO_wDgHy1X%2BRaWppXejQXB-tnbPtC5RjwwoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django 2.2 and the watchman reloader

[Claude Paroz]

Hi,

The new watchman-based autoreloader in Django 2.2 is a nice improvement. 
However, the main issue in my opinion is that there are no Debian/Ubuntu 
official packaging of watchman to my knowledge.
I've been able to compile it without difficulty, but I'm especially 
concerned about newcomers and non-experienced programmers which will be 
faced to a startup warning message and a rather heavy system load when they 
start developing with Django. Telling them they have to compile from 
sources to get rid of that is not very friendly at least.

Tom (Forbes), as the author of this refactoring, could you tell us if it 
would be much work to create a pyinotify reloader to fallback when watchman 
is not installed?

Claude

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/23ecaa54-a148-4439-a16b-16937da9e934%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will Django ever CompositePrimaryKeys?

[Simone Federici]

Lance Ellinghaus wrote:

> Should I consider his statements to be the final statement from the Django
> core developers?
>

of course not, I'm not a core developer.
:-)

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKsNYugf%3Dws7ObtCQAG_iSLfxV%3DB9Z5xjqJ%2BO1hGii2L8s1iLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Mat Gadd]

You can see this in action yourself using Chrome's Dev Tools. Open Dev
Tools, then their Settings, and turn on "Auto-open DevTools for popups".
Then, click any link in the Gmail web app. You'll see you go via
google.com/url?q=original_url_here. Since they're doing this with
JavaScript, the links look like they're going to open the real URL, but
they *don't.*

On Thu, 21 Feb 2019 at 10:44, Mat Gadd  wrote:

> Exactly that, yes. We've disabled all click tracking that we can, but
> Gmail has its own redirect which causes Safari's privacy features to kick
> in. (Some?) Gmail users are unable to use the password reset emails.
>
> On Thursday, 21 February 2019 01:03:54 UTC, Philip James wrote:
>>
>> Mat, are you saying you're seeing Safari still blocking, even with click
>> tracking turned off, because GMail itself is inserting a redirect?
>>
>> PJJ
>> http://philipjohnjames.com
>>
>>
>> On Wed, Feb 20, 2019 at 4:46 AM Mat Gadd  wrote:
>>
>>> We're also now seeing Gmail users complain that the password reset links
>>> don't work, even after we disabled click tracking. It seems that Google are
>>> inserting their own click tracking into users' emails, which is… weird?
>>>
>>> The markup of links is transformed to the following (where … is our
>>> original URL):
>>>
>>> https://www.google.com/url?q=…;>Link text here
>>>
>>> Gmail is a *huge* provider of emails, and they make up around 54% of our
>>> user base. Anyone using the Gmail web app can no longer reset their
>>> password simply by clicking the link in the email.
>>>
>>> On Wednesday, 23 January 2019 12:51:22 UTC, Perry Roper wrote:

 It would appear that this affects a large number of users. We're also
 experiencing this in the following configurations.

 - Mailgun click tracking enabled + Safari 12.0 on MacOS or any browser
 in iOS 12
 - Clicking the link in the Gmail app or web app (Mailgun click tracking
 disabled) + Safari 12.0 on MacOS or any browser in iOS 12.

 All iOS 12 browsers and MacOS Safari users using the Gmail app, or in
 any email client if the site they are requesting a password from uses link
 tracking.

 On Thursday, 22 November 2018 20:43:15 UTC+7, Mat Gadd wrote:
>
> Hi all,
>
> I raised a ticket 
> regarding this and was directed here to discuss the topic. The summary is
> that the combination of using click-tracking redirects (which are popular
> with a variety of email providers) with the Django contrib.auth password
> reset views does not work in Safari on macOS and iOS as of the latest 
> major
> versions.
>
> It took me quite a long time to work out what was happening, so I
> wanted to at least raise a ticket where other people might find it, but 
> was
> also hoping to start a discussion around how else the problem could be
> mitigated. An option to disable the internal token redirect might be
> useful, but that then re-opens the token up to being leaked via the
> HTTP_REFERER header.
>
> Regards,
>  - Mat
>
 --
>>> 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 post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/c10f608f-7f5e-4bba-aa89-4779e37d61f0%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2830288b-6890-4c2f-ac4c-b07a82196619%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 

Re: Validation of m2m

[Bernd Wechner]

Most once sided discussion I've seen on a developers group in a while ;-), 
but I'll go so far as to suggest an API for the Django Core on this one. I 
mean I have a way to advance myself now, but methinks this need is so 
common that perhaps it's best sitting in the Django Core, albeit with a 
setting as it demands an atomic transaction for create and update views. 
Now this rests on a few premises, namely:


   1. That there is nothing overly broken with my suggestion that I am not 
   seeing as yet (I am the noob after all, and while pretty Python and Django 
   savvy, not diving into the core code very often at all, as little as I've 
   needed to, the very benefit of a cool framewor, keeping us isolated from 
   the dirty details ;-).
   2. That the observations I tabled are valid across all three database 
   backends that Django supports. if it's only  1 (Postgres) or 2 then it 
   shoudl definitely stay an enable-able option and not a default behaviour.

A suggested API is as follows:


   1. Implement a  setting to enable this new behaviour. Looking over 
   exiting settings they can get quite long in name (like  
   DATA_UPLOAD_MAX_NUMBER_FIELDS for example) and so perhaps a name like: 
   RELATIONSHIP_VALIDATORS. I take inspiration from this setting:
   
   AUTH_PASSWORD_VALIDATORS¶ 
   
 
   
   Default: [] (Empty list)
   
   The list of validators that are used to check the strength of user’s 
   passwords. See Password validation 
   

 
   for more details. By default, no validation is performed and all passwords 
   are accepted.
   
   And propose:
   
   TOMANY_RELATIONSHIP_VALIDATORS¶ 
   
 
   
   Default: False
   
   A boolean that specifies whether to use atomic transactions on in 
   CreateView and UpdateView POST requests in order to support relationship 
   (OneToMany and ManyToMany) validation in the Model itself. If true, 
   Model.clean() is called as usual, then inside an atomic transaction all 
   submitted forms and formsets are saved and Model.clean_relations() is 
   called. It is important to note that when Model.clean() is saved ToMany 
   relationship (creation or changes) are not visible to Model.clean() but are 
   visible in Model.clean_relations() where they can be validated.
   
   2. 
   
   Implement the code in CreateView.post(...) and UpdateView.post(...) that 
   does this, that is a little savvier than my example in previous mail, but 
   if form.is_valid() pass opens a transaction, saves the form and then for 
   each other form or formset in the POSTed data (not sure off hand how to 
   find those, more learning for me), check each with their .is_valid() and if 
   passing save it, then call Model.clean_relations() (for each model involved 
   (associated with any of the submitted forms or formsets). Of course has to 
   work if the model fails to implement clean_relations(), either by checking 
   it's there first of defining a default implementation which pay just pass. 
   
   3. 
   
   If Model.clean_relations() fails (throws an exception), roll back, if 
   not commit. 
   
It's a rough outline that I think can work. And if it's good (which I await 
feedback on from the silent developer community) then there may even be a 
case for defaulting this setting to True, on new projects anyhow as it may 
be sensible to default to False on any existing site (not introduce a new 
transaction layer without warning on existing projects that upgrade Django 
- where there may well be a transaction system in place already).

I mean if it's a good plan, and it actually gets some feedback to that 
efffect or that help it evolve into a good plan, thus far this looks 
eminently like something I could implement and submit as a PR (Pull 
Request), but I'm just as likely to code mine up and run as I am way way 
busy on other stuff ;-).

Regards,

Bernd.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/239d7900-94a8-4491-b973-50e8731b3957%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Mat Gadd]

Exactly that, yes. We've disabled all click tracking that we can, but Gmail 
has its own redirect which causes Safari's privacy features to kick in. 
(Some?) Gmail users are unable to use the password reset emails.

On Thursday, 21 February 2019 01:03:54 UTC, Philip James wrote:
>
> Mat, are you saying you're seeing Safari still blocking, even with click 
> tracking turned off, because GMail itself is inserting a redirect?
>
> PJJ
> http://philipjohnjames.com
>
>
> On Wed, Feb 20, 2019 at 4:46 AM Mat Gadd > 
> wrote:
>
>> We're also now seeing Gmail users complain that the password reset links 
>> don't work, even after we disabled click tracking. It seems that Google are 
>> inserting their own click tracking into users' emails, which is… weird?
>>
>> The markup of links is transformed to the following (where … is our 
>> original URL):
>>
>> https://www.google.com/url?q=…;>Link text here
>>
>> Gmail is a *huge* provider of emails, and they make up around 54% of our 
>> user base. Anyone using the Gmail web app can no longer reset their 
>> password simply by clicking the link in the email. 
>>
>> On Wednesday, 23 January 2019 12:51:22 UTC, Perry Roper wrote:
>>>
>>> It would appear that this affects a large number of users. We're also 
>>> experiencing this in the following configurations.
>>>
>>> - Mailgun click tracking enabled + Safari 12.0 on MacOS or any browser 
>>> in iOS 12
>>> - Clicking the link in the Gmail app or web app (Mailgun click tracking 
>>> disabled) + Safari 12.0 on MacOS or any browser in iOS 12.
>>>
>>> All iOS 12 browsers and MacOS Safari users using the Gmail app, or in 
>>> any email client if the site they are requesting a password from uses link 
>>> tracking.
>>>
>>> On Thursday, 22 November 2018 20:43:15 UTC+7, Mat Gadd wrote:

 Hi all,

 I raised a ticket  
 regarding this and was directed here to discuss the topic. The summary is 
 that the combination of using click-tracking redirects (which are popular 
 with a variety of email providers) with the Django contrib.auth password 
 reset views does not work in Safari on macOS and iOS as of the latest 
 major 
 versions.

 It took me quite a long time to work out what was happening, so I 
 wanted to at least raise a ticket where other people might find it, but 
 was 
 also hoping to start a discussion around how else the problem could be 
 mitigated. An option to disable the internal token redirect might be 
 useful, but that then re-opens the token up to being leaked via the 
 HTTP_REFERER header.

 Regards,
  - Mat

>>> -- 
>> 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 post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/c10f608f-7f5e-4bba-aa89-4779e37d61f0%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2830288b-6890-4c2f-ac4c-b07a82196619%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.